Re: RT patch acceptance

[Karim Yaghmour <karim@opersys.com>]

Bill Huey (hui) wrote:
> When I think about it in terms of dual kernel primitives, I really have
> difficulty thinking about how to use the message queue stuff to integrate
> all of the systems involved in particular with shared buffers. Proper
> locking in those cases is scary to me for both methods, but at least
> the single kernel image stuff uses familiar chunks of memory that I can
> manipulate. I'm open to be proven wrong about this point if you have a
> good example sources to show me. I really am.

Having shared buffers between adeos and Linux and/or rtai and Linux is
common practice. The're all living in the same address space anyway.
So from that point of view, just lock those pages in memory.

The issue then becomes, how do these domain all talk to each other.
At the lowest of levels, Adeos provides a fairly simple inter-domain
communication mechanism: virtual interrupts. If you have a driver that
must absolutely get hard-rt responsiveness, you load it as a priority
Adeos domain and have its hard-rt handler shoot virtual interupts to
its non-rt linux upper half using a virtual interrupt, which can then
do the rest of the work that would be done by an interrupt handler.
The reverse is also possible: use a normal linux driver to feed
virtual interrupts to higher-priority adeos domain.

These are basic primitives, and it isn't difficult to see how fancy
services can be built on. As is RTAI for example.

Again, none of this precludes working to reduce Linux's responsiveness,
but it may just save the need for modifying the locking mechanisms
or threading the interrupt handlers.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546