Re: netbsd : internals : bach book : good to start-off?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 26 Jul 2019 18:14:31 +0300
    From:        "Andrei M." <lingvofactory%gmail.com@localhost>
    Message-ID:  <CAAkeOY=vRgrS26a20yKW46rxOHzoLve1zTY6GT3FrUYLpYK0fQ%mail.gmail.com@localhost>


  | >         http://netbsd.org/docs/internals/en/netbsd-internals.html

  | Far from being complete though:

It is also largely (many parts of those that do exist) written for
a user who is wanting to write new kernel pieces, rather than one who
wants to understand what is there now.

That seems like it should require a more in depth analysis, but it doesn't.

To tell people how to do something, it only needs to explain the
normal/common cases "do it this way..." whereas for someone to learn
everything that is (or might be) found in existing code it would need
to document everything possible, not just what is rational, and the
interactions of all of that.

eg: to explain how to apply locks for new code that is to be written,
the text just needs to make it clear that they need to be acquired in
this specific order, ...  whereas in existing code that's not always
possible for various reasons, and there are release/re-acquire
dances all over the place that one must understand (along with the
ramifications for the code before and after) in order to understand
what is happening.

It is also now quite old (2005-6 even though it has had more recent
mods) and completely lacking some info (like the new module interfaces)
that is really needed to understand the kernel.

That last word is also relevant - this book isn't really NetBSD Internals,
it is NetBSD Kernel Internals - a true NetBSD Internals book would
contain info on the rc system, /etc/daily (etc) all the account names
with leading _'s and their uses, the build system (and much much more).

And least of its issues (as this could easily be fixed) it contains some
straight out errors - I didn't know this existed until it was pointed out
here, and have not looked at it in detail yet, so I would suspect there
is more.

But (from some example code):

        if (mode & VWRITE && mode->tn_flags & IMMUTABLE)
                return EPERM;

I mean, really!    (And no, I can't fix it, I don't know what the
2nd use of "mode" there really should be).

Further:

   Each node has four times associated to it, all of them represented
   by struct timespec objects. These times are:

       Birth time: the time the file was born. Cannot be changed
       after the file is created.

which is incorrect - the (100% useless) birth time is lowered each time
the mod time is made earlier than the birth time was (my guess is that
someone decided that it is nonsense to have a file which was last modified
before it was created...)    That's used to set the birth time when
restoring a file from one of the formats (like dump) which actually
retain it:

	struct utimbuf b = { access_time, birth_time };
	struct utimbuf m = { access_time, mod_time };

	creat(filemame, permissions);
		/* insert the data */
	utime(filename, &b);
	utime(filename, &m);

The first of those utime() calls, which is nominally setting the mod
time (to a value before this new file was "created") also sets the
birth time, otherwise we would have birthtime > modtime.   The second
one then sets the mod time that is really desired for the file (the
time of the most recent change ... not counting this restore operation).


And:

tlaronde%polynum.com@localhost said:
  | I'm surprised nobody has mentionned "Lions' Commentary on UNIX(r)
  | 6th Edition with source code" (John Lions).

John's commentary was great in the mid/late 1970's, unfortunately its
relevance to anything contemporary is almost zero ... there are
a few underlying principles (like the way inodes and directories
are related) which have been more or less constant over time, but
there's almost nothing else that is still relevant.

It is still interesting, if only to see the way the code was written
in the simpler days of pre K&R C targetted at a PDP-11, but it doesn't
explain anything particularly useful for someone attempting to understand
NetBSD's code.

kre