![]() Well, its my driver/service architecture: each driver and service runs and does its part until it reaches *receive* in the main loop again. Well - they *need* to be delivered as fast as possible and doing so in a quick way without doing lenghty queries of services is a nice thing.Īs you see, you *need* to take care of who preempts whom in kernel land: it makes no sense to have a page fault and the pager canna jump to life because floppy driver writes in to exactly the kind of nirvana which has invoked the pagefault handler. Although, I have implemented a second interface for direct kernel calls - as a means to handle semaphores and signals/events. To my experience having low control paths in kernel land are a very good thing. (dunno wether this is a good thing (tm)). Userprocesses are queued in a priority based round robin queue. MMsrv main process & MM thread: preempt every other service process and user processes So each thread preempts the ones of lower priority: this means, that in BlueIllusion a strict pyramid of who preempts whom exists:ĭrivers: preempt services and user processes Well, my drivers are threads in kernel space, everything else which does the management stuff - is a process of its own - with small little threads inside. I'm actually developing a micro kernel - well many design quirks, many things one does because he does such a thing the very first time and lacks time to *think* properly.Ĭoncerning the issue of preempting the microkernel itself: My brain got stuck in an infinite loop while trying to design the memory manager.Top three reasons why my OS project died: I'm not really looking for a clear-cut answer here, more of a general discussion. Not specifically aimed at real-time stuff, but low latency is important for general responsiveness. ![]() Implemented on x86 initially, but will be portable.It seems to me that this is an important design decision to make early, since it affects the way control flow in the kernel is structured.įinally, a bit of background on my design goals: Opinions.? Is it worth the added complexity? But I thought pre-emption would be sort of redundant for a microkernel. what gives? It makes sense, given that it's a real-time OS and has to make pretty strict latency guarantees. However, the latest version of Neutrino (which still qualifies as a microkernel AFAICS) is pre-emptible. I remember reading something to that effect in the documentation for an older version of QNX Neutrino ( Unfortunately, that doc is now in the great bit bucket in the sky. The idea being that microkernels are supposed to have such short code paths, that the cost of these paths being non-preemptable, in terms of latency, is negligible. This leads me to the conclusion that one of the main benefits of the microkernel approach is its simplicity. Likewise, the additional design work that has to be done to get a microkernel design right could also be spent on making a monolithic kernel preemptable.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |