Date: Tue, 30 Jan 2001 13:04:10 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Kris Kennaway <kris@obsecurity.org>, Hajimu UMEMOTO <ume@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: ports/sysutils/gkrellm Makefile distinfo Message-ID: <Pine.NEB.3.96L.1010130125948.29561D-100000@fledge.watson.org> In-Reply-To: <32566.980877217@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 30 Jan 2001, Poul-Henning Kamp wrote: > >If ccd is now deprecated by vinum, [...] > > It isn't. Don't suppose we could have ccd export this information using ioctl's instead? Or we could remove the setgid anyway and simply require it be run as root. > >Dmesg should be modified > >to use a sysctl > > I thought it already did ? Nope. The dmesg source I'm looking at appears to frob through /dev/kmem using KREAD and friends. A ktrace of dmesg reveals that indeed, it does make a call to sysctl, but the real work happens using read on the kmem file descriptor. Part of the problem appears to be that, despite some claims to the contrary, we do have a desire that we be able to analyze dumps using vmstat/netstat/etc, and that there is no uniform interface for extract information using the appropriate choice of sysctl or KREAD, except for the process list handling, and the hack there is a little unfortunate. The use of direct reading of kmem will also get less and less happy as a result of mutexes, versioning of structs, and possibly inconsistent snapshots of data. We've already moved in the direction of exporting userland prepared versions of some structs, we probably need to move the rest of the way in that direction. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010130125948.29561D-100000>