Chris Lattner: Linux Kernel ORB: kORBit

From: Chris Lattner 
To: linux-kernel vger kernel org, orbit-list gnome org
Subject: ANNOUNCE: Linux Kernel ORB: kORBit
Date: Fri, 8 Dec 2000 17:10:47 -0600 (CST)

This email is here to announce the availability of a port of ORBit (the
GNOME ORB) to the Linux kernel.  This ORB, named kORBit, is available from
our sourceforge web site (http://korbit.sourceforge.net/).  A kernel ORB
allows you to write kernel extensions in CORBA and have the kernel call
into them, or to call into the kernel through CORBA.  This opens the door
to a wide range of experiments/hacks:

* We can now write device drivers in perl, and let them run on the iMAC
  across the hall from you. :)
* Through the use of a LD_PRELOAD'd syscall wrapper library, you can
  forward system calls through CORBA to an arbitrary local/remote machine.
* CORBA servers are implemented as Linux kernel modules, so they may be
  dynamically loaded or unloaded from a running system at any time.  CORBA
  servers expose their IOR's through a /proc/corba filesystem.
* Filesystems may be implemented as remote CORBA objects and mounted on
  the local machine, by using 'mount -t corbafs -o IOR:... none /mnt/corba'

This are just some of the features available _RIGHT_NOW_ that are
supported by kORBit.  I'm sure that YOU can think of many more.

Implementation:
We implemented this port by providing a user->kernel mapping layer that
consists of providing standard system header files for the "user" code to
#include.  In these header files, we do the mapping required.  For
example, we implement a <stdio.h> that #defines printf to printk (as a
trivial example).  Only user level code sees or uses these wrappers... all
of our modifications to the Linux kernel are contained within the
linux/net/korbit subdirectory.  

This is currently implemented with a 2.4.0test10 kernel, although forward
porting should be very easy.  This project was implemented as a cs423
semester project by Chris Lattner, Fredrik Vraalsen, Andy Reitz, and Keith
Wessel at the University of Illinois @ Urbana Champaign.

Unresolved issues:
* Our poll model is not optimial.  Currently we actually do a real poll on
  a (struct socket *) set.  This causes relatively high latencies (on the
  order 1 second, worst case) for CORBA requests.  Our waitqueues are not
  working quite as well as they should.  :)
* Security is completely unimplemented.  Someone could use corba
  interfaces to read any file on your system, for example (if the
  CORBA-FileServer module is installed).  Thus, this is really more for
  prototyping and development than actual real world use. :)

If you have any questions or comments, please feel free to contact us at:

Chris Lattner, Fredrik Vraalsen, Andy Reitz, Keith Wessel

korbit-cvs@lists.sourceforge.net


btw, yes we are quite crazy, but what good is it to be normal and
conformist afterall?  :)