In this section we describe the status of K42, describe work related to K42, and finish with a performance evaluation of K42 and Linux running the SPEC SDET benchmark[2].
K42 is available under an LGPL license and a CVS (Concurrent Version System) source tree is available. Directions on how to obtain it at are available at https://www.research.ibm.com/K42. An early version of a complete environment including build infrastructure, debug tools, a simulator, and source is available as of March 2003.
The modular structure of the system makes it a good teaching, research, and prototyping vehicle. Policies and implementations studied in this framework have been transferred into Linux. For example, a kernel scalable queue lock originally designed in K42 was transferred to Linux, RCU[22] is similar to the safe memory and garbage collection in K42, and lockless scalable tracing technology has been integrated into LTT[26]. K42's framework will allow continuing technology transfer.
K42 currently runs on PowerPC (SMP) hardware and simulators (SimOS and Mambo), and is being ported to x86-64. As stated, K42 is fully functional for 64-bit applications, and can run codes ranging from scientific applications to complex benchmarks like SDET to significant subsystems like Apache. Currently, K42 can directly execute 64-bit binaries compiled for Linux, and soon will be able to do the same for 32-bit binaries.
There are still some missing holes in K42's full Linux compatibility. There are system calls with unimplemented (less common) cases. For example, mmap protection only works on common cases. We have not yet implemented /proc (except for ps, this is primarily an impediment only to running administration tools). Our approach has been to add additional Linux functionality as applications require it. In some sense, K42 will never be fully one hundred percent compatible. We do not intend to be bug compatible, in fact, stack overflows and other such error conditions should they occur would be at different places in K42 than in Linux.
Although Linux is currently the only personality K42 supports, the base K42 mechanisms would allow support of other interfaces as well. Other flavors of Unix such as AIX and BSD would be fairly easy to support. Most of the challenging technical work is already in place. There would still be considerable detailed work to be done in ensuring structures get correctly translated. For example, getting the exact semantics and contents of the stat structure correct on such systems can be difficult because the structure is different under each of the Unix systems mentioned above. Other potential challenges involve providing dynamic linking for systems like AIX that use XCOFF instead of ELF. Supporting a significantly different interface, e.g., Windows, while doable, would be considerably more work. K42 is not much further along being able to support a Windows API than Linux is. The original intent in K42 was to allow multiple personalities to be efficiently supported, but we have not pursued this avenue of research. Other work[18] has examined supporting multiple personalities on a micro-kernel-like architecture.
Other operating systems emulate Linux, for example, all the BSD Unix systems do. They do so by reflecting traps to a vector with minor translation from Linux to native system calls. That is one part of our solution, the more straightforward part. The more difficult part for K42 is that it is not a real Unix system under the covers. Thus, one of the key challenges relate to the different abstractions the base system supports. Mach is another operating system with an implementation of Linux. The MkLinux Linux Server [1] has the entire Linux functionality in one single Mach task (instead of smaller specialized tasks communicating through Mach RPCs) in order to maximize reuse of the existing monolithic kernel.
K42 has similarities to a micro-kernel such as Mach[3] but more closely resembles the Exokernel[11]. The kernel, filesystem, etc., servers do not provide all the operating services, rather part of this functionality is integrated into the application's own address space. For the Linux API, a large majority of the conversion occurs in each application's address space. This approach is unique to K42.
There are other operating system projects that have aspects similar to K42. The ability to perform efficient IPCs as in L4[20] is important to K42's structure of employing user-level servers. K42's strategy for fault tolerance is similar to Disco[15] in that the plan is to run multiple simultaneous instances of K42 across varying sized machines. Other operating systems such as Spring[17] and Choices[9] have similar object-oriented goals but were motivated more by distributed system concerns. Our approach is best summarized by what was stated earlier, namely that performance was a central concern and although we follow a set of design philosophies in K42, we are willing to make compromises for the sake of performance.