Re: [patch] IRQ threads

[Philippe Gerum <rpm@xenomai.org>]

On Wed, 2004-07-28 at 22:21, Bill Huey 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.

<snip>

> 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.
> 

With the ego power switch and name-calling amplifier lowered to the
minimum, maybe there could be a third approach, like cooperation between
both through a better integration. At least, the signal / noise ratio
would improve...

The hard RT people I know of and work with want to be able 1) to get
microsecond level bounded interrupt latency with no exception to this
rule, and 2) to be able to choose the right level of dispatch latency
on a thread-by-thread basis, from a few microseconds to a few hundreds
of, but in any case _bounded_ and predictable in the worst case. For
this to happen, they are willing to accept stringent limitations
functionaly-wise if need be to obtain the first, but still get access
to the regular Linux programming model and APIs if the second fits
their apps.  They already know how they could mix both properly in
what would look like a single system from the application pov.

For these people, the current undergoing work aimed at improving the
current determinism of the vanilla kernel is everything but a danger:
it's fundamental and very good news, because it could make 2) a
reality sooner or later. However, point 1) remains an issue, and
unless you find a solution for mixing fire and water, i.e. determinism
which requires unfairness by design and throughput seeking fairness on
the average case, you would likely end up considering that the Linux
RT people's radical approach of using a dual-kernel does not make them
uneducated bozos (Ok, except me perhaps, but this is not my point).
To get microsecond level guaranteed interrupt latencies, the problem
is far beyond solving random latency spots here and there: it's an
architectural issue.

To achieve this, we (i.e. the educated ones like Karim helping the
uneducated bozo like myself; yep, this is a teamwork) have come to the
conclusion that we needed a portable infrastructure that allows a
complete prioritization of interrupts, and hw events of interest in
general (e.g. traps/exceptions). Some infrastructure that exposes the
same interface regardless of the platform it runs on. It's called
Adeos, the source code identation is terrible (after 20 years practicing
it, I still
find means to worsen my coding style, funky eh?!) but it's a working
example of such kind of infrastructure. The advantage of such kind of
thin layer is that you can plug any hard real-time core over it. This
layer can remain silent when unused, it can be configured out, it is
just an enabler.  You don't have to put the hell of a havoc in a
stable GPOS core to modify some key architectural characteristics of
the Linux kernel in order to buy hard RT capabilities to everyone,
which could be construed as smashing a squadron of flies with nukes.

> All things to think about.

There is evidence that the GPL side of the hard RT universe does too.
Indeed.

-- 

Philippe.