🚀 go-pugleaf

Vladimirr Saigon wrote:
> Hi,
>
> Does anybody know why Linus choose to make linux monolithic instead of
> microkernel?

Microkernels are very difficult to debug.  It's hard enough to
develope, test, and debug multithreaded 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.

> I have been told, that there was some dispute about that
> decision.

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.

> Best regards.

Good Question.