How the Linux kernel works (TuxRadar)
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%."
Posted Mar 17, 2009 0:43 UTC (Tue)
by butlerm (subscriber, #13312)
[Link] (12 responses)
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
Posted Mar 17, 2009 2:03 UTC (Tue)
by flewellyn (subscriber, #5047)
[Link] (9 responses)
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.
Posted Mar 17, 2009 6:00 UTC (Tue)
by Janne (guest, #40891)
[Link] (5 responses)
And if you want an oerating system with graphical interface, X, KDE, Qt, GNOME, GTK+ etc. suddenly ARE "core OS components"....
Posted Mar 17, 2009 17:55 UTC (Tue)
by flewellyn (subscriber, #5047)
[Link] (4 responses)
Posted Mar 18, 2009 6:08 UTC (Wed)
by Janne (guest, #40891)
[Link] (3 responses)
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.
Posted Mar 18, 2009 6:47 UTC (Wed)
by flewellyn (subscriber, #5047)
[Link] (1 responses)
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.
Posted Mar 21, 2009 13:50 UTC (Sat)
by nix (subscriber, #2304)
[Link]
What is part of the 'core OS' depends on the type of system you're looking
Posted Mar 26, 2009 10:32 UTC (Thu)
by jschrod (subscriber, #1646)
[Link]
You might respectfully disagree, but frankly -- your worldview seems to be rather restricted.
Posted Mar 17, 2009 11:42 UTC (Tue)
by nye (subscriber, #51576)
[Link] (1 responses)
Posted Mar 17, 2009 18:31 UTC (Tue)
by flewellyn (subscriber, #5047)
[Link]
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".
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.
Posted Mar 17, 2009 2:15 UTC (Tue)
by cjs (guest, #45842)
[Link]
Posted Mar 17, 2009 11:19 UTC (Tue)
by efexis (guest, #26355)
[Link]
Posted Mar 17, 2009 20:41 UTC (Tue)
by AnswerGuy (guest, #1256)
[Link] (1 responses)
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.
Posted Mar 17, 2009 22:32 UTC (Tue)
by nix (subscriber, #2304)
[Link]
It rocks.
Posted Mar 19, 2009 21:55 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link]
Because of these differences in usage, it's pointless to argue as there is no one right answer.
Not part of the operating system?
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"
standard usage of what constitutes an "operating system" that I hardly know
where to begin. Suffice it to say that programs, libraries, and utilities
that are near universal dependencies of higher level applications or which
are required for the basic operation and maintenance of any general purpose
computer system are generally considered "operating system" components
rather than "application components".
operating system, especially when a distribution ships with no equivalent
alternative.
Not part of the operating system?
Not part of the operating system?
Not part of the operating system?
Not part of the operating system?
Not part of the operating system?
Not part of the operating system?
*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) :)
at.
Not part of the operating system?
Not part of the operating system?
Not part of the operating system?
Not part of the operating system?
Not part of the operating system?
Not part of the operating system?
Kernel as "server" ... system calls and interrupts as "protocols"
Kernel as "server" ... system calls and interrupts as "protocols"
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.
... 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.
There is nothing so pointless ...