Puzzled about VFS sysctl OIDs -- signed vs. unsigned

[Brandon Gooch]

On Thu, Mar 3, 2011 at 11:49 AM, David Wolfskill <david at catwhisker.org> wrote:
> I'm using a little shell script to capture selected sysctl OID
> values periodically, in an attempt to get a better idea how the
> resources of a system are being used during a long-running (usually
> measured in hours), mission-critical workload.
>
> In the process of testing this, I've seen some of the VFS sysctl
> OIDs (in particular) report negative values ... when the description
> looks to me as if the OID in question is intended to be a monotonically
> increasing counter.
>
> For example:
>
>> sysctl -d vfs.getnewbufcalls
> vfs.getnewbufcalls: Number of calls to getnewbuf
>> sysctl vfs.getnewbufcalls
> vfs.getnewbufcalls: -348909432
>
> Examining sys/kern/vfs_bio.c, the definition of vfs.getnewbufcalls
> appears to be:
>
> ...
> static int getnewbufcalls;
> SYSCTL_INT(_vfs, OID_AUTO, getnewbufcalls, CTLFLAG_RW, &getnewbufcalls, 0,
>   "Number of calls to getnewbuf");
> ...
>
> Many of the other OIDs defined nearby are also SYSCTL_INT (or
> SYSCTL_LONG), vs. SYSCTL_UINT (or SYSCTL_ULONG), and the corresponding
> variables are defined as static int (or static long) vs. static u_int
> (or static u_long).
>
> Is this both correct and reasonable?  If so, how should I interpret such
> negative values?
>
> [GSoC project, anyone?]
>
> Thanks!
>
> Peace,
> david

The following initiative may factor heavily into any decision to
change sysctl declarations at this point:

http://www.freebsd.org/news/status/report-2010-10-2010-12.html#SYSCTL-Type-Safety

I don't pretend to fully understand the reasons or impact of this
project, but I have to imagine that at least the scope is similar to a
proposed GSoC project (probably bigger).

-Brandon