Re: RT patch acceptance

Ingo Molnar
2005-05-24T15:25:46Z

* Karim Yaghmour <karim@opersys.com> wrote:

> I've visited these issues before. It all boils down to a simple
> question: is it worth making the kernel so much more complicated for
> such a minority when 90% of the problems encountered in the field
> revolve around the necessity of responding to an interrupt in a
> deterministic fashion?
>
> And for those 90% of cases, a simple hyper-visor/nanokernel layer is
> good enough. For the remaining 10% of cases, that's where something
> like the rt-preempt or RTAI become necessary. [...]

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.

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.

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.

Ingo