CS423 Project Proposal

Andy Reitz, Chris Lattner, Fredrik Vraalsen, Keith Wessel
October 2nd, 2000

Background

CORBA is increasingly becoming the defacto standard for distributed object systems. CORBA bindings are available for a wide variety of languages, and an even wider variety of operating systems. One widely addressed barrier to CORBA acceptance on a broad scale is the performance implications of using the system. Invoking a method on a CORBA object may imply many context switches between the user-level client application, the operating system kernel, and the user-level server. Remote calls have an even higher overhead, even beyond "pushing bits onto the wire".

We have stumbled across the following quote from Michi Henning, which summarizes some of the advantages of an in-kernel CORBA Orb:

Some more idle musings... Suppose for a moment that CORBA is built into the OS kernel and that OS objects, such as segment descriptors and inodes are CORBA objects that are addressed via object references. Suddenly, a whole new world opens up. For example, there would be no need for distributed file systems such as NFS, RFS, or DFS (which are just more application-level protocols for a specific purpose, namely file sharing). Instead, all file systems would be automatically distributed, almost by accident. You could share files at any level of granularity, down to a single file, simply because they are individually addressable by object references (instead of having to export sub-trees of a file system).

If we had segment descriptors that are CORBA references, shared memory could transparently be accessed over the network, without the need for another protocol.

-- Michi Henning

Proposed Project

We propose designing a Linux Kernel module that implements ORB services in kernel space. This would involve either porting a preexisting ORB from a user-level application to a kernel module; or it would involve rewriting an ORB core from scratch (obviously if we took this approach, we would not be interested in implementing the entire CORBA 2.2 standard). Given a kernel ORB, several interesting sub-projects are possible:

  1. Refactor and expose traditional system calls as CORBA method invocations:

    2. This would involve sorting the preexisting linux system calls into various sets of functionality (for example, filesystem management, process management, memory management, i/o management, etc...), and defining an interface for each functional group. A set of "adapter objects" would then be constructed, which conformed to this interface, and perform the necessary functions by making calls to existing Kernel methods. Another kernel module would be written to expose these kernel services to the Kernel ORB, thus providing a somewhat "object oriented" operating system (at least to the user-level applications).

  2. Map user level system calls onto the CORBA system entry points:

    3. Once the system calls are refactored, it would be "relatively easy" to implement a custom libc library that maps, for example, the 'open' system call into 'DefaultFileSystem.open(...)'. This would effectively cause every system program to use (and test) our entry-points and the Kernel ORB. Note that this would certainly reduce performance over direct system calls.

  3. Allow the "DefaultFileSystem" object to point to a remote machine:

    4. Once applications are using object oriented kernel services (either automatically through library magic, or by explicitly invoking CORBA objects), a simple extension is to reference objects on remote machines, instead of the local machine. One very straight forward thing to do would be to change (through an environment variable, for example) the DefaultFileSystem object that is used to perform file operations. This object may be changed to point to a remote machine, or it may be changed to a "virtual" filesystem (for example, a virtual FTP filesystem on a non-CORBA'ized remote host). Then, when a CORBA-ized application was launched on the client, this environment variable could be checked, and the application could then make use of the specified filesystem transparently.

  4. Implement new OS functionality in the object oriented way:

    5. Once language neutral object oriented services are available in the kernel, it makes sense to implement kernel functionality in an object oriented way. Although we are not advocating rewriting the entire kernel, it may be feasible to rewrite (for example) a serial driver so that the mouse may be CORBA'ized and exposed more directly to user-space.

Tasks Involved

  1. Port an ORB into the Linux Kernel:

    2. This would be the most time consuming and risky (in terms of completion) portion of the project. The major questions here are: What ORB should we use? What kernel version should we work on (2.2 or 2.4)? How much functionality belongs in the kernel? What GIOP derivative should we use to interface between user and kernel space?

  2. Implement some of the possibilities mentioned above:

    3. We believe that it would be unrealistic to think that we can accomplish all of the above mentioned sub-projects (because we anticipate spending most time on the ORB), but we will implement at least one of the sub-projects. At least one subproject needs to be completed for testing purposes, and also in order to demonstrate that the Kernel ORB works. Therefore, we would like to focus on the DefaultFileSystem example above. Furthermore, we plan to spend our time primarily on functionality, not performance tuning. This project is primarily meant as an "investigation". We wish to examine how an in-kernel CORBA ORB would work, and what the benefits/detractions of such a scheme would be.

Division of Labor

Initially, the division labor will look like this: Once an in-kernel ORB is working, it will be much easier to split up the work.

Relevance to CS 423

We are attempting to improve operating system integration with object oriented technologies. Current technology is (arguably) not ready for entirely object oriented operating systems (most commonly used, performant OS's today are monolithic in structure), but that time is getting closer ever day. Bringing CORBA into an operating system kernel would bring all of the benefits of CORBA to the operating system (language neutrality, introspection, more uniform interfaces, exceptions, etc...) and also the benefits of the kernel to CORBA (performance, integration). In addition, we look forward to working on a real "production" operating system.

References

  1. kHTTPd: Linux HTTP Accelerator - Kernel HTTP server.
  2. Kernel NFS Daemon Maintainer's Page - Kernel mode NFS server.
  3. A New Protection Model for Component-Based Operating Systems - Mentions putting an ORB system into a kernel (not CORBA however).
  4. CORBA and Object Technologies - Christopher Browne's page of CORBA references, contains the cited Michi Henning quote.