Puzzled about VFS sysctl OIDs -- signed vs. unsigned

[Matthew Fleming]

On Thu, Mar 3, 2011 at 1:03 PM, Brandon Gooch
<jamesbrandongooch at gmail.com> wrote:
> 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

The intent of the type-safety is to make sure that the types assumed
for the kernel's sysctl handler match the type of the variable.  This
project won't fix issues where a signed type is being used and the
value wraps (at least, I presume that's what happened in this case?)

Thanks,
matthew