Date: Thu, 3 Mar 2011 13:34:45 -0800 From: Matthew Fleming <mdf356@gmail.com> To: Brandon Gooch <jamesbrandongooch@gmail.com> Cc: hackers@freebsd.org, David Wolfskill <david@catwhisker.org> Subject: Re: Puzzled about VFS sysctl OIDs -- signed vs. unsigned Message-ID: <AANLkTi=1-AOF6jFQjzRSQ3oPGFi5mdKUhDOD0UW5gtw=@mail.gmail.com> In-Reply-To: <AANLkTinNQJmVCW3guKzOxbco-C5NDeUuXBnUm1-MRNvA@mail.gmail.com> References: <20110303174948.GF1471@albert.catwhisker.org> <AANLkTinNQJmVCW3guKzOxbco-C5NDeUuXBnUm1-MRNvA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 3, 2011 at 1:03 PM, Brandon Gooch <jamesbrandongooch@gmail.com> wrote: > On Thu, Mar 3, 2011 at 11:49 AM, David Wolfskill <david@catwhisker.org> w= rote: >> 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, >> =A0 "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? =A0If so, how should I interpret su= ch >> 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-Typ= e-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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=1-AOF6jFQjzRSQ3oPGFi5mdKUhDOD0UW5gtw=>