On 11-07-08 09:08, William Case wrote:
If not, I could come in here and say I'd like to view kernels as
large collections of independent nano-bots and then demand that
people tell why they weren't.
I haven't seen a pattern of nano-bots within the kernel, nor do I
think, have you. Describing the kernel as a library, says to me
there are 6 million lines of code and that is the only way to view it
-- from top to bottom. You have to because all those lines are in
random order.
THE most important thing to realize is that the kernel does not in any
sense have a top and a bottom -- and that is what the library model
rather says. Linear programs have tops and bottoms, but libraries do
not. They have many entry/exit points.
Many people new to the kernel start "where the kernel starts"; they
start tracing the boot code, get lost in things such as initial page
tables, find themselves in BIOS interactions, all for no good reason. If
you're the type, it can be fun to study these details, but as the
abundance of arch/ directories for which all that code is completely
different already shows: it's no _more_ than machine details. The fun
starts when the kernel is up and running.
The point to start at is asking why a kernel exists and the only correct
answer is that it exists to serve the needs of the applications that run
under it. Serve them as well as possible but serve them slavishly.
Kernels aren't cool. They are the pieces of software that everyone gets
to boss around. The entry into a kernel, then, is through user space:
the way to knowing how/why the kernel does what it does is by knowing
what is being asked of it. This is generally true, very true for
real-life (as opposed to academic) kernels and VERY true for the
exceedingly pragmatic real-life kernel Linux.
Of course, applications have differing needs and this is what the kernel
as shared library model says; the kernel is a collection of various
useful code that applications call into to get various things done.
Most successful entries by programmers into the Linux kernel also start
there. They need something done, figure out the kernel either does not
provide a way to do it or does it wrong, slow, clumsy or whatever and
set out to implement, fix or improve it. They "scratch an itch". As time
goes by, there are fewer remaining itches to scratch (you might as this
point have fairly little unsupported hardware for example) but one
should not abandon this route to entry.
The most traditional way of interacting with the kernel is through the
system call ("syscall") interface. You can write a small program which
does something you find interesting and then ask yourself how it works.
If you limit yourself to interfaces documented in section 2 of the
manpages you'll be foregoing the user space libc interfaces and will be
using syscalls directly. To take the most fundamental UNIX syscall as an
example, try a "man open".
So how does the kernel implement open? All available for your viewing
pleasure under your local kernel source directory, starting at the
syscall entry point "sys_open". That's not the most low-level entry
point into the kernel but is called directly from that point. You can if
you decide you find it interesting figure out later exactly where the
first line of kernel code executed after the program calling the "open"
syscall is, but that's again not important for the kernel as such.
Tools such as ctags help navigating the kernel source. If you run "make
tags" from the root of the source tree, a "vim -t sys_open" will take
you to the sys_open function immediately. ctrl-] while on an identifier
to jump to its definition (ctrl-t to jump back, ":help tags"). Other
tools include cscope and lxr.
Now mind you, sys_open, while maybe the most fundamental syscall is not
the most basic and likely not a good start. You may for example like
getttimeofday() better. But the route is the point. The kernel is driven
by what user space expects from it ...
... and by being as quick about it as possible. In your perusals you'll
frequently encounter things that are complex only due to them needing to
perform well. If performance were not an issue, core kernel code could
be cut by a factor of 100.
If not already clear from the masses of text trying to be helpful above,
I'm sort of satisfied that your question wasn't necessarily intellectual
wankage. Hope you'll find this useful.
In Linux you'll encounter few encompassing abstractions. There's the old
generic "everything is a file" UNIX model of course but even something
as fundamental as that is violated at so many points that you basically
need to forget it. And sure, lots of the kernel is object oriented (is
driven by tables of function pointers that is) but this doesn't in any
sense make the tables the important ones. The _code_ is and any tables
are nicely grouped sets of data serving code.
I just reread this post. It is full of stupid typos. It is 3:00 am
here. If you want to continue this dialogue, I will resend a corrected
version in the morning.
Don't worry about it. This is an international community and as such
everyone is very used to communication being about understanding one
another. Spelling, grammar, it dun' really matter...
Rene.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
