tech-kern archive

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

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

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

        I have a problem with the current (110.75) and last versions
        (110.74) of smlnj, of which I thought to build the newest
        smlnj-110.75 this morning.

        The build, given a few system dependent edits is fairly
        automatic in general.  The problem is that due to a
        configuration shell script which relies on uname (1), here
        specifically uname -r for the OS version to type and label for
        OS-type and arch the sml base heap it builds.

        For NetBSD-6.0 using the cvs -r netbsd-6 pulls, the kernel has
        somewhere in it an id tag which actually reads
        NetBSD-6.0_{BETA,BETA1, BETA2, RC1, RC2,STABLE} or such,
        reflecting the minor or tiny version etc. divisions of the OS
        release tag, and the script is breaking on it because sh is
        parsing the regex following 6. as not including the all caps
        minor revision of NetBSD-6.0, and thus the bsd-x86 tag is not
        formed and no sml heap is built for smlnj to finish.

        from man 1 uname

     The uname utility writes symbols representing one or more system
     characteristics to the standard output.

     The following options are available:

     -a      Behave as though all of the options -mnrsv were specified.

     -m      print the machine hardware name.

     -n      print the nodename (the nodename may be a name that the system is
             known by to a communications network).

     -p      print the machine processor architecture name.

     -r      print the operating system release.

     -s      print the operating system name.

     -v      print the operating system version.

UNAME(3)                   Library Functions Manual                   UNAME(3)

     uname -- get system identification

     Standard C Library (libc, -lc)

     #include <sys/utsname.h>

     uname(struct utsname *name);

     The uname() function stores nul-terminated strings of information
     identifying the current system into the structure referenced by name.

     The utsname structure is defined in the <sys/utsname.h> header file, and
     contains the following members:

           sysname       Name of the operating system implementation.

           nodename      Network name of this machine.

           release       Release level of the operating system.

           version       Version level of the operating system.

           machine       Machine hardware platform.

     If uname is successful, 0 is returned, otherwise, -1 is returned and
     errno is set appropriately.

     The uname() function may fail and set errno for any of the errors
     specified for the library functions sysctl(3).

     uname(1), sysctl(3)

     The uname() function conforms to IEEE Std 1003.1-1990 (``POSIX.1'').

     The uname function first appeared in 4.4BSD.

NetBSD 6.0_STABLE               March 30, 2011               NetBSD 6.0_STABLE

Somewhere buried in libc is how this data structure is filled.  I
started to take a look throught /usr/src to find it, but then I came to
a question, maybe what is meant for no such _BETA suffixes is not passed
to the struct for uname(3).

bash-4.2# uname -r
bash-4.2# uname -m
bash-4.2# uname -s
bash-4.2# uname -v
NetBSD 6.0_STABLE (Peano6) #0: Tue Dec 11 22:24:48 CST 2012

%% built by concatenation separated by whitespace from $(uname -s)
%%$(uname -r) and the rest from the kernel ident in
%%/usr/src/sys/arch/i386/config/Peano6 including the automatic kernel
%% revision number, and the rest about the compiled kernel in use.

bash-4.2# uname -a
NetBSD 6.0_STABLE NetBSD 6.0_STABLE (Peano6) #0: Tue Dec
11 22:24:48 CST 2012 i386

%% The same as expected for uname -a plus $(uname -m) appended at the
   tail of the string, but...

from man sysctl, and applying the result.

bash-4.2# sysctl -a | less

kern.ostype = NetBSD
kern.osrelease = 6.0_STABLE
kern.osrevision = 600000000
kern.version = NetBSD 6.0_STABLE (Peano6) #0: Tue Dec 11 22:24:48 CST 2012

My question is that for other programs that rely on uname(1) and
uname(3) and the assigned readings in the man pages, is what the man
pages mean reflected in kern.version = {above version with ident stuff}
above and uname -a = same {above version with ident stuff and uname -m},

how is such a minor/tiny/micro version ordering string appended to the
cvs tag netbsd-6 edition pulled of a certain date reflecting 

           release       Release level of the operating system.

           version       Version level of the operating system.

and how is the full combination of uname opts with the kernel config
file's ident tag which seems to be taken straight from sysctl's
kern.version fit in with these apparent man page readings and

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.

Maybe this is the POSIX spec also which is cited.  I can do more reading
about this.  But people know here, why is uname -v under the current
reading and implementation the OS name etc. and then the kernel config
ident string and compilation information, and where the problem is for
my concern --- how does a calling program branching on OS features, make
use of the full OS name number and ident tags here for uname -v?  How
would a user or other program know from the kernel compilation version
details anything about what to expect in terms of system services and
characteristics of the OS?  I know because I configured the kernel to
build it or used a given one.  It helps me, as admin of the system to
remember what was done, but that is all.  So what systematic solutions
or understandings will help me address this problem area for using
uname(1) or uname(3) with other programs.  

For smlnj-110.[4-7][45] config/{,_arch_op-n-sys} as
distributed, I should be able to change the uname -r call in the complex
of shell scripts which run over the network to fetch as well to just
select the numeric major version or numeric major.minor versions that
the build system wants in order to just work.  It is possible to chop
the appended string off with perl or awk or sed and play with the #!
shell/interpreter etc. and sort out how the numerous shell scripts of
the build system interact, but none of these are as simple and elegant.
So, I thought I would ask people who know how this came about in the
build of /usr/src and the kernel and what best reflects the systematic
design of NetBSD and (BSD) Un*x and Unix.

Thanks in advance,
John R. Towler

Home | Main Index | Thread Index | Old Index