Date: Fri, 3 Dec 1999 23:19:00 -0500 (EST) From: Kelly Yancey <kbyanc@posi.net> To: freebsd-hackers@freebsd.org Subject: oddities in sysctl -a Message-ID: <Pine.BSF.4.05.9912032230500.87947-100000@kronos.alcnet.com>
next in thread | raw e-mail | index | archive | help
I've got a box running 3.2 dated Tue May 18 18:39:26 EDT 1999 (I'de
upgrade but the 117 days uptime is putting the linux boxen in-house to
shame :) ). Anyway, here are some excerpts from sysctl -a that caught my
eye:
kern.dumpdev: { major = 255, minor = -65281 }
kern.ps_strings: -1077944336
kern.usrstack: -1077944320
vm.stats.sys.v_intr: -1837017521
vfs.cache.numchecks: -1447532299
Now, getting my hands dirty, I noticed that the entire vfs.cache sysctl
tree is registered in sys/kern/vfs_cache.c using SYSCTL_INT, even though
the variables are all declared as u_longs. However, being that I'm running
on i386 and ints and longs are the same size, I don't think that accounts
for what I'm seeing.
The problem seems to be that values registered with the kernel sysctl
interface cannot specify whether the values are signed or unsigned. Then
when sysctl reads the oid_fmt specifier back out, it assumes integers are
unsigned.
My immediate inclination it to add new format identifiers (maybe "LU"
and "IU" for the unsigned versions of long and integer respectively) and
update sysctl to understand the new formats. But the source tells me that
get-the-oid_fmt code should be axed. So the question is, should I bother
fixing it?
If so, I'll submit patches adding unsigned integer support along with
ones fixing the int/long bug in vfs_cache when I get home. I'm looking
forward to your input,
Kelly
--
Kelly Yancey - kbyanc@posi.net - Richmond, VA
Director of Technical Services, ALC Communications http://www.alcnet.com/
Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/
Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9912032230500.87947-100000>