sensors fun..

[Robert Watson]

On Wed, 17 Oct 2007, Max Laier wrote:

> On Wednesday 17 October 2007, Poul-Henning Kamp wrote:
>> In message <47166BA5.1000100 at elischer.org>, Julian Elischer writes:
>>>> Having a userland interface also makes it easier to have backends that 
>>>> are entirely in userland.
>>>
>>> maybe a loopback filesystem
>>
>> Just what is it that is so enticing about the kernel ?  Why not simply pass 
>> it to a daemon ?
>
> What I like about the OpenBSD framework is, that you can get the sensor data 
> with basic tools.  What's wrong with "everything is a file"?  With a file 
> system you don't have to jump through any hoops to provide concurrent access 
> to more than one reader.  You could easily create symlinks to map sensors to 
> location.  You have means to restrict access to certain sensors. etc. ...

Actually, experience with procfs suggests that you do have to deal with these 
problems and more.  For example, cat offers quite a small read buffer on a 
file, so what should the kernel do if the read buffer is too small to hold all 
the data from a procfs file?  I.e., with /proc/pid/map?  Should it snapshot 
the state so that iterative reads work to pull out a complete snapshot, 
requiring handling of concurrency between simultaneous openers -- perhaps 
multiple snapshots at once or limiting to one reader at a time. 
Alternatively, it could truncate the read and not report an error, or fail? 
In procfs, we fail, returning an I/O error if the buffer passed by the user 
app is too small, resulting in user confusion when a process's memory mappings 
exceed default buffer sizes for common command line tools.  Instead you have 
to run 'dd if=/proc/pid/map of=/dev/stdout bs=64k" or the like.

Sysctl offers a typed data semantic and defined atomicity model, as well as a 
decent way to query how much space is needed and handle cases where not enough 
space is available.  You won't find me arguing sysctl is perfect, but it has a 
number aspects of great value.

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.  You only have 
to look at the historic linprocfs/linux procfs parts to see what can go wrong 
with free-form data representation :-).

Robert N M Watson
Computer Laboratory
University of Cambridge