Hi, With the bare metal platform running smoothly both on actual hardware and popular hypervisors, now is a good time to see where we are and where we're going. In addition to facts, this mail contains some envisioning.
My prediction is that over time the significance of operating systems as we know them will diminish. I expect that as we move more and more from computers to computing devices and the cloud, more and more people will realize that they are running traditional operating systems only for drivers, and simply do not need an operating system. The need for drivers will of course remain, as they are needed to interoperate. What I do not believe will go away either are, for better or worse, the POSIX-like application interfaces, at least not for a very long time. There is simply too much software for that environment to start rewriting it from scratch. About a year ago, rump kernels had solid support for POSIXy userspace platforms and offered the syscall interface. Since then, not only have we seen support for multiple different and different types of platforms (more on that later), but also going from offering just the syscall interface to an almost full POSIXy application interface. That's quite a leap! Of course, the whole "userspace" part of the rump kernel stack (*) is still completely optional, giving a good degree of flexibility. *) by "userspace" I mean the three top boxes in this diagram: http://ftp.netbsd.org/pub/NetBSD/misc/pooka/images/baremetal-rumpstack.png I like to think of rump kernels as being capable of running on four different kinds of platforms: 1) hosted, e.g. userspace 2) paravirtualized, e.g. Xen 3) "bare metal", e.g. hardware or hypervisor with virtio 4) microkernels (as servers) The lines between the four are not always completely clear, for example the "microkernel" approach I have most experience with is running drivers as userspace servers on NetBSD, which clearly falls also into "1". I'll not go into technical details and thread splitting in this mail, but the above taxonomy gives at least some indication. All of the above puts rump kernels in a pretty sweet spot. We get all of the reuse potential of kernelside drivers, POSIXy userspace interface and, though we're not providing it directly, everything else commonly thrown in userspace. All of this is up for liberal chopping, mixing and blending by users building applications and products on top. As was demonstrated with the bare metal platform, you can literally write a case-specific OS in a week when you don't have to worry about porting or hacking drivers. In that respect, I see rump kernels more of as an enabling technology instead of the end result. So what's in store for the future, then? As far as I am concerned, there are no big rototills immediately coming up. Instead, in the near term we, or at least I, will concentrate on application use cases and improving usability. For the past year, we have been trying to figure out how to implement a rough idea. The rough idea is starting to look clearer, and a rough (but working) implementation exists too. Now all that remains is polishing. The good thing about polishing is that people familiar with Makefiles, build processes and shell scripts on regular operating systems will find themselves right at home; it's a convenient gateway for exploring the transition from the old style of OS to the new style of lack of OS. As an example of something to investigate, a few people have suggested hosting rumpkernel.org website on a rump kernel (well, the future hopefully-soon-to-be-website). In addition to the obvious eat-our-own-dogfood value, the lessons learned from such an operation would be invaluable in helping others repeat a similar operation. cheers, antti ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
