Re: uname (3), and uname (1) values, 6.0_[A-Z]* and building userland projects

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

    Date:        Fri, 14 Dec 2012 14:02:44 -0600
    From:        jtowler%soncom.com@localhost (John R. Towler)
    Message-ID:  <uepq2c8krf.fsf%peano.jtcl.org@localhost>

  |         The topic is uname(1) and uname (3), sysctl -a entries and their
  |         intended semantics in the English words of the man pages.

Alan Barrett replied ...

  | Sorry, I could not find a concise statement of your problem or
  | question.

I think his point was that the output from uname/sysctl includes
more detail than is really necessary to identify the system features
(eg: 6.0_BETA and 6.0 and 6.0_STABLE should really all be the same
as far as user level software is concernet)  The request was for some
way to just get the "6.0" without (for this purpose) meaningless
appendices, which aren't always easy to safely ignore.

John, to make your request clearer, it would be a good idea to
explicitly say what you are seeing, and what you want to see instead
(then you can explain why either the doc supports your interpretation,
or why your needs require something different than currently supported).

However ...


  | I can work with the smlnj build system to work around this build
  | problem.  But it seems that there should be a uname (1) option which
  | selects just the major or major.minor version of the OS, and this
  | problem area in where and how the kern.version information in the
  | /usr/src build also for uname -a gets fed to the libc functions etc.

But that indicates a major flaw in this approach.   Really the kernel version
info tells you almost nothing about what a user program can get access to
(there are some minor ioctls used by very few applications, where this is
actually useful to know, but those are not a common case).

What you really need to know is what the libc access functions will give
you access to, not what the kernel would permit of only libc allowed it.

For example, I have run 6.* (and 5.*) kernels with everything else on
the syste, being NetBSD 4 (and 5.* kernels where all the userland was
NetBSD 3 based).  It is irrelevant that some new function may be
available in NetBSD 6 if the sys calls all use NetBSD 4 compatability
access routines, and return the same data that a NetBSD 4 kernel would
have returned.

If your configuration looks at uname output, and determines from that
that the kernel is NetBSD 6, and so its sys calls (etc) should do ..
and then the software was built on my system, it would fail miserably.

So, if your purpose is to discuss just what should be available from
uname, and sysctl os.version (etc), and/or what should be, that's fine.
But don't use building smlnj as a use case for wanting something
different, as if its build is depending on that information, it is
really much more broken than anything that matters because of a stray _RC2
being appended somewhere it isn't expected.

The right way is to explicitly test whether various features are supported
or not, and then use them if so.   The kernel version really cannot tell
you that.

kre