sensors fun..

[Robert Watson]

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.

:-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 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.
>