On 04/25/13 13:32, Mike. wrote:
On 4/25/2013 at 4:47 AM Polytropon wrote:
|On Wed, 24 Apr 2013 22:32:17 -0400, Mike. wrote:
|> If uname -r [-a] does not give the proper version of the OS, then it
is
|> either a bug, or the documentation for uname should be changed.
|> Currently, the man page for uname gives the following option:
|>
|> -r Write the current release level of the operating system to
|> stan-
|> dard output.
|
|Also the manpage of uname(3) would require a change to make clear
|that the version of the _kernel_ is provided, which _may_ stay the
|same during patchlevels of a given version. From that point of
|view, if we consider the patchlevel _not_ being part of the OS
|_version_, the statement (as it currently reads) makes sense.
|The understanding is: Version 9.1 is the OS version, and if
|a patch has been added, it's still 9.1 (even though the more
|precise information is 9.1-p5 for example). Similarly consider
|followint -STABLE: in this case, 9-STABLE or 9.1-STABLE is being
|reported, because no "precise" version numbers exist on that
|branch (at least not in the terms of patchlevels, instead a
|repository revision number or the date of the checkout could
|be considered for precision).
|
|The uname program relies on the uname system call to get the
|system identification, which queries the information stored in a
|(struct utsname *) data structure:
|
| The uname() function stores NUL-terminated strings of information
|identi-
| fying 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:
|
| release Release level of the operating system.
|
| version Version level of the operating system.
|
|This part of documentation would, given the case, also require
|adjustment, refering to the kernel instead of the OS.
=============
On the other hand, maybe instead of changing the documentation of uname
to accommodate a problem with freebsd update, maybe freebsd update
should be changed to accommodate the historical and expected
performance of uname.
In other words, once I found out this problem with freebsd update
(i.e., not properly refreshing the OS version), I stopped using it, as
I was not able to ascertain the current state of my OS installation
anymore.
Interesting. My only observation was that sysctl is supposed to be the
'system' database where all queries relate to. It is supposed to display
everything about the system; therefore any of these data bits should be
fixed here first. Anything else would be a 'feature' :)
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
