Weekly Edition
Return to the Press page
| |||||||||||||
How the Linux kernel works (TuxRadar)
TuxRadar takes a simplified look at the Linux kernel. Targeted at users and application programmers, rather than system-level programmers, the article gives an overview of what the kernel does, with a bit about how it does it. "All the other pieces you find in a Linux distribution - the Bash shell, the KDE window manager, web browsers, the X server, Tux Racer and everything else - are just applications that happen to run on Linux and are emphatically not part of the operating system itself. To give some sense of scale, a fresh installation of RHEL5 occupies about 2.5GB of disk space (depending, obviously, on what you choose to include). Of this, the kernel, including all of its modules, occupies 47MB, or about 2%."
(Log in to post comments)
Not part of the operating system? Posted Mar 17, 2009 0:43 UTC (Tue) by butlerm (subscriber, #13312) [Link]
"All the other pieces you find in a Linux distribution - the Bash shell,
the KDE window manager, web browsers, the X server, Tux Racer and everything else - are just applications that happen to run on Linux and are emphatically not part of the operating system itself"
Emphatically? The author of this article is apparently so unaware of the
On that count Bash, X, the KDE core, etc. are most definitely part of the
Not part of the operating system? Posted Mar 17, 2009 2:03 UTC (Tue) by flewellyn (subscriber, #5047) [Link]
I don't know if I would count X or the KDE core as OS components. It's possible to have a fully functional, usable OS without a graphical interface, much less a full desktop environment.
Without a shell, though? Or a libc? Yeah, probably not. In embedded contexts, maybe, you could roll your own libraries to run on top of the kernel, and your application(s) on top of those. Or even just write your embedded app to run directly on top of the kernel.
But I know of no reasonable installation on a general purpose computer which would not at the very least have glibc and bash.
Not part of the operating system? Posted Mar 17, 2009 6:00 UTC (Tue) by Janne (guest, #40891) [Link]
"I don't know if I would count X or the KDE core as OS components. It's possible to have a fully functional, usable OS without a graphical interface, much less a full desktop environment."
And if you want an oerating system with graphical interface, X, KDE, Qt, GNOME, GTK+ etc. suddenly ARE "core OS components"....
Not part of the operating system? Posted Mar 17, 2009 17:55 UTC (Tue) by flewellyn (subscriber, #5047) [Link]
Well, X, yes. But you can run a GUI with a simpler WM than GNOME or KDE, you know.
Not part of the operating system? Posted Mar 18, 2009 6:08 UTC (Wed) by Janne (guest, #40891) [Link]
Of course you can, but the simplicity or complexity of the GUI is irrelevant here. The point remains: if you want an OS with graphical interface, then those graphics-subsystems ARE part of the core-OS. Saying that they are not part of the core-OS because you can have an OS without graphics is dishonest.
Besides, is OS "fully functional" if it doesn't have a GUI? If you installed a Linux without X and GUI to my laptop and started claiming that it was a "fully functional OS", I would have to respectfully disagree.
Not part of the operating system? Posted Mar 18, 2009 6:47 UTC (Wed) by flewellyn (subscriber, #5047) [Link]
Depends on what you're using it for. If you're installing a server, you can certainly have a full-featured Linux system without a GUI.
But regardless, the argument that "if you want this feature, it becomes part of the core OS" is just silly. There has to be a boundary at which you say "this stuff is core OS, this stuff here is applications and user libraries". If you aren't going to draw that line at the kernel boundary (which is arguable either way), a good suggestion I have is to examine your filesystem hierarchy. What goes in /bin, /lib, and /sbin could be called "core OS libraries and programs", but if it goes in /usr, /opt, or especially /usr/local, I don't think you could reasonably argue for that being "core" anything.
Not part of the operating system? Posted Mar 21, 2009 13:50 UTC (Sat) by nix (subscriber, #2304) [Link]
I've had endless arguments with various people about this (wasting
*months* in a epic flamewar with Peter da Silva, years ago) and have come to the conclusion that we're all arguing over nothing. There is *no such thing* as a 'core OS'; there is simply a nested set of layers, getting less and less useful to users and more and more hardware-constrained the closer you get to the centre. Some systems develop the layers independently (e.g. Linux); some develop them as a unit (e.g. the BSDs, even more than their MacOS X offshoot); some are just a bloody mess (Windows) :)
What is part of the 'core OS' depends on the type of system you're looking
Not part of the operating system? Posted Mar 26, 2009 10:32 UTC (Thu) by jschrod (subscriber, #1646) [Link]
Well, I have a laptop with Linux and without X/GUI that is fully functional. It is a 12 years old Thinkpad Butterfly -- still working like a charm! -- with 16 MB main memory, just a few GB disk, and I use it successfully for network troubleshooting in data centers.
You might respectfully disagree, but frankly -- your worldview seems to be rather restricted.
Not part of the operating system? Posted Mar 17, 2009 11:42 UTC (Tue) by nye (guest, #51576) [Link]
I think the distinction between the OS and the software running on it seems rather more important now that we have Android - the first Linux system which is definitely not GNU/Linux. So far as I'm aware it doesn't have glibc, or much else except the kernel from a standard Linux system, does that make it a different OS or not?
Not part of the operating system? Posted Mar 17, 2009 18:31 UTC (Tue) by flewellyn (subscriber, #5047) [Link]
That's an interesting question to ponder, yes. When I was studying operating systems theory in college, one of the things I noticed was the tendency in the literature to use "operating system" and "kernel" almost interchangeably. In Andrew Tannenbaum's "Operating Systems: Design and Implementation", for instance, I recall reading a number of references to "the operating system" versus "user libraries", treating libc as the latter in many cases. It seemed one of the main distinctions (hardly the only one!) was where the code lived in memory: a single, unified kernel address space, or one of many userspace virtual memory mappings? Using this distinction, "the operating system" was really just the portion that lived in "kernel space".
But then the book and the professor both went on to break that distinction by talking about microkernels; our edition of the book at the time didn't talk about exokernels, since they were too new, but our professor did mention them as well.
In the case of a microkernel or exokernel system, of course, you really can't do much of anything without libraries; an exokernel in particular provides absolutely no abstraction over the hardware, only performing arbitration of resources. So "the operating system" in this case was a small (in the case of exokernels, VERY small) chunk of code, and everything else, even traditionally "OS-level" services, was actually library code or daemons living in userspace.
Given that fact, my professor in that class encouraged us to consider "the operating system" as the kernel AND the collection of libraries and/or daemons that implemented the basic "OS-level" services: if the library or daemon was exporting functions that looked like POSIX system calls, that was the "boundary" of the OS.
But Linux is a monolithic kernel that contains a great deal of abstraction and provides a lot of services in its single kernel address space. The system calls it provides as its "entry points" ARE the POSIX system calls, plus some extras. In the case of Linux, it makes sense to consider the kernel as "the operating system", at least in some contexts.
To make a long story short (too late!), I would say "no, Android isn't a different operating system, it just has a different userspace".
Not part of the operating system? Posted Mar 17, 2009 19:44 UTC (Tue) by vonbrand (subscriber, #4458) [Link] You can build an amazing lot of stuff on busybox. There are alternative C libraries around. And you can compile Linux with ICC (the Intel compiler). It was even possible to boot the source kernel using The Tiny C Compiler... You could even replace all userland (including libc) with BSD, or Solaris (perhaps at a risk for your license-abiding health, though). Or go the other way, plant a BSD/Solaris/Hurd kernel inside, say, Debian.
Not part of the operating system? Posted Mar 17, 2009 2:15 UTC (Tue) by cjs (subscriber, #45842) [Link]
Nice article, except for the inane bickering in the comments section.
Not part of the operating system? Posted Mar 17, 2009 11:19 UTC (Tue) by efexis (guest, #26355) [Link]
Quit it, this isn't slashdot.
Kernel as "server" ... system calls and interrupts as "protocols" Posted Mar 17, 2009 20:41 UTC (Tue) by AnswerGuy (guest, #1256) [Link]
When I teach advanced sysadmin classes in Linux troubleshooting I usually cover strace, ltrace, sh -vx, and similar tools.
On a conceptual level I cover the process life cycle (from clone()/fork(), through execve(), the parent process using wait() or waitpid(), how the child exits and how that results in a SIGCHLD to the parent, etc).
I draw little diagrams of the process' "memory map" --- how it gets "copied" (virtually via shared page references with copy-on-write) ... and how most of the address space is over-written by the execve() (pointing at how part of it is preserved ... which explains the environment and also explains why the Bourne shell built-in command to move a local shell variable into the environment is called ''export''). More squiggles in the boxes talk about the "text" and BSS, stack and heap memory areas --- which leads to the discussion of malloc() and brk() and so on.
When I talk about system calls and compare them to library functions I describe the kernel as if it were a separate "server" --- so that the students can see the system call as a protocol by which the "clients" (user space processes) request services.
Then I point out that the kernel has a dual facing nature (like the mythical Greek deity, Janus). The kernel provides a system call interface to user space, and it provides interrupt handling for devices.
When we get back to strace, I use an strace of the 'uname' command as my first example. This is one of the simplest possible commands (almost as simple as '/bin/echo'). Then we compare that to an 'ltrace' and finally (now tha they've added the option) to an ltrace -S (which interleaves the system calls with the library function calls in the trace).
It's a huge amount of information to pack into the 4 hours or so that I spend on it. (My typical class is about 40-50 hours total).
Recently I've started exploring SystemTap and hope to be adding coverage of that to my courseware. My plan is to drive home the contrast -- strace gives you information about what gets "thrown over the wall" (the call) between user space and the kernel ... and what got "thrown back" (returned). SystemTap let's us see what's going on on the other side of the wall.
Just a few stray thoughts on how I've approached it over the years.
Kernel as "server" ... system calls and interrupts as "protocols" Posted Mar 17, 2009 22:32 UTC (Tue) by nix (subscriber, #2304) [Link]
You might find 'latrace' useful too. It uses the nearly-undocumented glibc
LD_AUDIT system to provide complete, accurate coverage of shared library calls (including calls to routines in the same library as long as they're via public interfaces), complete with call stacks.
It rocks.
There is nothing so pointless ... Posted Mar 19, 2009 21:55 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] ... as an argument over the meaning of a term that different people use in different ways. Some authors define it to mean the kernel. Others consider everything in a minimal base installation to be part of the OS. The GPL (version 2) makes clear that the compiler is considered part of the operating system, in a clause that is intended to allow use of proprietary operating system components with GPL code.Because of these differences in usage, it's pointless to argue as there is no one right answer.
|
|||||||||||||