Re: RT patch acceptance

[Ingo Molnar <mingo@elte.hu>]

* 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
-
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/