On Fri, 22 Apr 2016 13:53:00 +0200 Heiko Schocher hs@denx.de wrote:
An alternative approach would be not executing work directly while scheduling it but in produce_free_peb(). UBI is designed to work with the worker being disabled. All UBI work will then happen synchronous and should also work in u-boot.
Sounds good!
Not so good actually. I tried that, and ended up with tasks stalled in the work queue because the implementation was never "scheduling" the do_work() loop.
Let's keep it simple, in uboot everything is synchronous, and you can't be preempted by another task, so it's safe to assume that "scheduling a work" == "executing it right away". IMHO, the kernel should also assume that "scheduling a work" might involve "the work may have been done before the ubi_schedule_work() function returns": when you schedule a work to be done and wake up the thread responsible for dequeuing UBI works, the scheduler can decide to schedule this thread right away, which means this work can be done before the caller gets back to the instruction just after ubi_schedule_work().
Of course, this has to be nuanced for the "attach procedure", because at this time the UBI thread is not launched yet. But even in this specific case, I think it's safer to assume that, maybe one day, the UBI thread might be running when ubi_wl_init() is called, which is why I suggested to also apply this patch to Linux.
In the long run I suggest removing the whole Linux UBI implementation from u-boot and add a small (read only!) implementation which can also read UBIFS. Reading UBIFS is not a big deal. Also journal reply can be done in-memory.
Hmm.. I think read only is not for all boards an option, as we also create UBI Volumes and/or write to them in U-Boot ...
Depends. IMHO a bootloader has exactly one job, loading a kernel and booting it. And not being a poor man's general purpose operating system where you can also do management stuff like managing UBI volumes. ;-)
Heh...
That's another topic ;).