GNOME ORBit Ported To Linux Kernel

Lennie writes: "Some crazy people did this for fun; let's hope it stays that way. There is enough kernelbloat already (or have you been able to compile a 2.4 kernel as zImage?). Nonetheless, lots of fun I'm sure." Of all the ridiculous things, this has got to be at least three of them. Actually the worst part is that I kinda could see this as being useful. I think I'm broken.

Maybe I read a different article...

This isn't an attempt to get orbit running faster by moving it into kernel space. This is a functionality hack - orbit won't run in kernel space, the kernel API will be made available to corba clients.

I'm not sure if I like it or not - the functionality is cool, but the possibility of destabilization is pretty high, and there are lots of security issues.

Re:why not?

> The initial reaction here seems to be that this is a bad idea. But what's wrong with bringing a object request broker architecture to an essentially monolithic kernel?

Nothing, but they didn't bring an architecture to the kernel, they just ported ORBit to it. Grafted it in with duct tape and baling twine, really. I don't even see anything valuable coming out of this as a side effect, such as a generic userland/kernel IPC interface like STREAMS or FreeBSD netgraph, just some libc compatibility macro hacks ... *shudder*

Oh well, everyone's entitled to their own fun projects.

--

Excellent.

That is very cool.

With this, and khttpd and the frame buffer support and just a few other patches, I might not have to run in userland ever again!!

Just like DOS!!! ;)
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].

why not?

The initial reaction here seems to be that this is a bad idea. But what's wrong with bringing a object request broker architecture to an essentially monolithic kernel? It seems to me that if it can perform well, the added modularity might actually be a huge step forward and might be a nice alternative next to the existing module architecture (sort of a primitive object request broker). One of the immediate advantages is that C is no longer required (but still allowed) for doing kernel programming.

But then, i'm not a kernel hacker.

Re:Gnome...

"So, Gnome, what are we going to do tonight?"

"Same thing we do every night, Pinky, try to take over the kernel!"

Kernel "bloat"

I haven't really looked much at the kernel, but puting aside for a second stability and security issues, is a large kernel really so bad?

If there actually is bloat, in the form of unnecessary or poorly written code, that's unquestionably bad, but if there's simply a lot of cool things being put into the kernel, that doesn't strike me as bad. You can always recompile, thereby stripping your kernel down to just what YOU need.

I know, I know, the average desktop user isn't going to have the skills to recompile a kernel, but that's okay. Whether a user's kernel is 2 megs or 200 megs, they've probably got enough HD space to fit it. The situations where kernel size matters are probably going to be small devices (pda's, palmtops, etc.), and old devices (486). Small devices generally have customized OSes anyway, so you can expect that the manufacturers will take care of that. Old devices are probably better off running older software, so I'm not too worried about them.

I probably missed a few things, again I'm not a kernel expert. Plus, the security and stability issues are not trivial, and are a big strike against a project like this. But, any other reasons why this is bad?

Sounds good for...

This idea sounds good for:

1. Remotely debugging device drivers

2. Security holes

HURD

The HURD is apparently going to offer CORBA as the primary means of inter-proccess communication. And due the HURD's micro kernel architecture it can probably be done without the bloat of having an orb compiled into a monolithic kernel.

A few clarifications about kORBit...

Hey all, here's a few responses to the feedback we've received so far, hopefully this will clear up some of the FUD:

1. NO, we do not expect this to go into any mainstream kernel any time soon. :)
2. YES, this is an awesome way to play with and prototype kernel functionality in user space.
3. NO, this does not work with other OS's. Although, there is no fundemental reason why it cannot be ported... again.
4. YES, this does mean that if it was ported to other OS's that you could trivially write portable drivers.
5. NO, we are not planning on porting GNOME to the kernel. :)
6. YES, SOME user space code can do good things in the kernel, particularly network-centric code. Think kHTTPd or kNFS.
7. NO, at least not without some redesign of GNOME, this will not make GNOME/bonobo faster.
8. YES, security can definately be improved [err, well, ahh, be implemented? ;)]. We have one proposal from Miguel de Icaza on improving the security to the point of NFS. Other schemes could definately be implemented, we just haven't started thinking about it.
9. NO, this does not "severely bloat your kernel", it adds about 150k of space when compiled in debug mode. This is still a very alpha version, btw, and there is still a lot to reduce out.
10. YES, you can now write your device drivers in C++. :)

Anyways, if you have any other questions, feel free to contact us. [mailto] :)

-Chris

Linux: it's not a microkernel

... but it plays one on TV.


________________________________________

Re:Excellent.

The HURD is not designed for speed. That immedietly makes the OS crap in my view.

Do you mean that they are not taking speed into account at all? Or maybe that they are completely ignoring any concerns for efficiency?

Or do you maybe mean that they simply are not making speed their number one concern?

Could it be that speed (or perhaps efficiency), while important, is not the only factor to consider (as so many here seem to think it is) -- that in some circumstances it might reasonable to sacrifice some efficiency for other factors such as maintainability -- ease of implementing new deamons, etc. The age old sacrificing some comptuer resources for human producitivity.

How much of a difference are we talking about here? A few (or some number of) percent, or an order of magnitude?

Distributed OS

It's an interesting experiment in creating a distributed operating system, but it's certainly nothing to put on your production system. Give it a few years (assuming people are willing to actually explore this) and it just might be something Tanenbaum would put in his next book (or maybe not). I also gotta wonder what the performance hit is, when the module you want is on the same machine requesting it, vs the non-Corba kernal (obviously if the module is on anther machine, you've got to deal with network latencies).
cb

Re:This is kinda cool...

This is a cool attempt.. for one thing it shows how flexible the linux kernel is.

Um... Not really. It's almost trivial to put something inside of something else [indiana.edu], as long as you write good interfaces. And the more 3rd party code you accomodate, the more risk there is of unstable code crashing the system, or of security breaches.

If necessary, kernel interfaces to userland programs [linuxdoc.org] are probably the best way to go, but even then you're not necessarily safe [attrition.org]. Remember: try to run code as an unpriveleged user at first, then as root if necessary, but only in kernel space as a last resort.

but it would be funky having device drivers loaded from anywhere using this technology!

Like Jini [sun.com]? I hope you're not suggesting we embed the JRE into the kernel! That would be grotesque, despite the niftiness... No! No niftiness! Don't tempt me! Back!

--

boo hiss

The closer Linux gets to being more like windows the more bloated and unstable it becomes. and yet even most Linux users must admit with every release of windows, windows suck less and less. Linux kernel hackers aka "people with too much free time on there hands" are only too willing to overload the kernel with unnessasary crap. i'll give credit where credit is due, MS knows that some think windows suck and they actively go out to make it work better. that takes direction, the kind that Linux currently lacks.

Corba != GUI

> wouldn't be the first OS to more closely tie the GUI to the kernel.

I shouldn't have to say this here, but CORBA has nothing to do with GUIs, except that it is a necessary service for Gnome's particular architecture.

This article is good news because it allows the ORB to be used in non-gui contexts. I'm not saying that it should be part of the kernel, but it should and can be decoupled from GNOME. Modularity. Reusability. Flexibility. These are all good things.

This Is Actually Cool

I know most people will shudder, but this is possibly great news for Linux on the desktop.

If more and more of the infrastructure of a desktop environment (like GNOME) could be moved into kernel space, it wouldn't be the first OS to more closely tie the GUI to the kernel. As long as all the pieces are stable and the whole operation was well thought out (admittedly, not a trivial expectation for Linux code) it would surely mean a more integrated (and speedy) desktop. There's alot you can't do with a GUI in UNIX because of the rift between userland and kernelland.

Imagine...GNOME/Linux on store shelves, with a custom kernel patched to take advantage of this. GNOME bigots, I can hear you gagging, but noone really cares ;-).

Mercster

But is this really bloat?

I don't think a kernel ORB would be bloat. If anything, it could lead to a [em]de-[/em]bloating of the kernel, because it would allow us to remove things that really don't belong in the kernel. You know, things like khttpd and that sort of thing (I'm sorry, but a Web server is no more an integral part of the OS than a Web browser).

In addition, it would allow for a much more robust and powerful way of extending the kernel. This is a Good Thing, because the componentized architecture makes sure that this can be done without introducing instability. This is less of an issue in an Open-Source kernel than it is in a closed-source one, of course, but it's still an important advantage that should not be overlooked.

ORBit itself has the advantage of being small. This is a big thing, since it minimizes size bloat. Its performance is also pretty good (though it could use some improvement), and would get faster in kernelspace. This is also a Good Thing. However, there's the distinct problem that it needs better testing for security issues; something of this complexity can't be allowed into the kernel until it's rock solid for obvious reasons.

But overall, I say go for it. The potential benefits of CORBA in the kernel are simply too great to ignore.
----------

Re:Linux microkernel

If you think I'm wrong, look at NT... it's all abstracted.

Well, NT used to be abstracted. NT is a sad story, really. Micros~1 got a whole bunch of top-notch engineers (Dave Cutler, the VMS guy, being probably the most famous one) and told them to make the next-generation OS.

The engineers were gung-ho about it, and designed it to be modular, abstract, and machine-independent. Management, however, was actually against these attributes and turned NT into something much less wonderful. NT used to run on x86, Alpha, MIPS, and PPC, but those were gradually killed off so that only Intel remains.

Heh, I got most of this info from a book I was browsing at the story but didn't have the money to buy. I wish I had; NT is one of the great tragedies of our day.

--

Linux in education

What a great platform Linux is for as both an teaching aid and as the basis for experimental work. All CS departments should adopt Linux as the basis for their operating system courses since it allows exactly this sort of experimentation.