Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Sep 2016 18:41:46 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-doc@FreeBSD.org
Subject:   [Bug 213012] Clarifying what hw.physmem returns
Message-ID:  <bug-213012-9@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213012

            Bug ID: 213012
           Summary: Clarifying what hw.physmem returns
           Product: Documentation
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: Documentation
          Assignee: freebsd-doc@FreeBSD.org
          Reporter: djensen@macsales.com

Apparently at some point FreeBSD changed the variable type returned by
hw.physmem but this has not been documented.  The only documentation I found
for hw.physmem is in conjunction with the sysctl(8) where it says it return=
s an
integer.  However this not 100% accurate as the actual integer type that
FreeBSD returns when the following command is run:

sysctl hw.physmem

Is uint64_t (or unsigned long long int) and all the documentation I could f=
ind
that referenced hw.physmem says it should return an int32_t (signed 32 bit
integer).  Now while it is better to return the uint64_t value this is not =
what
appears to be the normal standard of what this variable returns.  This
undocumented inconsistency only leads to confusion should someone try to lo=
ok
up the general documentation concerning the hw.physmem value.

It would be a good idea on the following page:

https://www.freebsd.org/cgi/man.cgi?sysctl(8)

To change at least the following line:

hw.physmem                               integer       no

To the following:

hw.physmem                               uint64_t      no

This would at least clarify exactly what this sysctl will be returning if t=
he
command above is run.  I am assuming if one does not give the return value =
an
integer of the appropriate size that there is possibility that it would exc=
eed
the maximum value allowable whenever RAM exceeds 2.15 GB

Personally I think all the variables listed on that page should have their
"exact" variable type listed rather than a generic variable type or at leas=
t a
reference of what variable types it may return if the return type is dynami=
c in
some way.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-213012-9>