Messages in this thread |  | | | Date | Sun, 29 May 2005 14:23:44 +0200 | | From | "Brian O'Mahoney" <> | | Subject | Re: RT patch acceptance |
| |
Also, the u-kernel has been tried, MACH & Chorus, and even the real NT core, as opposed to the Win32 API skin, and has not worked well yet.
James Bruce wrote: > Nick Piggin wrote: > >> But nobody has been able to say why a single kernel is better than a >> nanokernel. > > > I think it's a bit more like you haven't realized the answer when people > gave it, so let me try to be more clear. It's purely a matter of effort > - in general it's far easier to write one process than two communicating > processes. As far as APIs, with a single-kernel approach, an RT > programmer just has to restrict the program to calling APIs known to be > RT-safe (compare with MT-safe programming). In a split-kernel approach, > the programmer has to write RT-kernel support for the APIs he wants to > use (or beg for them to be written). Most programmers would much rather > limit API usage than implement new kernel support themselves. > > A very common RT app pattern is to do a bunch of non-RT stuff, then > enter an RT loop. For an example from my work, a robot control program > starts by reading a bunch of configuration files before it starts doing > anything requiring deadlines, then enters the RT control loop. Having > to read all the configuration in a separate program and then marshall > the data over to an RT-only process via file descriptors is quite a bit > more effort. I guess some free RT-nanokernels might/could support > non-RT to RT process migration, or better messaging, but there's > additional programming effort (and overhead) that wasn't there before. > In general an app may enter and exit RT sections several times, which > really makes a split-kernel approach less than ideal. > > An easy way to visualize the difference in programming effort for the > two approaches is to take your favorite threaded program and turn it > into one with separate processes that only communicate via pipes. You > can *always* do this, its just very much more painful to develop and > maintain. Your stance of "nobody can prove why a split-kernel won't > work" is equivalent to saying "we don't ever really need threads, since > processes suffice". That's true, but only in the same way that I don't > need a compilier or a pre-existing operating system to write an > application. > > - Jim Bruce > - > 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/ > >
-- mit freundlichen Grüßen, Brian.
Dr. Brian O'Mahoney Mobile +41 (0)79 334 8035 Email: omb@bluewin.ch Bleicherstrasse 25, CH-8953 Dietikon, Switzerland PGP Key fingerprint = 33 41 A2 DE 35 7C CE 5D F5 14 39 C9 6D 38 56 D5 - 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/
|  |