Re: RT patch acceptance

[Karim Yaghmour <karim@opersys.com>]

Ingo Molnar wrote:
> just to make sure, by "much more complicated" are you referring to the 
> PREEMPT_RT feature? Right now PREEMPT_RT consists of 8000 new lines of 
> code (of which 2000 is debugging code) and 2000 lines of modified kernel 
> code. One of the primary goals i had was to keep it simple and robust.

I'm refering to the complexity of the behavior. Turning interrupts to
threads and spinlocks to mutexes makes vanilla Linux's behavior much
more complicated than it already is. But before a bunch of mouth-foaming
rugby players tackle me to the ground, please keep in mind that this is
my appreciation of things. Others have claimed that they are perfectly
fine with this ...

> That's more than 3 times smaller than UML and it's almost an order of
> magnitude smaller than a nanokernel codebase i just checked, and it
> boots/works on just about everything where the stock Linux kernel boots.
> I challenge you to write a nanokernel/hypervisor with a comparable
> feature-set in that many lines of code.

No challenge needed, I'm not refering to codebase. No to mention that I'm
not even going to get near claiming knowing the kernel's guts anywhere
as much as you do :)

Here's running the risk of comparing apples to oranges:
$ ll adeos-linux-2.6.11-i386-r10c3.patch realtime-preempt-2.6.12-rc4-V0.7.47-07
-rw-rw-r--    1 karim    karim      195105 May 24 10:19 adeos-linux-2.6.11-i386-r10c3.patch
-rw-rw-r--    1 karim    karim      610509 May 24 00:14 realtime-preempt-2.6.12-rc4-V0.7.47-07

> anyway, as always, the devil is in the details. I certainly dont suggest 
> that nanokernels/hypervisors are not nice (to the contrary!), or that 
> all component technologies of the -RT patchset will be accepted into 
> Linux. PREEMPT_RT started out as an experiment to reduce scheduling 
> latencies within the constraints of the Linux kernel. It is not an 
> all-or-nothing feature, it's more of a collection of incremental 
> patches. It is one, nonexclusive way of doing things.

Here's from a previous posting back in october:
> development pace. Let's face it, no self-respecting effort that has
> ever labeled itself as wanting to provide "hard real-time Linux"
> has been active on the LKML on the same level as Ingo (though many
> have concentrated a lot of effort and talent on other lists.)

Clearly I recognize the work you have accomplished, and you are correct
in stating that the approach is nonexclusive. If the patch does indeed
make it into the kernel, then so be it. It's worth considering though
that there are other methods which can provide hard-rt without increasing
the kernel's complexity even when enabled; the most basic of which would
be turning the interrupt-handling/disable to function pointers. At the
next level, you could have something like the interrupt pipeline from
adeos on top (possibly as a loadable module), and at a third level you
could have something like RTAI/fusion (as additional loadable modules) ...

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/