Slashdot Log In
Anatomy of the Linux Kernel
Posted by
Zonk
on Sat Jun 09, 2007 02:23 AM
from the a-guided-tour dept.
from the a-guided-tour dept.
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.'"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
I call BS (Score:4, Funny)
Re: (Score:3, Funny)
As opposed to... say... rock squirrels.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
2.6.x.x (Score:2)
Re:2.6.x.x (Score:5, Interesting)
Parent
Re: (Score:2)
The FOSS realm is better for this diversity.
If you really require a one-size-fits-all world, send your resume to Hanrahan [slashdot.org]
Re: (Score:2)
But man, I gotto say, the shitty SMP support absolutely kills me. Especially when I'm trying to compile the latest version of X on my OpenBSD firewall... oh wait... I don't do that.
USE THE RIGHT TOOL FOR THE RIGHT JOB YOU FLAMING COWARD AND QUIT ABUSING SOMETHING YOU OBVIOUSLY DON'T UNDE
Protected from Commercial Exploitation? (Score:3, Insightful)
Re:Protected from Commercial Exploitation? (Score:4, Informative)
Parent
Let The Flamewars Begin (Score:5, Funny)
Re: (Score:2, Funny)
Re: (Score:2)
Too late, my friend, too late. I already have mine (a very modular one, of course) pointed at your neck.
Microkernels are flexible... (Score:5, Interesting)
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.
Parent
Re: (Score:2)
Re: (Score:2)
Unfortunately, to perform at all well, it demands a compiler/VM with optimizations I haven't seen tried anywhere before.
okay but one major error (Score:3, Insightful)
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:
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.
Re: (Score:2)
Re: (Score:2)
Where do you get the idea that glibc contains system calls? glibc contains things like trig functions and regular expression matching, which are not system calls.
wrong! (Score:5, Informative)
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?
Parent
Re: (Score:3, Interesting)
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! (Score:5, Funny)
Parent
Re: (Score:2)
No, I'm not being overly pedantic. First, the great majority of functions in glibc are not by any stretch of the imagination system calls. Functions dealing with character handling, strings and arrays, character encodings, locales, searching and sorting, pattern matching, trignometry, random numbers, and cryptography, for example, are not system calls. Second, yes, glibc has been expanded, in its capacity as a portability library, to include functions like low-level i/o that are normally system calls. The
Intriguing (Score:2, Insightful)
Re: (Score:2)
Indeed.
I was hoping for some insight into the interesting interfaces. What I saw was a description that seems to apply equally well to anything UNIXy post BSD 4.3. (except for the fawning over the GNU stuff, of course.) Disappointing.
Something remotely related (Score:4, Informative)
Interesting to read about events from a bygone era.
Re: (Score:2)
wow (Score:3, Funny)
That's hot.
Re: (Score:2)
What's more - when you print it out in legible 12 point print on ordinary office paper those five million lines of code can fit in a single briefcase carried in one hand by an SCO employee. I really would not want to arm wrestle that guy.
Re: (Score:2)
Visualize your kernel (Score:5, Interesting)
http://fcgp.sourceforge.net/ [sourceforge.net]
you do need a big printer for it if you want a readable poster though
I does however show you in perfect details all the arch's and sub systems of the kernel.
A Brief History of Kernel Size (Score:5, Informative)
Hush little kernel, nobody said you are getting a little f-a-t!
Re: (Score:2, Informative)
Re: (Score:2)
Re: (Score:2)
Hush little kernel, nobody said you are getting a little f-a-t!
It's not that bad. Much of the size of a Linux kernel is all of the support for the plethora of devices it supports. Sure, much of that code is build as modules, but some isn't, and even the modules have to have hooks built into the kernel binary.
As an experiment, I just built a stripped-to-the-bone version of 2.6.21 (from Debian's kernel sources), and it's 799 KB. Still rather large for those of us who started on machines that had only a fraction of that much RAM, but certainly not a problem in the
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:3, Informative)
I think you've been adding a lot of features without knowing it.
Small amendment needed. (Score:2)
Should read:
'The Linux kernel is a large and complex operating system, and while it's huge, it is well organized in terms of subsystems and layers.'
Although based upon the comments from those who claim to have read the article it doesn't look like the article covers anything but compiling the Linux operating system with make menuconfig. It does apparently includ
Re: (Score:2)
Re:Good article... (Score:5, Informative)
Not that there's anything wrong with Linux From Scratch, but a deep diving kernel expedition it isn't.
Parent
Re:Good article... (Score:4, Insightful)
Parent
Re: (Score:2)
http://www.linuxfromscratch.org/lfs/ [linuxfromscratch.org]:
Why would I want an LFS system?
Many wonder why they should go through the hassle of building a Linux system from scratch when they could just download an existing Linux distribution. However, there are several benefits of building LFS. Consider the following:
LFS teaches people how a Linux system works internally
Building LFS teaches you about all that mak
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
This is definitely not the IBM that I loved (not) in the 80's...
That's BSD. (Score:2)
Of course, that's difficult to prove. All we really know are a few trivial things like telnet, although I hear most modern OSes just ripped off the BSD network stack wholesale.
Re: (Score:2)