Linux history microkernel, monolithic 2278

Vladimirr Saigon

Microkernels are very difficult to debug. It's hard enough to develope, test, and debug mulbreasthreaded applications, but imagine doing it at machine code level with no tools for debugging. Creating Mach, for instance, required In Circuit Emulators, logic analysers, and cache had to be disabled during debugging. Creating a microkernel for a $1000 PC could take $50,000 worth of tools and hardware.

Linus didn't have much money (he was a college student), he wanted to play with memory management, including caching. He wanted to create a really simple kernel (version 0.10 was only 10,000 lines. He wanted to be UNIX compatible (not a true UNIX or MACH kernel), and he wanted to isolate library functions from kernel functions (using memory maps and mapping memory between processes). The design was elegantly simple.

Linus and Tannenbaum (author of Minix), had a rather heated and lengthy debate over the nature of the design of Linux. Although Tannenbaum made a very good case for the Microkernel vs the "monolithic" kernel, the logistics of microkernel development prevented the successful implementation of a general purpose open source kernel for PCs.

Eventually, Linux did evolve beyond the "monolithic" design. Device drivers were written as "modules", which eliminated the need to compile drivers into the kernel (one of Tannenbaums best arguments for microkernels). These modules were called by the kernel, much like shared libraries. By 1994, the modules were designed to "probe" hardware to help identify which modules needed to be loaded. A configuration file made it possible to select which modules should be "probed" (initially almost everything). This almost completely eliminated the need to compile custom kernels for devices that used traditional "probe" protocols.

The elegance of the Linux kernel was that provided a framework for coupling the libraries to the drivers, managed memory and time, and didn't try to do much more than that. As a result, much of the Linux "personality" resides in the libraries, which makes it easier to manage and maintain compatibility with other APIs such as BSD and X-Open Unix specifications. This makes it possible for Linux to run GNU, BSD, and even System V applications, even though it's internal design is almost nothing like Unix or Mach-BSD.

IBM did contribute a scheduler, but contrary to the suspicions of SCO, it's roots went back to System 360 and MVS-CICS. IBM had provided similar code to SCO, but it was code that IBM owned, and had been using for years in it's mainframes. Rather than using pure semaphores to lock shared resources for "the duration", memory and resources were queued, which meant that the head of the queue only needed to be locked when items were being added to a queue, and the tail of the queue only needed to be locked when items were being removed from the queue. If the head and tail were the same, then the queue was empty. Mainframes often use dozens of these queues to manage resource pools and memory pools.

Good Question.