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
Hello,
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
DESCRIPTION
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)
NAME
uname -- get system identification
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include <sys/utsname.h>
int
uname(struct utsname *name);
DESCRIPTION
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.
RETURN VALUES
If uname is successful, 0 is returned, otherwise, -1 is returned and
errno is set appropriately.
ERRORS
The uname() function may fail and set errno for any of the errors
specified for the library functions sysctl(3).
SEE ALSO
uname(1), sysctl(3)
STANDARDS
The uname() function conforms to IEEE Std 1003.1-1990 (``POSIX.1'').
HISTORY
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
6.0_STABLE
bash-4.2# uname -m
i386
bash-4.2# uname -s
NetBSD
bash-4.2# uname -v
NetBSD 6.0_STABLE (Peano6) #0: Tue Dec 11 22:24:48 CST 2012
jtowler%peano.jtcl.org@localhost:/usr/obj/sys/arch/i386/compile/Peano6
%% 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 peano.jtcl.org 6.0_STABLE NetBSD 6.0_STABLE (Peano6) #0: Tue Dec
11 22:24:48 CST 2012
jtowler%peano.jtcl.org@localhost:/usr/obj/sys/arch/i386/compile/Peano6 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
jtowler%peano.jtcl.org@localhost:/usr/obj/sys/arch/i386/compile/Peano6
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
observations.
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/{install.sh,_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
jtowler%soncom.com@localhost
Home |
Main Index |
Thread Index |
Old Index