![]() | |||||||||||||
Messages in this thread |
* 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/ | ||||||||||||
| Last update: 2005-05-24 17:32 [from the cache] ©2003-2008 | |||||||||||||