×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Anatomy of the Linux Kernel

Zonk posted more than 6 years ago | from the a-guided-tour dept.

Education 104

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

104 comments

God Smack Your Ass !! (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#19448877)



God Smack Your Ass !!

Re:God Smack Your Ass !! (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#19448975)

God suck my dick.

Good article... (-1, Offtopic)

creimer (824291) | more than 6 years ago | (#19448905)

But if you really want to get into the guts of Linux, check out Linux From Scratch [linuxfromscratch.org] .

Re:Good article... (4, Informative)

Bronster (13157) | more than 6 years ago | (#19448955)

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.

Re:Good article... (0, Offtopic)

creimer (824291) | more than 6 years ago | (#19449073)

Some people like to work from the inside (kernel) out (distribution), and other people like to work from outside (distribution) in (kernel). Just pick the one that works out the best for you.

Re:Good article... (3, Insightful)

Per Wigren (5315) | more than 6 years ago | (#19449103)

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

Re:Good article... (1)

smitty_one_each (243267) | more than 6 years ago | (#19449989)

Nah, it's not really about building a distro, in terms of something you're actively engineering for others.

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 makes Linux tick, how things work together and depend on each other. And most importantly, how to customize it to your own tastes and needs.

Building LFS produces a very compact Linux system
When you install a regular distribution, you often end up installing a lot of programs that you would probably never use. They're just sitting there taking up (precious) disk space. It's not hard to get an LFS system installed under 100 MB. Does that still sound like a lot? A few of us have been working on creating a very small embedded LFS system. We installed a system that was just enough to run the Apache web server; total disk space usage was approximately 8 MB. With further stripping, that can be brought down to 5 MB or less. Try that with a regular distribution.

LFS is extremely flexible
Building LFS could be compared to a finished house. LFS will give you the skeleton of a house, but it's up to you to install plumbing, electrical outlets, kitchen, bath, wallpaper, etc. You have the ability to turn it into whatever type of system you need it to be, customized completely for you.

LFS offers you added security
You will compile the entire system from source, thus allowing you to audit everything, if you wish to do so, and apply all the security patches you want or need to apply. You don't have to wait for someone else to provide a new binary package that (hopefully) fixes a security hole. Often, you never truly know whether a security hole is fixed or not unless you do it yourself.



I'll add that it will give you some excellent OJT on the various tools, as well as an appreciation both for why GUI and a pre-compiled OS is both a luxury and a prison compared to a CLI and source code.
Package management is a chore, though. Once you're in the door, you may go eventually near the ol' online distro of justice...

Re:Good article... (1)

creimer (824291) | more than 6 years ago | (#19451065)

I did read the article. I thought it was pretty good. I'm just suggesting one way of approaching the understanding of the kernel. I don't understand why the mods are being so anal. Off topic? This is highly relevant to *my* learning experience that I started a few days ago.

Re:Good article... (1)

trofer (986393) | more than 6 years ago | (#19452929)

I don't understand why the mods are being so anal.
You must be new here.

Re:Good article... (1)

creimer (824291) | more than 6 years ago | (#19453165)

You must be new here. I expected that comment from an Anonymous Coward, not someone with an ID number that's 162,108 newer than mine.

I call BS (4, Funny)

Timesprout (579035) | more than 6 years ago | (#19448923)

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 (2, Funny)

TheRealMindChild (743925) | more than 6 years ago | (#19448961)

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:I call BS (0)

Anonymous Coward | more than 6 years ago | (#19448985)

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

...and prairie squirrels, city squirrels, deep-sea squirrels and of course the dreaded SPACE SQUIRRELS!

Those bastard space squirrels might've won the war, but we'll be back. We will strive on, never losing hope for a better tomorrow. We must rally our strength someday punish them for subjugating our planet and our people.

Damn you space squirrels! Damn you straight to HELL!

Re:I call BS (1)

jd (1658) | more than 6 years ago | (#19455597)

Just remember. As any UFOlogist can tell you, Space Squirrels are the Greys.

Re:I call BS (1)

Timesprout (579035) | more than 6 years ago | (#19449083)

No as opposed to ground squirrels which hibernate for the winter so clearly developing a time machine might be difficult for them when they are asleep half the time.

Re:I call BS (1)

fusion9290991 (721295) | more than 6 years ago | (#19457051)

laugh all you want, but we have "rock squirrels" here in South Africa (very prevalent and tame on Table Mountain in Cape Town). They're called "dassies" or "klipdassies" (literally "rocksquirrel") here, but I believe the official name is a "hyrax". See wikipedia http://en.wikipedia.org/wiki/Hyrax/ [wikipedia.org] for more info :)

2.6.x.x (1)

Per Wigren (5315) | more than 6 years ago | (#19448983)

The graph hints that 2.6.0 is the last major release, but isn't the scheme 2.6.x.y where x is major and y is minor nowadays?

Re:2.6.x.x (0, Flamebait)

Drinking Bleach (975757) | more than 6 years ago | (#19449025)

Is that how it works these days? No wonder there's been no 2.7/2.8/etc yet.

I stopped using Linux when it was about... 2.6.11 or something. (Moved to OpenBSD and never looked back)

Re:2.6.x.x (0)

Anonymous Coward | more than 6 years ago | (#19449821)

So you must be happy with terrible performance, shitty smp and packages that aren't available (or supported) because they don't have the userbase to maintain them (for sec vulns).

Re:2.6.x.x (1)

smitty_one_each (243267) | more than 6 years ago | (#19450123)

The BSDs have their audience, as does Linux.
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:2.6.x.x (1)

Architect_sasyr (938685) | more than 6 years ago | (#19455903)

Yep actually I am really happy with the terrible performance. I don't have users on my OpenBSD firewall, I don't allow more than SSH onto my OpenBSD firewall, and I don't install more than vi and pf on my OpenBSD firewall.

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 UNDERSTAND.



Time for a new sig... "there goes my karma"

Re:2.6.x.x (4, Interesting)

4e617474 (945414) | more than 6 years ago | (#19449387)

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.

Re:2.6.x.x (0)

Anonymous Coward | more than 6 years ago | (#19450763)

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
What an appropriate name for the maintainer!

Re:2.6.x.x (1, Informative)

Anonymous Coward | more than 6 years ago | (#19450877)

It's actually Adrian Bunk [wikipedia.org]

Oops (1)

4e617474 (945414) | more than 6 years ago | (#19455167)

Apologies to Mr. Bunk. That's what happens when you make a geek get up at 5:00 A.M. to take somebody to the airport.

Protected from Commercial Exploitation? (4, Insightful)

smartbei (1112351) | more than 6 years ago | (#19449003)

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? (4, Informative)

Tab is on Slashdot (853634) | more than 6 years ago | (#19449181)

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.

Re:Protected from Commercial Exploitation? (0)

Anonymous Coward | more than 6 years ago | (#19449191)

"which is truly free in the sense that the code can be used in any fashion, proprietary and modified or not."

Blah. And made non-free in the process.

You can thank proprietary Wasabi Systems for NetBSD's decline, and the GPL for Linux's dominance in the embedded sector.

Re:Protected from Commercial Exploitation? (0)

Anonymous Coward | more than 6 years ago | (#19453617)

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

That's right, I wake up every morning thinking to my self that I am not 'truly free' unless I can murder my next door neighbours, etc.

Let The Flamewars Begin (5, Funny)

cerberusss (660701) | more than 6 years ago | (#19449029)

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 (2, Funny)

Anonymous Coward | more than 6 years ago | (#19449737)

Don't Hurd anybody.

Re:Let The Flamewars Begin (1)

Bromskloss (750445) | more than 6 years ago | (#19449919)

Whenever I hear the word microkernel, I reach for my revolver.

Too late, my friend, too late. I already have mine (a very modular one, of course) pointed at your neck.

Re:Let The Flamewars Begin (1)

Monkeybaister (588525) | more than 6 years ago | (#19449967)

Microkernels should die.

With type safe languages [wikipedia.org] , they really should be compiling all the components into the same memory space and then they would be able to use the programming language to create the API between components instead of IPC.

Which would basically be Linux written in a type safe language. I can't find it, but IIRC, Linus commented once that Linux is like a microkernel with how the components of the system are separated, but they're using C function calls to initiate inter-communication and run in the same memory/process space. The same memory/process space is something microkernels use to get better performance, but that destroys the separation advatages.

Re:Let The Flamewars Begin (1)

Eli Gottlieb (917758) | more than 6 years ago | (#19451305)

Ah, but type-safe languages suck for writing operating-system kernels. You want to be able to perform type-unsafe pointer operations when you have to create page tables and the like.

Microkernels are flexible... (4, Interesting)

SanityInAnarchy (655584) | more than 6 years ago | (#19453651)

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.

Re:Microkernels are flexible... (1)

WilliamSChips (793741) | more than 6 years ago | (#19454187)

The only thing you've done wrong is not mention capability security [wikipedia.org] . It's an interesting technology which parallels microkernels in a lot of ways--both were ruined by inefficient initial implementations.

Re:Microkernels are flexible... (1)

SanityInAnarchy (655584) | more than 6 years ago | (#19455519)

If I understand that, I actually have an idea for a much simpler model -- at least in its primitives. You could use this model to build POSIX, or capability security, or UAC, or whatever you want, all while sharing one address space through your entire program.

Unfortunately, to perform at all well, it demands a compiler/VM with optimizations I haven't seen tried anywhere before.

Re:Microkernels are flexible... (0)

Anonymous Coward | more than 6 years ago | (#19455179)

You're not a moron. Great post.

Clarification (1)

A non-mouse Coward (1103675) | more than 6 years ago | (#19468305)

you need a language that is restrictive enough that you can actually run multiple, untrusted programs in the same address space
Trust is an action. By executing a program at all, you are trusting that program. I don't mean to be a stickler here, but this is a HUGE distinction that most everyone I know or have met confuses.

Trustworthy is an adjective, meaning that the trust placed on an object is valid.

Perhaps a better way of saying what you said:

... you need a language that is restrictive enough that you can actually run multiple, less trustworthy programs in the same address space ...

See the difference? Millions of people trust untrusworthy code every day.

Re:Clarification (1)

SanityInAnarchy (655584) | more than 6 years ago | (#19469833)

Trust is an action. By executing a program at all, you are trusting that program.

Fine. But that's not the point.

The point is to be able to run multiple, untrustworthy and (relatively) untrusted programs in the same address space.

Or, in other words, being able to sandbox programs that are not trustworthy so that they are also not entrusted with any ability that we don't want them to have.

At a very basic level, think JavaScript, or Java applets. Those are generally run in the same process as the web browser -- thus, the same address space. However, both are limited such that one applet or script cannot affect another applet or script, or another website, much less anything outside the browser, without explicit user consent. If this can be done very well and securely, and on a large scale, you don't need separate address spaces at all.

... you need a language that is restrictive enough that you can actually run multiple, less trustworthy programs in the same address space ...

This is not sufficient, because as you say, millions of people run untrustworthy code every day. There's really nothing stopping you from downloading a bunch of random executable code, throwing it together into one process, and running it -- that would be what you just said, and it would be a security hazard. I'm talking about taking such code and running it, while actually not trusting it.

Re:Let The Flamewars Begin (0)

Anonymous Coward | more than 6 years ago | (#19455359)

You appear to know about as much about microkernels as Linus does.

Re:Let The Flamewars Begin (1, Funny)

Anonymous Coward | more than 6 years ago | (#19450369)

How can you be channeling ESR like that? The man's not dead, only his popularity is!

5+ million lines of code ... sheesh (0)

Anonymous Coward | more than 6 years ago | (#19449033)

that is starting to rival teh microsoft ;)

#irc.trolltalk.3om (-1, Troll)

Anonymous Coward | more than 6 years ago | (#19449049)

Future at al`L

okay but one major error (3, Insightful)

belmolis (702863) | more than 6 years ago | (#19449063)

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.

Re:okay but one major error (1)

ettlz (639203) | more than 6 years ago | (#19449133)

This is false and could be very confusing for readers who don't already know about the structure of Linux.
Yes, it's as if a billion pure assembler programmers cried out in terror... aren't glibc system calls wrappers for SYSENTER instructions on modern Intel processors?

Re:okay but one major error (1)

belmolis (702863) | more than 6 years ago | (#19449147)

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.

Re:okay but one major error (0)

Anonymous Coward | more than 6 years ago | (#19449383)

And what open(), close(), socket() etc. does?

Re:okay but one major error (1)

Anonymous Coward | more than 6 years ago | (#19449431)

Or perhaps the syscall() [sourceware.org] function?

wrong! (5, Informative)

Anonymous Coward | more than 6 years ago | (#19449453)

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! (0)

Anonymous Coward | more than 6 years ago | (#19449491)

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

I'd like to see an IBM developerworks article on that ;-)

Re:wrong! (2, Interesting)

spitzak (4019) | more than 6 years ago | (#19449653)

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! (1, Interesting)

Anonymous Coward | more than 6 years ago | (#19453359)

And even more actually, many Linux system calls don't look anything like the POSIX-style API exported by glibc. This was a conscious decisions. Calls like fork() are now implemented in terms of the Linux system call clone(), rather than using an actual fork() system call (which is still available for ABI compatibility, but that's all it's there for). This is all possible because the implementation of the POSIX API is in glibc, not the kernel.

Re:wrong! (1)

belmolis (702863) | more than 6 years ago | (#19455245)

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 ones in glibc, however, are not system calls. Glibc runs entirely in user space and when it does system-call like things, it calls the real system calls.

Re:wrong! (0)

Anonymous Coward | more than 6 years ago | (#19456535)

In other words, glibc comprises, among other utilities, a set of glorified system call wrappers. IMHO, since glibc has become fat itself and is not just a thin layer of glue code anymore, system-specific parts should be separated from others and one more layer of wrappers introduced, so that we could have both sides of glibc, "top" toward user programs and "bottom" toward available calls provided by kernel, standardized for better portability (and back-portability) over various kernels.

Intriguing (2, Insightful)

peterjb31 (1108781) | more than 6 years ago | (#19449087)

Interesting article but really quite vague.

Re:Intriguing (1)

pedantic bore (740196) | more than 6 years ago | (#19454735)

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 (3, Informative)

Z00L00K (682162) | more than 6 years ago | (#19449115)

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:Something remotely related (1)

jd (1658) | more than 6 years ago | (#19455617)

There's a PL/I compiler that works with GCC that's open-source and free. (I'm adding that because I've found at least one commercial PL/I compiler for Linux, which costs $15,000/seat.) If we had enough of the Multics OS code, it should be possible to replace the hardware-specific calls to the Linux equivalent and then compile it as a wrapper.

wow (3, Funny)

kitsunewarlock (971818) | more than 6 years ago | (#19449119)

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

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

Re:wow (1)

dbIII (701233) | more than 6 years ago | (#19449583)

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

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:wow (0, Troll)

brother sloth (991002) | more than 6 years ago | (#19451131)

"Are they allowed to show all that." and "That's hot."

I asked the same question of your mother. She said we could still play hide the sausage. Wanna watch? Oh, that's right, you're a homo!

great (1)

drifta303 (1113363) | more than 6 years ago | (#19449193)

Its awesome that the article is being hosted at IBM.. Perhaps more people will start to shift away from windows and more titles will be available. i think dell is also shipping with linux, yes?

Re:great (1)

deftcoder (1090261) | more than 6 years ago | (#19449521)

IBM hosts *many* technical articles on just about everything.

Most Linux users do not evangelize Linux and would prefer that the unwashed masses stick with Windows.

What do you mean by titles? More distros? More OSS programs in general?

The fact that Dell is now shipping a couple of machines with Ubuntu (if the customer chooses) is completely irrelevant.

Intermediate? (0)

Anonymous Coward | more than 6 years ago | (#19449485)

Have the developerworks levels been recalibrated for web programmers, what's intermediate about that article? It's a contentless high level intro suitable for executives.

An intermediate article should discuss an implementation detail with sample code.

VT syscall efficientcy improvements (0)

Anonymous Coward | more than 6 years ago | (#19449513)

Methods for system call interface (SCI)
In reality, the architecture is not as clean as what is shown in Figure 2. For example, the mechanism by which system calls are handled (transitioning from the user space to the kernel space) can differ by architecture. Newer x86 central processing units (CPUs) that provide support for virtualization instructions are more efficient in this process than older x86 processors that use the traditional int 80h method.


Would someone care to elaborate?

Re:VT syscall efficientcy improvements (1)

Mr. Hankey (95668) | more than 6 years ago | (#19459569)

With x86 processors you typically have had to emulate the Ring 0 (supervisor mode) instructions, since these supervisor-level instructions could cause the virtualized system to break out of its sandbox and inadvertantly (or advertantly?) crash your machine. In a way, it's like gaining root or admin privileges in the OS. These newer virtualization instructions provide a secondary "Ring 0" that can be used to trap these instructions in hardware, rather than looking for the opcodes yourself. In theory these instructions should allow faster and possibly more stable emulation. In practice VMware runs a bit slower with these in 32 bit mode at the moment, although that will no doubt change in the future. It requires them in 64 bit mode however. Xen uses them to good effect, and is able to run unmodified operating systems only because of these instructions.

this is cool (0)

Anonymous Coward | more than 6 years ago | (#19449565)

now if those ibm blades only
had video/audio-in ...
it's been ... wow ... 15 years since
i touched a original ibm made computer.

Visualize your kernel (5, Interesting)

daxomatic (772926) | more than 6 years ago | (#19449713)

Here is a great tool to visualize your kernel and then print a poster of it
http://fcgp.sourceforge.net/ [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.

Re:Visualize your kernel (1)

creinig (18837) | more than 6 years ago | (#19463745)

Here is a great tool to visualize your kernel and then print a poster of it http://fcgp.sourceforge.net/ [sourceforge.net]

I'm one of the maintainers of this thing -- and I have to say that it's effectively not maintained these days. So don't be too surprised if it doesn't completely work ;)

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)

Well, 16xA4 will be a bit small (~0.8x1.1m). I have a printout of a 2.4 kernel at a bit more than 1x1m, and it's hard to read.

A Brief History of Kernel Size (5, Informative)

Toffins (1069136) | more than 6 years ago | (#19449819)

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 (0)

Anonymous Coward | more than 6 years ago | (#19450073)

I didn't believe you at first but then I checked on my laptop.

1629942 2006-11-21 23:56 kernel.org-2.6.18
1495002 2007-05-02 12:31 rt-patched-2.6.20
A server running 2.4 has a similar size kernel, and 2.6.21 on a server...

1483848 2007-05-09 12:42 vmlinuz
What difference does the config optimize for size option make?

Anyway, all of this pales into insignificance compared to this monstrosity...

nvidia 5422868

Re:A Brief History of Kernel Size (1, Informative)

g2devi (898503) | more than 6 years ago | (#19450837)

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:A Brief History of Kernel Size (1)

Peter La Casse (3992) | more than 6 years ago | (#19451531)

Re-read the post you're responding to. They're not compiling every device driver under the sun into their kernel.

Re:A Brief History of Kernel Size (1)

swillden (191260) | more than 6 years ago | (#19450853)

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 context of today's computers. I'm sure that going beyond just turning off unused items in make xconfig to actually paring out parts of the kernel code, like embedded Linux developers do, would make it much smaller.

Re:A Brief History of Kernel Size (2, Insightful)

Daniel Dvorkin (106857) | more than 6 years ago | (#19451577)

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 (1)

Vexorian (959249) | more than 6 years ago | (#19451639)

Remember the days when a kernel and root filesystem HAD to comfortably fit on a 1.4 MB floppy?

Re:A Brief History of Kernel Size (2, Informative)

644bd346996 (1012333) | more than 6 years ago | (#19451897)

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.

Re:A Brief History of Kernel Size (1)

boolithium (1030728) | more than 6 years ago | (#19453579)

Really the kernel hasn't been getting fat. The modules provided by the kernel team aren't assumed in compiling, that's what make menuconfig is for. However I've noticed poor optimization on the part of distro released kernels. An example I've found in ubuntu is the amount of processor ticks used. For a desktop either 300 or 1000 is recommended by the kernel, for servers either 100 or 250 would be better. They default this at 250, and this is were ubuntu leaves the setting despite the kernel recommendation. If the kernel is fat, blame the distro who thought you needed T3 driver modules or the ability to run 64 processors for your laptop, instead of removing those modules in their release.

Re:A Brief History of Kernel Size (0)

Anonymous Coward | more than 6 years ago | (#19454513)

In 2008 a Linux 2.6.x kernel lzmaImage weighed in at 1999 kBytes, OK?

LZMA > BZIP2 > GZIP

Why not 100 MB kernel (reloaded) instead of stupid limited size upto-2 MiB ?

Re:A Brief History of Kernel Size (0)

Anonymous Coward | more than 6 years ago | (#19455677)

Remember the days when a kernel and root filesystem would comfortably fit on a 1.4MB floppy?

Yes, I, too, long for the days when kernels didn't support any hardware made within the last 5 years.

Fortunately the syscall interface has stayed virtually the same, so for those of us who care about saving a megabyte of disk space, we can run Linux 1.0 and feel all warm inside, while we wonder why none of our hardware seems to be supported.

Re:A Brief History of Kernel Size (1)

DollyTheSheep (576243) | more than 6 years ago | (#19460355)

Your post would be pretty much irrelevant in those current days of multi-gigabyte RAM and terrbyte-sized hard disks. However, kernel size still matters for embedded developers. Many projects in the embedded market still use 2.4 (if they use Linux at all), because even with everything stripped down, 2.6 kernels tend to be considerably larger than 2.4 kernels.

Re:A Brief History of Kernel Size (1)

Paul Rose (771894) | more than 6 years ago | (#19478967)

according to Desi Rhoden, president and CEO of industry consortium Advanced Memory International and chairman of the JEDEC JC-42 memory committee. "The historical year-over-year, price-per-bit decline from 1978 -2002 is 36 percent," ( http://www.techiwarehouse.com/cms/engine.php?page_ id=bb2a94e7 [techiwarehouse.com] )

(1/(1-0.36))^14 > 500

The size of the kernel has grown more than 7 times over 14 years, but memory is more than 500 times cheaper.

When measured in dollars that 1500K 2007 kernel will fit in 70 times less memory than the 1993 kernel.

Large and Complex? (0, Troll)

TreeHead (553584) | more than 6 years ago | (#19450631)

"The Linux® kernel is the core of a large and complex operating system..."

Huh? The Linux kernel is at the core of Windows?

That's BSD. (1)

SanityInAnarchy (655584) | more than 6 years ago | (#19453675)

Due to the nature of the BSD license, I wouldn't be surprised if NT had as much BSD code in it as OS X does.

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:That's BSD. (0)

Anonymous Coward | more than 6 years ago | (#19454503)

NT-based kernels were mostly derived from OS/2. Granted, a lot of the OS/2 stuff has probably been rewritten since the actual Windows NT heyday. But in the same manner, I'd be surprised if there is very much BSD stuff within Windows.
I think you're right that most modern OS probably have some BSD code in them. It's solid stuff, both in design and implementation, and with very permissive license terms. It makes sense to use it.

Small amendment needed. (1)

shaitand (626655) | more than 6 years ago | (#19454375)

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

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 include information about the other software that is included with the operating system to make up complete operating system distributions.

Nitpicks (0, Flamebait)

jd (1658) | more than 6 years ago | (#19455643)

Kernels are not Operating Systems and it is syntactically incorrect to place a "," before an "and", although it is usually acceptable where one list contains a second list. In this case, where the "and" applies to the whole of the remainder of the sentence and not just the insert, the comma should follow the and.

Re:Nitpicks (1)

shaitand (626655) | more than 6 years ago | (#19456167)

Kernels are by definition operating systems in the technical sense. The terms are synonymous. Incorrect usage has caused the term 'operating system' to take on a second meaning that is more or less synonymous with distribution that is easily clarified by using the complete term 'operating system distribution' to distinguish between the two. For instance, Windows XP is an operating system distribution that includes an operating system as the core functional piece that all other components of the system depend upon.

P.S. Grammar corrections have a place in classrooms or with non-native speakers. When you harass native speakers with grammar corrections it is simple trolling. That is doubly true when the correction is a syntax error that literally serves no function and conveys no meaning.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...