cvs commit: src/etc Makefile sensorsd.conf src/etc/defaults rc.conf src/etc/rc.d Makefile sensorsd src/lib/libc/gen sysctl.3 src/sbin/sysctl sysctl.8 sysctl.c src/share/man/man5 rc.conf.5 src/share/man/man9 Makefile sensor_attach.9 src/sys/conf files ...

Poul-Henning Kamp phk at
Wed Oct 17 13:36:15 PDT 2007

In message <20071017160440.b6fd00xs6cog888g at>, Alexander L
eidinger writes:
>Quoting Poul-Henning Kamp <phk at> (from Tue, 16 Oct 2007 =20
>17:32:40 +0000):

This discussion is growing too many branches, I have pruned to the
central core for now:

>> By defining the sensor API (on top of sysctl) at the kernel/userland
>> boundary you have decided that all sensor implementations must live
>> in the kernel, there is no room in your architecture for sensors
>> that live in userland.
>No, I didn't. I said (even last time when you first told us that you  
>don't like the sensors framework), that the sensors framework is  
>supposed to export data which lifes in the kernel to the userland. I  
>never said the sensors framework is supposed to be the one and only  
>way of getting status data from a running system.

This is what I think is the most fatal flaw in this design.

It is only an API for _some_ of the sensors in a system, and because
of that limitation, it invites people to try to shoehorn things
that do not belong there, into that subset.

In this case, that puts code into the kernel that should under no
circumstances (have to) live there.

The timekeeping sensors is a prefect example of that, since March
2000 RFC2783 has defined the API for such stuff, but rather than
go and do things properly, somebody goes and implements DCF77
decoding in the kernel.

Kernel Architecture is just as much about preventing things as
enabling them.

Sensors, as here presented, fails both criteria: It doesn't do
enough for the relevant subject matter, and doesn't keep 
irrelevant stuff abay.

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 cvs-src mailing list