You are here

I thought now was the right time to sum things up a bit as far as kernel development status is concerned…

  • Bootstrapping – Done.
  • Memory allocation – Done, but no user-mode interface yet
  • Processes, threads, and inter-process communication – In progress. Multitasking will require clock interrupt handling, syscall interface to IPC will require user interrupts management. Executable loading will probably be one of the last kernel features to be completed.
  • Interrupt management – Cannot progress, requires processes and IPC
  • I/O ownership and other security token subsystems – Requires processes

As can be seen, all these services are heavily dependent on each other in a crazily messy fashion, but globally, in true respect of the microkernel tradition, we need a bit of processes and IPC before we move any step further in other areas. Interestingly enough, completing process management will also require advances in these other areas. This pushes further my belief that all these kernel components are fundamentally entangled and shouldn’t be separated from each other through extra isolation.

Advertisements

4 thoughts on “You are here

  1. Tom Novelli May 31, 2011 / 4:29 pm

    Hehe, I see you’ve encountered a limitation of microkernels. I was gonna say you’re crazy to develop one (I’ve decided not to do any isolation in my hobby OS, for simplicity’s sake) but it’s starting to make sense. Yeah, combine the core services into one module, because you don’t gain much by isolating them — if one fails, the system is hosed.

    3rd-party drivers, on the other hand, should definitely be isolated. I have a lot of trouble with the Linux NVidia and ATI drivers (proprietary and open-source alike). A microkernel would not solve everything, though. Currently it’s my X server process, not the kernel, that’s getting hosed (badly enough to require a reboot) by the part of the NVidia driver that’s an X module. X, like Linux, is modular-monolithic.

    I’m no microkernel expert, but I suspect that if microkernels with really good IPC were the norm (rather than Windows and Linux), we’d be looking at a very different landscape today… X and everything else would use the microkernel isolation/IPC facilities. I wonder if that’s how OSX does it? That’s the only major consumer OS that I’m aware of with a substantial track record using a microkernel.

  2. Hadrien May 31, 2011 / 5:03 pm

    Hehe, I see you’ve encountered a limitation of microkernels. I was gonna say you’re crazy to develop one (I’ve decided not to do any isolation in my hobby OS, for simplicity’s sake) but it’s starting to make sense. Yeah, combine the core services into one module, because you don’t gain much by isolating them — if one fails, the system is hosed.

    Heh :) It is an annoying truth that some system services require to break through the system isolation facilities to work. The parts that manage processes, threads, IPC, and security, noticeably, do. So no benefit is gained by putting them in isolated processes, and it’s better to put them together in the kernel binary. On the other hand, when it can be afforded, putting things in small isolated modules is truly a good thing.

    3rd-party drivers, on the other hand, should definitely be isolated. I have a lot of trouble with the Linux NVidia and ATI drivers (proprietary and open-source alike). A microkernel would not solve everything, though. Currently it’s my X server process, not the kernel, that’s getting hosed (badly enough to require a reboot) by the part of the NVidia driver that’s an X module. X, like Linux, is modular-monolithic.

    I don’t believe in the idea of code injection in system services, as done with X modules, for a number of reasons, but noticeably because it breaks the process isolation. In my opinion, something like X should simply draw on a frame buffer that’s provided by the driver. The driver then does what it has to do to display the frames on the screen, without the OS’s display manager having to care about it. In such an isolated design, system services keep a consistent behavior, and excellent reliability : the only thing that can fail when introducing a new driver is the driver itself.

    I’m no microkernel expert, but I suspect that if microkernels with really good IPC were the norm (rather than Windows and Linux), we’d be looking at a very different landscape today… X and everything else would use the microkernel isolation/IPC facilities. I wonder if that’s how OSX does it? That’s the only major consumer OS that I’m aware of with a substantial track record using a microkernel.

    The kernel of Mac OS X, XNU, is not a microkernel but an hybrid kernel, which means that it is a monolithic kernel that tries to be a bit less monolithic than the others. In the Mac OS X kernel, on may noticeably find a network stack, file systems management (including networked ones), cryptographic functions, and drivers for mass storage devices, graphics, USB and Firewire… We’re pretty far away from the “each isolated process does one thing and does it well” philosophy, there.

  3. Tom Novelli May 31, 2011 / 5:44 pm

    Ah, so OSX isn’t based on L4 as I thought. XNU actually sounds like Linux, which started out monolithic, added loadable modules early on (circa 1993), then gradually began shifting kernel modules into userspace where it was feasible. Taken to the extreme, I suppose Linux could evolve into a microkernel… after all, it’s already got lightweight processes compared to Windows.

    It seems like X is gradually being rewritten around OpenGL, which is (in an abstract sense) a message-passing IPC protocol for drawing on framebuffers in GPUs. Then there’s Wayland which is apparently built from the ground up on OpenGL. Seems like the right direction. It’ll probably be 2020 by the time everyone gets there :(

  4. Hadrien May 31, 2011 / 5:46 pm

    OSX’s kernel is based on a Mach core, but with *lots* of added kernel functionality.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s