From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 22:03:11 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23104106566C for ; Thu, 3 Mar 2011 22:03:11 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A853A8FC18 for ; Thu, 3 Mar 2011 22:03:10 +0000 (UTC) Received: by wyb32 with SMTP id 32so1786169wyb.13 for ; Thu, 03 Mar 2011 14:03:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=23X58G1/Z/L88uGOguuqrYqyhS8neb2JjN4cw8ljWJE=; b=S5Jc2rAhTvWFeZHpf/mGtQbQo3rTNjxuuf8bSu7oIuD1mPAulZR5Ci6STLsQ8DEFOa OySEXnOR5tV4y57BN9a2R8aqetprJMJS+F9XJSklySI/uePBS0Y8FVFUKA0g8gwcnHH3 /NbQuEXMNN9q/aRyAgpf75d6nv5qmco5AkHN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TvdPQubLDRbEcvtwd9CulF++x3Kdros15m8Q4bK+CNYoFCFkGHdKYO6+WeVP5k7Zjx JbZoq2YT66Xbf1Y5NpdG9PnzQiQOmGkY79BR1sTcNAwMga4iCUDWTY1egb0j4MLUIELC smCBcSYjsNqK+lFJs7+gTcVJJKPOZRnawfaR0= MIME-Version: 1.0 Received: by 10.216.167.13 with SMTP id h13mr1281246wel.95.1299189789604; Thu, 03 Mar 2011 14:03:09 -0800 (PST) Received: by 10.216.25.72 with HTTP; Thu, 3 Mar 2011 14:03:09 -0800 (PST) In-Reply-To: References: <20110303174948.GF1471@albert.catwhisker.org> Date: Thu, 3 Mar 2011 16:03:09 -0600 Message-ID: From: Brandon Gooch To: Matthew Fleming Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org, David Wolfskill Subject: Re: Puzzled about VFS sysctl OIDs -- signed vs. unsigned X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 22:03:11 -0000 On Thu, Mar 3, 2011 at 3:34 PM, Matthew Fleming wrote: > On Thu, Mar 3, 2011 at 1:03 PM, Brandon Gooch > wrote: >> On Thu, Mar 3, 2011 at 11:49 AM, David Wolfskill = 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, >>> =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 s= uch >>> 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-Ty= pe-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. =A0This > 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 Yes, it's wrapping. I wonder, would an audit of the SYCTL_* types be of general use to FreeBSD? I haven't ran into these issues myself, but I can see where this could become more of a problem with the OS in general as larger, heavier loads are placed on general-purpose type systems; where FreeBSD has been used in a product, I assume that the companies engineers, such as those at Isilon, have applied local patches where necessary. Y'know, I think this could be a good GSoC project after all... -Brandon