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]

In message <20071015152408.10kvgtog6cooc4wc at webmail.leidinger.net>, Alexander L
eidinger writes:

>And I responded that we need to have a way to export data from the  
>kernel to userland in an unified way.

I can't seem to find the supposed requirement for unification here,
and in fact, it is exactly that a lot of crap gets bundled up
under the wildcard term of "sensor" that I object to.

The stuff I see people putting under the sensor framework doesn't
have anything to do with each other, and all the sensor framework
ends up being is a "small amount of data export" interface.

>I already told you last time  
>that the current way (access to the i2c or smbus) needs more access  
>rights than using the userland parts of the sensors framework.

More rights than what exactly ?

>> Right now, the people who advocate importing the OpenBSD sensor
>> framework need to tell us, in a coherent architecture document:
>>
>>    A) Why we need it
>
>Already told here and in the past. I haven't seen any word from you  
>that those reasons are not enough for you (and why).

No, I have yet to see why we need this framework.

I have heard various arguments for why we need certain specific
piece of data, but I have not heard why unifying all sorts of stuff
in a new, badly designed kernel interface is needed.

>>    B) Why so much of it ends in the kernel
>
>If you talk about the temperature/voltage sensors: Already told here  
>and in the past. I haven't seen any word from you that those reasons  
>are not enough for you (and why).

Anything that can be sensibly done in userland should be.

The fact that it might take more work to do it properly is no excuse
for this requirement.

>>    C) How it integrates into FreeBSD and for the places where
>>       it does not (newbus ?) why it doesn't.
>
>The improvement suggestions we got from someone else (private mail)  
>deal with newbus and provide an example. The suggestions also talk  
>about using taskqueue(9) and some other things. This critique is what  
>I call "constructive". From you I've only seen hand waving and whistle  
>blowing so far. Can we please go to a constructive way of criticism?

It is hard to provide socalled "constructive criticism" when ones
attitude to the entire concept is that it should be dragged behind
the barn, summarily shot and buried right there and then.

It's even harder to be constructive, when one registers ones opinion,
only to see it completely ignored.

>The code we have currently doesn't harm the system, [...]

This is where I disagree: it does harm the system.

It dumps a load of badly thought out code into our source tree, and
that will effectively be in the way of any well thought out solution
that might ever appear.

This stuff should be backed out, and forced to live outside the tree
until it satisfies our quality and architectural requirements.

Forcing it to stay out of -current, means that the motivational
pressure is on the people who thing we badly need this featureset,
and gives them reason to improve it.

Leaving it in the tree, is the sure fire way for it to become an
unmaintained lump of code that slowly rots away.

>You object to the current implementation because you think it is bad.  

s/think/know/

>Ok, I don't object to your objection. All I ask is to put the cards on  
>the table so that we can find a way forward. A way which gives the  
>users the new feature, and you the satisfaction of no bad parts in the  
>kernel you object to.

The solution to that is to remove it from -current, let it live in
P4 until such time that it passes muster in a review on arch@ which
gives relevant people a chance to study and comment on it.

>You don't go to court and tell someone is guilty and then the person  
>has to prove he/she is not guilty.

No, I go to court, get a prelimnary injunction so that he is forced
to stop while a proper review is carried out.

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.