> The basic level of knowledge stuff can already be bought at your book
> store. Linux Kernel Internals, Linux Device Drivers, Design of The Unix
> Operating System, etc.
Books are static. The kernel is not. Given the current rate of kernel
development, books on it are outdated almost as soon as they hit the
shelves. What good is a basic introduction if it's outdated and
therefore wrong?
_Linux Device Drivers_ is a good book. I like it. Unfortunately, it
doesn't help very much with 2.2 and 2.3. It's a lot easier to keep
documentation in the kernel tree up to date than it is to keep a
physical book up to date.
> Obviously, external interfaces (syscalls, ioctls, /proc) are a different
> story. But what we're arguing about now is the internals. Or should the
> whole underside of the kernel that modules talk to be declared an external
> interface and written in stone? Next you'll want binary compatibility and
> we'll be one short step away from having a microkernel.
Even the internals can have some stability. If I'm writing a set of
modules, which is a better way to spend my time -- chasing after
changes to the kernel interface or making my code better?
> This is a straightforward consequence of the investment in documentation.
> "Hey, I just wrote this nifty new subsystem and all these docs. Oh look,
> there's a nifty way I could improve it by doing <foo> everywhere. But then
> I'd have to change the docs. Hell with it."
Laziness is laziness, and no system can prevent that. Currently we
have "Oh, then I'd have to change everything in the kernel that uses
<foo>". I'm not convinced that adding "and write a paragraph
explaining it" is really a killer task compared to that. Even if the
guy who made the change doesn't want to add that paragraph, someone
else can. What's important is that it exists, not who wrote it.
> Umm, yes. Unreadable code is hard to maintain. Documented unreadable code
> is not much better - you still have to read the code to fix it and maybe
> just to use it. Systematically documenting everything with man pages,
> etc., including the readable code (which a lot of the kernel is, happily),
> is a step in the wrong direction. Effort is better spent on making the
> code comprehensible.
Why do you think I'm advocating documentation at the expense of
readable code? Argue against my position if you like, but please stop
constructing strawmen. Please show me where I or anyone else claimed
that writing documentation was more important than cleaning up code.
--nat
-- nat lanza --------------------- research programmer, parallel data lab, cmu scs magus@cs.cmu.edu -------------------------------- http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/