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.'"

Comments

I call BS

[Timesprout]

I posted the question "What is the Linux kernel" to Ask a Ninja on YouTube. He told me it was a secret project undertaken by tree squirrels to create a time machine from the kernels of nuts so they could fast forward through winter cos they are fed up being stuck indoors for the winter months.

Re:I call BS

[TheRealMindChild]

I posted the question "What is the Linux kernel" to Ask a Ninja on YouTube. He told me it was a secret project undertaken by tree squirrels to create a time machine from the kernels of nuts so they could fast forward through winter cos they are fed up being stuck indoors for the winter months.

As opposed to... say... rock squirrels.

Re:Good article...

[Bronster]

That takes you into the guts of a distribution, but not much further than "make menuconfig" into the kernel itself. Woot.

Not that there's anything wrong with Linux From Scratch, but a deep diving kernel expedition it isn't.

Protected from Commercial Exploitation?

[smartbei]

From TFA (emphasis mine): "Linux quickly evolved from a single-person project to a world-wide development project involving thousands of developers. One of the most important decisions for Linux was its adoption of the GNU General Public License (GPL). Under the GPL, the Linux kernel was protected from commercial exploitation, and it also benefited from the user-space development of the GNU project (of Richard Stallman, whose source dwarfs that of the Linux kernel). This allowed useful applications such as the GNU Compiler Collection (GCC) and various shell support." Tivo?

Re:Protected from Commercial Exploitation?

[Tab is on Slashdot]

I think they're speaking in contrast to a BSD-style license, where there is no stipulation regarding re-committing modified code. In other words, with the GPL, a company can't absorb the Linux kernel into a proprietary project without having to open up all further modifications. This is unlike the BSD license, which is truly free in the sense that the code can be used in any fashion, proprietary and modified or not.

Let The Flamewars Begin

[cerberusss]

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.

Re:Let The Flamewars Begin

[Anonymous Coward]

Don't Hurd anybody.

okay but one major error

[belmolis]

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.

Intriguing

[peterjb31]

Interesting article but really quite vague.

Re:Good article...

[Per Wigren]

RTFA. Linux From Scratch is not about understanding the insides of the kernel, it's all about building a custom distro.

Something remotely related

[Z00L00K]

when it comes to the inner workings of an operating system can be found at the Multicians web site.

Interesting to read about events from a bygone era.

wow

[kitsunewarlock]

5 million lines of code? Are they allowed to show all that.

That's hot. /insert another "anatomy" joke here.

Re:2.6.x.x

[4e617474]

The major version number in 2.6.x.x is 2. Six is the minor version number, for which the term "series" is frequently used. The third number is called the "release" number, and the fourth is called "trivial" (although sometimes the difference is "the X server doesn't crash every ten seconds any more" and I don't personally consider it trivial). They stopped using the minor version/series number to denote stability vs. development in 2.6, and did away with having a stable vs. development branch altogether, but Adrian Branch has been maintaining 2.6.16.x since December of 2005 to serve the old role - a stable feature-set with the relevant bugfixes from newer releases applied.

wrong!

[Anonymous Coward]

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?

Re:wrong!

[spitzak]

Unless you're so l33t that you invoke all your system calls with inline assembly?

Actually there was a time when read() and write() were usually turned by the compiler into assembler instructions to trap straight to the kernel. "libc" was considered where stdio (fread/fwrite and printf, etc) lived, not where read() and write() did.

Re:wrong!

[cyber-vandal]

Someone being overly pedantic on Slashdot? Next they'll be criticising a great company like Microsoft.

Visualize your kernel

[daxomatic]

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.

A Brief History of Kernel Size

[Toffins]

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!

Re:A Brief History of Kernel Size

[Daniel Dvorkin]

Over that same period, the RAM, processor cycles, and HD space sitting on my desk all increased by a factor of about 2000. So I'd say a five-fold increase in kernel size isn't too bad -- and a hell of a lot better than most software has done.

Re:A Brief History of Kernel Size

[644bd346996]

Funny - I can easily get a 2.6 kernel under 1000Kb. All I have to do is disable the subsystems that I don't need on my circa 1996 PC. Things like USB, SCSI, AGP, and MD add quite a bit to the kernel. In fact, with all hotplug systems disabled (and no modern systems like sysfs) it isn't hard to get a kernel down to 620kb.

I think you've been adding a lot of features without knowing it.

Microkernels are flexible...

[SanityInAnarchy]

I don't disagree, in theory. In practice, there are at least a few things that microkernels can do that monolithic kernels can't (yet).

For example, a microkernel can run filesystems and probably even certain kinds of drivers on a per-user basis. Give them access to the chunk of hardware they need, but don't require them to be able to pwn the rest of the system. This would be really nice for binary drivers, too -- it not only kills the licensing issues, but it allows us to, for example, run nvidia drivers without trusting nvidia with any hardware beyond my video card.

Microkernels can also allow drivers to be restarted and upgraded easily, without having to upgrade the entire system. It would be theoretically possible to upgrade the nvidia drivers in-place, or even recover from an nvidia driver crash without having to reboot the whole system. If it was designed intelligently, you might not even have to restart X to reload a driver.

Monolithic kernels can do this in theory. In practice, "kernel modules" are ugly and hackish, often requiring you compile a kernel module for a specific kernel version, and too often being held "in use" by something. Also, they just sit there eating up RAM (though a small amount, I admit) when not being used, yet often you want them loaded anyway -- for example, loop is completely useless except for the 1% of the time I want to mount a disk image, but if loop isn't loaded, mount won't load it.

One of the major selling points of a Unix system in the first place, at least to me, was that a single rogue program is unlikely to bring the entire system down with it. Sure, forkbombs still work, and eating tons of memory still sucks, although you can prevent both of them -- but you don't often have the situation you see on Windows (especially 95/98), where a single badly-written program can make the whole system unstable.

This is true on microkernels, only more so. In order to replace them entirely with a monolithic kernel, you need a bit more than type-safety -- you need a language that is restrictive enough that you can actually run multiple, untrusted programs in the same address space. If you can do that, you don't even need userspace processes to have a private address space, except for some backwards-compatible POSIX layer.

But then you're stuck with the tricky problem of making that kind of language useful for the low-level stuff a kernel has to do. Like it or not, I don't think we're at a point where you can make a viable kernel in LISP or Erlang, though Java might be close (when extended with C, which kind of kills the point).

I would love to develop such a system, but I am about to be gone for two weeks, and when I get back, I still won't have a ton of time.

And I think you're probably wrong about microkernels using shared memory "destroying the separation advantage" -- I'm guessing it's probably done in a fairly safe/quick way. (Or if it's not, it can be.) Consider a pipe between two processes -- what you write to stdout would, in a naive implementation, be copied to the stdin of the other process. A smarter implementation might actually allow you to simply pass ownership of that particular buffer to the other process -- functionally about the same, but almost as fast as shared memory.

But if I have no clue what I'm talking about, please tell me. I don't want to sound like a moron.