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

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.

Something remotely related

[Z00L00K]

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

Interesting to read about events from a bygone era.

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.

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?

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

[g2devi]

Keep in mind that the bulk of that size is related to support for every device driver under the Sun (and x86, and PowerPC, and IBM mainframe, and iPod, ...). Most people don't compile in all the options, so it is significantly smaller. And although it's possible to get a bare-bones kernel that support exactly the devices your computer supports (i.e. embedded Linux systems do this), most people are willing to trade a little bulk for the convenience of having any computer they install on or device they plug in once installed instantly recognized.

Re:2.6.x.x

[Anonymous Coward]

It's actually Adrian Bunk [wikipedia.org]

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.