Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Apr 2013 13:43:03 +1000
From:      Da Rock <freebsd-questions@herveybayaustralia.com.au>
To:        freebsd-questions@freebsd.org
Subject:   Re: FreeBSD-update?
Message-ID:  <5178A647.4030302@herveybayaustralia.com.au>
In-Reply-To: <201304242332000938.0324FC0A@sentry.24cl.com>
References:  <201304242307.r3ON7AEg039368@chilled.skew.org> <201304242232170093.02EE4C98@sentry.24cl.com> <20130425044744.3ebda15f.freebsd@edvax.de> <201304242332000938.0324FC0A@sentry.24cl.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
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' :)




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?5178A647.4030302>