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

[Alexander Leidinger]

Quoting Poul-Henning Kamp <phk at phk.freebsd.dk> (from Wed, 17 Oct 2007  
20:36:11 +0000):

> In message <20071017160440.b6fd00xs6cog888g at webmail.leidinger.net>,   
> Alexander L
> eidinger writes:
>> Quoting Poul-Henning Kamp <phk at phk.freebsd.dk> (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.

Again, we don't need to put everything what OpenBSD puts into  
hw.sensors into our hw.sensors. If you object to include the time  
stuff into hw.sensors when we have an existing and good API for this,  
I don't object. I even agree with you, as this would be a good  
technical argument. But this is unrelated to the sensors framework  
(the API). It is related how this API is used. Nothing prevents us to  
come up with a policy how this API shall be used.

And for the "in a system" part, see my answer to Julian Elischer. You  
are talking about something what I call "single-system sensor  
framework" in the mail to him.

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

There was no modification to your time-stuff in FreeBSD. Instead of  
complaining against the entire sensors framework, you could asks to  
include a text somewhere, which tells that we are not interested to  
add a sensor for the time stuff and why.

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

Keeping the irrelevant stuff away means instantiating a policy.  
Nothing prevents us from this. Feel free to start by contributing a  
text which states that we don't want time sensors and why. For the  
relevant things where you think it doesn't do enough, you should tell  
us what you are talking about and why it is relevant. Maybe what you  
want can be done without problems. As you haven't looked at the  
framework itself (as you said you don't like the idea to an extend  
that it is not even worth looking at it), you are in a weak position  
to tell something can not be done with it (we've seen several times  
that high level things you used to object against the sensors  
framework integrate without problems into the sensors framework).

Bye,
Alexander.

-- 
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137
The man who can smile when things go wrong has thought of
someone he can blame it on.