Re: [patch] IRQ threads

[Karim Yaghmour <karim@opersys.com>]

Bill Huey (hui) wrote:
> With that said, there's really two camps that are emerging in the real
> time Linux field, dual and single kernel. The single kernel work that's
> current being done could very well get Linux to being hard RT, assuming
> that you solve all of the technical problems with things like RCU,
> etc... in 2.6.
> 
> The dual kernels folks would be in less of position to VAR their own
> stuff and sell proprietary products if Linux were to get native hard RT
> performance if you accept that economic criteria. Who knows what the
> actual results will be.

Two things:
- What I'm suggesting is a nanokernel-based N kernel scheme, not the
dual kernel scheme (which is patented BTW).
- There's only one company out there that is known to sell proprietary
products around the dual kernel approach, and it isn't mine.

> It could be that all of this work with Linux could bury prioprietary
> OS product (such as LynxOS here) or it could open doors to other things
> unknown things that were never possible previous to Linux getting some
> kind of hard RT capability. It's certainly a scary notion to think about
> with many variables to consider. Linux getting hard RT is inevitable.
> It's just a question of how it'll be handled by proprietary OS vendors,
> witness IBM for a positive example. A negative one would be Sun.
> 
> Now that Windriver System (the idiot folks that never understood Linux
> before laying off tons of folks and disbanned the rather famous BSD/OS
> group which I was apart of, etc...) and Red Hat is in the picture, it's
> all starting to cook up.

Indeed. So the question now becomes: is it worth introducing that much
complexity inside the kernel to solve a problem that matters only
marginally to server and workstation users? It's already difficult as it
is to manage the preemption, do we really want to go the full way with
threaded int handlers and mutexes instead of locks?

What I'm suggesting is a very simple model that solves 90% of the time-
sensitive problems I have seen with Linux: Use the Adeos nanokernel to
implement the real-time component of drivers as a priority domain the
interrupt pipeline. Hence, instead of the current driver model:
1- Int handler
2- BH/SoftIRQ/etc.
We get:
1- Hard-rt handler
2- Normal Linux handler
3- BH/SoftIRQ/etc.

This is even without any RTAI/RTL or anything of that kind.

And for the rest, then you want to have a look at Philippe Gerum's
ongoing RTAI-fusion work. With RTAI-fusion, you get the same normal
Linux ABI for all user-space tasks, but you get hard-rt for free.
Practically, normal Linux calls are caught and run through RTAI
instead of Linux. Philippe has already got the standard nanosleep()
running in hard-rt. So the question is therefore straight-forward:
should we engineer a path for converting the entire kernel to hard-rt
or do we keep the kernel as it was designed and add the necessary
mechanisms for obtaining hard-rt using things that were made to
provide it by design?

I personally believe that the added complexity does not benefit
Linux. I may yet be shown wrong, but with what we can currently do
with plain vanilla Adeos, and where RTAI/fusion is heading, the
problem space of applications which can't be serviced by this
combination is getting increasingly limited.

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