Providing a pervasive distributed object system at the kernel level opens a number of possibilities to to both users and application developers. From the user's perspective, a distributed object system allows the use of remote machines with the same interface as provided by the local machine. This makes access to remote systems transparent, so that the user doesn't need to waste any brain power (a most precious resource!) to take advantage of remote resources. From a developer's point of view, placing a distributed object system in the kernel means that it will become a standard system service, which is present on every machine (running that brand of kernel, anyway). Furthermore, an in-kernel system provides a fixed API for which to develop.
Because there are numerous advantages, we have decided to place a CORBA-compliant Object Request Broker (ORB) into the Linux Kernel. We plan to take an existing ORB, refactoring it as a Linux kernel module, so that it may reside in kernel space. We believe that this system will provide the advantages described above. This document will lay out the major design obstacles and features of this idea. In Section 2, we go through our choices of ORB and kernel versions. Section 3 mentions various use cases for the kernel ORB, while section 4 describes the structure of the chosen ORB and identifies pieces that need to change to fit into the kernel. Then in section 5 we discuss the specifics of how we will integrate the ORB into the kernel. Section 6 presents an example application that demonstrates the usefulness of the kernel ORB.