Re: [Xenomai-help] Advice needed: Xenomai / USB access from kernel task

[Jan Kiszka <jan.kiszka@domain.hid>]

Gilles Chanteperdrix wrote:
> On Fri, Feb 22, 2008 at 10:13 AM, G.P.M. Haagh <g.p.m.haagh@domain.hid> wrote:
>>
>> One of our trainees has written a LKM that accesses the standard Linux
>> kernel's usb_core facilities from a Xenomai real-time thread running in
>> kernel space.
>>  I am doing some follow up on his work and run into problems.
>>  I would appreciate some help/advise.
>>
>>  1)
>>  The main question to start with: is it Ok to submit urbs to usb_core
>> (usb_submit_urb) from a Xenomai kernel task (task created in a LKM) ?
> 
> Without looking at the function implementation, it is hard to answer.
> The short answer to this question is "no". In general, it ils not
> possible to call regular Linux services from a Xenomai task. Now, it
> may happen that it is possible, if the said service does not rely on
> any Linux services such as spinlocks, mutex, etc...

If we are in fact discussing a call from Xenomai RT context into the
vanilla USB stack, the answer is a clear "no". Even if we ignore the
incompatible (/wrt Xenomai) locking mechanisms the vanilla stack uses
(*), there is still the design issue that this stacks performs buffer
allocation on demand, and not in advance (like RTnet does for networking).

> Note that there is an USB stack for Xenomai, so, using this stack
> could be a better solution:
> http://developer.berlios.de/projects/usb4rt

There is another stack, usb20rt, which even supports USB 2.0 (the above
is limit to 1.1 so far). But I recently received a private mail
confirming my original review of usb20rt: It is only half-converted to
RT, still including incompatible Linux calls.

Conceptually, I consider usb4rt as the cleaner approach (not only
because it was a former student of mine who wrote it :->), but it also
suffers from its experimental state, having at least one known issue,
and lacking EHCI support.

Jan

(*) Switch on CONFIG_IPIPE_DEBUG_CONTEXT to learn about such problems
_before_ they happen to cause spurious crashes.

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux