Bill Studenmund <wrstuden@netbsd.org> wrote:
>
>Well, what technical criteria do we have for the version number? Its
>primary purpose is to communicate a version of the kernel. Since we don't
>have any other version numbers around, we also use it to version the whole
>os.

This is something that has bugged me.  Often, I run -current kernels
on machines to get certain -current kernel features, such as SMP;
however, the machines in question are otherwise -release, and are
meant to run the same userland, packages, etc. as non-MP machines
running -release kernels.

Unfortunately, I cannot do the compiling on the -current-kernel
machines, despite the fact that they're the fastest ones available.
Why?  Because the self-identification of the machine as -current will
cause certain feature tests, etc. to fire when they shouldn't.

Though the kernel may be capable of certain newer syscalls, etc., the
lack of either header files or library wrappers for them _should_ mean
that, as far as applications are concerned, the syscalls are not
present.  Unfortunately, if they check uname to determine if they're
running on an "OS version" with said feature (as e.g. X does), they
get what is ostensibly the wrong answer for their situation.

Thus, I would prefer that uname, sysctl, etc. return a version number
corresponding to the "userland" version, probably as compiled into
libc, unless _explicitly_ asked for the kernel version (which can
also usually be determined from dmesg, 'what /netbsd', etc.).
Given that uname(3) and sysctl(3) are both userland functions, and not
actually part of the kernel like syscalls are, it only makes sense for
their results to also be tied to the userland version...

jdarrow

-- 
John Darrow - Senior Technical Specialist               Office: 630/752-5201
Computing Services, Wheaton College, Wheaton, IL 60187  Fax:    630/752-5968
Pager via email: 6303160707@alphapage.airtouch.com      Pager:  630/316-0707
Email: John.P.Darrow@wheaton.edu (plain text please, no HTML or proprietary)