Date: Thu, 18 Oct 2007 12:17:01 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Max Laier <max@love2party.net>, "Constantine A. Murenin" <cnst@FreeBSD.org>, Julian Elischer <julian@elischer.org>, freebsd-arch@FreeBSD.org Subject: Re: sensors fun.. Message-ID: <20071018120730.N60783@fledge.watson.org> In-Reply-To: <55408.1192704998@critter.freebsd.dk> References: <55408.1192704998@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 18 Oct 2007, Poul-Henning Kamp wrote: > In message <20071018113431.K60783@fledge.watson.org>, Robert Watson writes: >> On Wed, 17 Oct 2007, Max Laier wrote: > >> There was a suggestion a few years ago on linux-kernel that procfs should >> be changed to export all data in XML -- on face value, that might be read >> as a rather mean joke, but really, it's quite a sensible suggestion. > > Some years ago, some nutcase argued for exporting kernelstate in XML in an > article on DaemonNews, and who knows, he might even have gotten away with > committing it to some unsuspecting BSD operating system if nobody paid > proper attention to his harebrained scheme. :-P It almost makes one wonder if we shouldn't define a new sysctl data type for structured text data. Mac OS X almost universally stores configuration information in plist files, which means that you can use a generic plist editor to make changes and perform basic syntax checking on configuration files you've never seen before. However, this does range a bit far afield from the thread topic. The basic point I was making is that sysctl offers a more semantically rich and, to be honest, better defined way of interacting with live subsystems than device files do in a generic sense. You can hammer down semantics for device nodes, but the code associated with sysctl is much simpler when the goal is to offer mib-like semantics even in quite simple cases (integer set/put). One of the concerns in this thread that did catch my eye is the notion of providing a sensor framework that ends up forcing us to distinguish control paths from monitoring paths. I dislike ioctl as much as the next guy, but where there's a sensor monitoring fan speed, logically associating the controls for fan speed with that sensor is important. Robert N M Watson Computer Laboratory University of Cambridge > > What was that? He did ? Really ?! > > Well, I can try that... > > $ sysctl -nb kern.geom.confxml | head -10 > <mesh> > <class id="0xc53b7da0"> > <name>BDE</name> > <geom id="0xc5396b00"> > <class ref="0xc53b7da0"/> > <name>ad4s4a.bde</name> > <rank>4</rank> > <consumer id="0xc4f91580"> > <geom ref="0xc5396b00"/> > <provider ref="0xc4f44900"/> > > AUGH!!! :-) > > Poul-Henning > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071018120730.N60783>