Slashdot Mirror


Anatomy of the Linux Kernel

LinucksGirl writes "The Linux kernel is the core of a large and complex operating system, and while it's huge, it is well organized in terms of subsystems and layers. In this article, the reader explores the general structure of the Linux kernel and gets to know its major subsystems and core interfaces. 'When discussing architecture of a large and complex system, you can view the system from many perspectives. One goal of an architectural decomposition is to provide a way to better understand the source, and that's what we'll do here. The Linux kernel implements a number of important architectural attributes. At a high level, and at lower levels, the kernel is layered into a number of distinct subsystems. Linux can also be considered monolithic because it lumps all of the basic services into the kernel. This differs from a microkernel architecture where the kernel provides basic services such as communication, I/O, and memory and process management, and more specific services are plugged in to the microkernel layer.'"

4 of 104 comments (clear)

  1. Let The Flamewars Begin by cerberusss · · Score: 5, Funny

    Linux can also be considered monolithic because it lumps all of the basic services into the kernel. This differs from a microkernel
    Whenever I hear the word microkernel, I reach for my revolver.
    --
    8 of 13 people found this answer helpful. Did you?
  2. wrong! by Anonymous Coward · · Score: 5, Informative

    The diagrams are nice and for the most part the text is okay, but there is one glaring error that should have been edited out before this was published:

    There is also the GNU C Library (glibc). This provides the system call interface that connects to the kernel and provides the mechanism to transition between the user-space application and the kernel.

    This is false and could be very confusing for readers who don't already know about the structure of Linux. The diagram gets it right.

    Yes, the diagram gets it right, but the text is essentially correct (unless you insist on being overly pendantic). glibc provides a portable system call interface via functions such as read(), write(), and open(). These functions provide the mechanism to transition between the user-space application and the kernel, ie, they invoke sysenter and sysexit (or int 0x80) on x86 cpus.

    Unless you're so l33t that you invoke all your system calls with inline assembly?
  3. Visualize your kernel by daxomatic · · Score: 5, Interesting

    Here is a great tool to visualize your kernel and then print a poster of it
    http://fcgp.sourceforge.net/
    you do need a big printer for it if you want a readable poster though ;-).( and yes you also can stick 16 A4's to a wooden plate but that's just plain silly)
    I does however show you in perfect details all the arch's and sub systems of the kernel.

  4. A Brief History of Kernel Size by Toffins · · Score: 5, Informative
    Here is a brief history of the average size of each series of the Linux kernels (this is for the core kernel not including module sizes) that I have configured with very approximately the same set of features over the last 14 years from 1993 to 2007:

    In 1993 a Linux 0.99 kernel zImage weighed in at 210 kBytes
    In 1994 a Linux 1.0.x kernel zImage weighed in at 230 kBytes
    In 1995 a Linux 1.2.x kernel zImage weighed in at 310 kBytes
    In 1996 a Linux 2.0.x kernel zImage weighed in at 380 kBytes
    In 1998 a Linux 2.2.x kernel bzImage weighed in at 650 kBytes
    In 2000 a Linux 2.4.x kernel bzImage weighed in at 1000 kBytes
    In 2003 a Linux 2.6.x kernel bzImage weighed in at 1300 kBytes
    In 2007 a Linux 2.6.x kernel bzImage weighed in at 1500 kBytes
    Remember the days when a kernel and root filesystem would comfortably fit on a 1.4MB floppy?
    Hush little kernel, nobody said you are getting a little f-a-t!