tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Location of the kernel version number



    Date:        Thu, 1 Nov 2012 12:57:22 +0200
    From:        Alan Barrett <apb%cequrux.com@localhost>
    Message-ID:  <20121101105722.GG18610%apb-laptoy.apb.alt.za@localhost>

This reminds me of something I had been meaning to suggest for some
time now ...  (totally unrelated to the topic of the message to which
I'm replying, hence the change of Subject:)

  | _NETBSD_VERSION_DEPENDENT
  |             A list of files which contain information about
  |             the version of the NetBSD being built.  This is
  |             defined only if the current directory appears
  |             to be inside a NetBSD source tree.  The list of
  |             files includes ${NETBSDSRCDIR}/sys/sys/param.h
  |             (which contains the kernel version number),

I'd like to change that last (parenthetical) fact - it is without
question true now, and has been (as best I remember) ever since the
idea of a kernel version number was first invented, which means that
it will probably be painful to change - but it is just plain wrong.

The problem is that (quite properly, given its intended use) the
kernel version number changes all the time (particularly in -current)
and arguably should change even more often (but we need not get into
that here).

With the kenel version being in param.h, that means that everything
(everything in the kernel) gets recompiled, for no good reason at all.

For example, were someone to add a field to the vnode struct, the
kernel version number would change (correctly).   All the parts of the
kernel that care about the vnode format change get recompiled because
they (necessarily) depend upon <sys/vnode.h>.  But as things are now,
all the rest of the kernel source gets recompiled as well, as everything
ends up depending upon param.h.   Aside from a couple of files, nothing
in the kernel actually cares what the kernel version is (and nor should it)
and being recompiled just because of that change is just waste.

The solution seems to be to move the kernel version number into a file
of its own.   The few places that actually care can include that new
header file.

Ideally, param.h would not include this file at all, certainly it can't
include it unconditionally, as that would defeat the purpose of
moving the thing out.

But that would break a large number of non-kernel sources, which assume
that param.h contains the current _NetBSD_Version_ - the NetBSD sources
we could fix, but everything else would be just too much of a pain, so
I think that param.h would need to contain something like

        #ifndef KERNEL
        # include <sys/version.h>
        #endif

(or something along those lines, perhaps, with the correct names).

Then again, perhaps there aren't really all that many non-NetBSD
applications that actually know about _NetBSD_Version_ and would be
affected by simply severing the relationship completely?  (Note, it
is just that one version string definition that needs to move, all
the ancient "never to be changed again" macros can remain in param.h
where they have always been.)

Opinions?

Incldenally, a good fraction of the rest of what is in param.h (the
actual kernel parameters, or what once were,) suffers from the same
basic problem, but changes so infrequently that the effects are largely
irrelevant.

kre

ps: the absurd and useless __NetBSD_Prereq__() macro *still* hasn't
been removed - I thought there had been general agreement to get rid of
that thing ages ago!


Home | Main Index | Thread Index | Old Index