rwatson at FreeBSD.org
Thu Oct 18 04:17:02 PDT 2007
On Thu, 18 Oct 2007, Poul-Henning Kamp wrote:
> In message <20071018113431.K60783 at 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.
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
University of Cambridge
> What was that? He did ? Really ?!
> Well, I can try that...
> $ sysctl -nb kern.geom.confxml | head -10
> <class id="0xc53b7da0">
> <geom id="0xc5396b00">
> <class ref="0xc53b7da0"/>
> <consumer id="0xc4f91580">
> <geom ref="0xc5396b00"/>
> <provider ref="0xc4f44900"/>
> AUGH!!! :-)
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> phk at 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.
More information about the freebsd-arch