Hacker News new | past | comments | ask | show | jobs | submit login
Where rump kernels are heading (gmane.org)
57 points by mrry on Aug 27, 2014 | hide | past | web | favorite | 11 comments



History lesson:

The earliest "Operating Systems" as we call them today were developed at General Motors. The system was a standard stack of punch cards that would be executed with every program to take are of environmental tasks, provide a standard library, and standard I/O functionality.

This system was built for the IBM701 in '56, but was used on all 40 IBM704's that were sold. It influence the development of a lot of early 50's and 60's OS's nobody ever heard of now-a-days. Namely the Michigan Terminal System, which was very big and never spoken of.

This was still a batch processing operating system. But it was a far cry from the automatic tape switching Univac had only 2 years earlier!

Literally a rump kernel.

:.:.:

The ultimate problem with rump kernels is looking into the future, we arrive back at Unix. Follow the thought experiment.

1) We reach a standard rump kernel for virtualization, that support most users needs.

2) Its declared an industry success and sees wide deployment.

3) In order to speed up its functionality hypermanagers are ran on native rump kernels.

4) In order to speed up its functionality hypermanagers have rump features built in.

5) Duplicate rump features exist in the hypermanager, and its (the hyper-manager's) own rump kernel.

6) rump kerenels and hypermanagers are re-merged to multi-process OS's to remove duplicate code and offer speed ups.

What we need is a more multi-process OS, not a multi-user + multi-processing OS.

TL;DR we are back pedaling.


Oh thank god I'm not the only one who thought this.

"Lightweight" is a term that gets used a little too much these days, to the detriment of actual useful functionality.

If smartphones and Docker/LXC are teaching us anything, it's that the solution is to improve our operating systems and make them better at the things they were intended to do.


The idea of rump kernels is to make existing kernel driver implementations available in environments beyond the original [monolithic] kernel they were written for. The idea is not to figure out some perfect structure for an OS. There is absolutely no intention to back pedal to historic systems which lack the drivers to operate with real world of today.


In other words, thesis -> antithesis -> synthesis.


One of the most useful ideas behind rump kernels, from what I can see, is as a technique rather than an end result: it's a great example of how filesystem drivers or other typically privileged code can be reused in a lesser privileged context or even across operating systems and/or architectures, with minimal effort.

This seems like mostly speculation on a mailing list, but I believe it's worth pointing out that this speculation doesn't do justice to what rump kernels can already offer. It would be nice to see other OS developers push models like this, to facilitate code reuse in widely varying contexts, instead of just "hypervisors".


This is going to sound sassy, but it's not _entirely_ meant to ---

Follow the thought experiment:

1) valarauca1 comments on rump

... [stuff goes here]

n) valarauca1 is dies

Is there a point to _anything_, if you use "following to logical conclusion" as measuring stick? We can't tell what will come of this work yet.

-bch


I understand what your saying, an I agree. its the journey not the destination that makes scientific progress worth it in the end.

But a lot of the "Rump Kernel" theory sounds like.

"I need a car with less features, and high performance."

"Okay, lets start with re-inventing the wheel, its the logical place to start. We'll build ground up and move from there."

"I was gonna start pulling the head lights off."

"Nonsense! We must start fresh!"


No part of the rump kernel is about reinventing the wheel. It is about reusing existing OS code in other situations. So I don't exactly follow. This was a mailing list post so didn't have all the background...


To answer the more general point, your (n) doesn't follow from (1). valarauca1 was already going to die, regardless of whether he/she commented on rump kernels, so that's not an example of taking things to their logical conclusion, and doesn't work as an argument against it.

There's only "a point to anything" in the context of external goals. When trying to satisfy one of those goals, it's almost always beneficial to take your assumptions and logic to their conclusion, because that's what reality, and (more relevantly) groups of people, do with their logic.


Can you explain how 3 & 4 work? Don't you need a context switch boundary to go from a hypermanager (hypervisor?) to a guest OS? If so, then is doing away with context switching (i.e. all ring 0) inside the Guest OS an I/O win? Or maybe I misunderstand?


I hope the rototill metaphor isn't lost on anyone. That's a metaphor worth saving.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: