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.

Comments

Excellent.

[pb]

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.

why not?

[jilles]

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.

A few clarifications about kORBit...

[sabre]

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. :)

-Chris

Re:This is kinda cool...

[vsync64]

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, 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 are probably the best way to go, but even then you're not necessarily safe. 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? 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!

--

But is this really bloat?

[Millennium]

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.
----------