Montavista's "Open Source Real-Time Linux Project" again

Karim Yaghmour karim at opersys.com
Fri Oct 15 02:18:00 CEST 2004


Thomas Gleixner wrote:
> Yeah, I know. I doubt that. 

You doubt which part of what I said?

> The missing bits are a few heartbeats away. You know, that there are in
> Kernel modifications around, which are at least as deterministic as
> RTAI.

And they are ... ?

> Modifing the kernel itself to do irq deferring and priviledged
> preemption of self contained irqs and userspace tasks with a restricted
> functionality is not that magic.

That's not the bone of my argument. If you have to audit every driver
and application for conformance to some way of using locks, then it's
a loosing battle. And the fact of the matter is that kernel developers
will never be able to stop anyone from using an existing API, and if
the API is in the kernel it will be used by driver and application
writers because as everyone else they want the best performance for
their software. So what will happen is that there will be drivers in
the kernel that will use this "enhanced" functionality as soon as it
becomes available, and once everyone is using it then we're back to
square one ...

> Responding to the marketing "blah" with the same amount of "blah" does
> not change anything. Neither way of self-adulation is doing any good.

I'm not sure what you are talking about. My  postings on the rtai list
are only a part of what I said on the topic. You can go around reading
what I wrote on LKML and in response to Jonathan Corbet's article on
LWN and then we'll talk some more. In the mean time, please avoid
sticking labels, it has a tendency to piss off people.

> Provide a static codepath analysis for all execution paths and I might
> buy your arguments.

Right, and then you have the nerve to lecture me about self-adulation ...

I don't have the time to do this myself, but I'd really love to plug a
scope and a function generator to machine and compare the VP patches and
RTAI under very high stress. This certainly would certainly be food for
thought for everyone involved.

Personally, I think that preemption should be dropped altogether from
the kernel. As others have said, even the basic preemption that already
exists in the kernel is highly controvertial and is rarely used because
of stability issues. Don't take my word for it, go read Jonathan's
article.

Instead, I favor the inclusion of the Adeos interrupt pipeline. It
provides a mechanism for obtaining deterministic hard-rt in Linux using
a clearly defined API, and it can be leveraged for hooking RTAI on top
of it.

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





More information about the Rtai mailing list