dde-linux, musb driver code page faults in Routine:Main

[Sebastian Sumpf]

Hi Bob,

On 04/02/2014 06:15 PM, Bob Stewart wrote:
> On 04/02/2014 10:40 AM, Bob Stewart wrote:
>> I'm porting the musb driver code from Linux, using the 14.02 release of
>> Genode. Basically, I'm using the main.cc code in dde-linux/src/lib/usb
>> to start the usb subsystem and usb port drivers. The main.cc code is
>> essentially unchanged and the start_usb_driver function is identical to
>> the release code.
>>
>> When running the executible containing this code a page fault occurs
>> when _run is called in Routine::main(). The reason appears to be the
>> schedule() function returns a pointer to 0x0 it got from _next which was
>> returned from _list. The pointer in in _list appears to have been
>> removed at the start main(). It looks to me like the code in main.cc in
>> src/lib/usb would fail for any usb driver code. What am I missing?
>>
>> Thanks,
>>           Bob Stewart
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Genode-main mailing list
>> Genode-main at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>
> Appears to be related to not including a call to subsys_usb_init() which 
> I had commented out inadvertently. Not sure why that is the case but 
> I'll figure it out. With that call included, main() now runs as expected.

The 'Routine' code resembles a sort of user-level threading. Each Linux
thread will get a stack there and scheduling is done by performing
setjmp/longjmp calls. To bootstrap this scenario the USB main thread is
added as a routine during startup, it calls all the initialization
functions, which in turn might create new Linux threads (that become
routines in the end). For USB controllers Linux creates at least the HUB
thread (see: contrib/drivers/usb/core/hub.c). After initialization we
don't need the main thread anymore, since it does not perform any Linux
driver related work, so it is removed from the routine list. By not
calling 'subsys_usb_init', the HUB thread will not be created, causing
the thread list in  routine to be empty, which it cannot handle right
now, hence the page fault.
The whole purpose of this scheme is to avoid races and only schedule
Linux threads a well defined points, like 'wait_for_completion', have a
look at 'src/lib/usb/signal/events.cc' for most points. This way we
don't have to deal with Linux's synchronization primitives and all it's
pre- and post-conditions.

I hope this clarifies things a little,

Sebastian