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 Mon, 15 Oct 2007  
07:13:07 +0000):

> In message <20071015081507.yi9t4ot8asg0wcw4 at webmail.leidinger.net>,   
> Alexander Leidinger writes:
>> Quoting Poul-Henning Kamp <phk at phk.freebsd.dk> (from Sun, 14 Oct 2007
>> 17:54:21 +0000):
>>
>>> My only beef is with the architecture of the sensors framework, and
>>> as a consequence thereof, with the actual code as well.
>>
>> When I asked you about a proposal how a better architecture looks
>> like, you didn't came up with an explanation and you didn't came up
>> with a list of things which you think are bad in the sensors
>> framework. You also didn't respond to counterarguments from me.
>>
>> [...]
>>
>> Could you please explain how you want to integrate devices with
>> newbus, which are only accessible via the i2c bus? Feel free to show
>> us example code for one of those of our drivers which access the i2c
>> bus, which already existed before this commit.
>
> So, lets see how that works:
>
> 	I propose that we write our own C/C++ compiler in perl.
>
> 	You object to that.
>
> 	Then I tell you: Now YOU have to write the compiler.
>
> No, I didn't think so either :-)

Come on Poul, you know that the response to such an objection would be  
to ask for reasons for the objection and the constructive continuation  
would be to point out weaknesses in an understandable way (and  
pointing out better ways if known) by the person with the objections.

> I have several times in the past pointed out why it is a very bad
> idea to add a unstructured dumping ground to the kernel, and why
> it is bad to stick code in the kernel that can easier live in
> userland.

And I responded that we need to have a way to export data from the  
kernel to userland in an unified way. No need to replicate a lot of  
code in a lot of places to export the data. When the data is out of  
the kernel in an unified way, one can do a lot of things with it in an  
automated way (e.g., use it in nagios or cacti, or whatever), but so  
far we don't have a framework for this.

I don't say the sensors framework can not be improved (in fact we got  
some improvement suggestions) or that I know more than you, but I  
think it doesn't deserve that much noise as is happening here currently.

Regarding your argument to move some parts into the userland (if not,  
please point out what you are talking about)... I assume you are still  
talking about the temperature sensors. 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. I can  
not remember that you objected to this security improvement or  
provided technical arguments which made this point obsolete. Feel free  
to point me to a corresponding mail I may have missed. Feel also free  
to point out where Constantine or me aborted discussing things with  
you, so far I remember that you didn't follow up on our last responses  
to what you wrote the last time we talked about the sensors framework.

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

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

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

Constantine agreed to improve what we have. So far the code is not  
scheduled to go into 7.0 (and based upon the constructive suggestions  
we got so far the code we have currently will not be in 7.0 for sure).  
The code we have currently doesn't harm the system, provides  
additional features, is far from seeing a release ATM (8.0 is about 18  
months away, plenty of time to remove unwanted parts), and the primary  
author agreed to work on improvements.

 From an userlevel point of view the current offering is not bad. We  
get an unified way of getting status information in a safe way. From a  
developer which doesn't work on the framework point of view, the  
kernel compiles and is not destabilized by the commit. The framework  
is also not spread over the entire kernel.

You object to the current implementation because you think it is bad.  
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.

You don't go to court and tell someone is guilty and then the person  
has to prove he/she is not guilty. To me your objection looks similar  
to the way Microsoft talks about patent issues in Linux... "I know you  
do bad things but I don't tell you what". We all know that a lot of  
people don't like this way of "doing business". If someone thinks my  
view of this is way off, please tell me. Really, I want to know about  
this if you think this is the case.

So please, tell with concrete examples what's bad and why in your  
opinion, and let Constantine have a look at it. For newbus and  
taskqueue(9) we already have pointers for improvement, and I assume  
Constantine is looking at them now. As far as I know the personality  
of Constantine (I don't know him personally, just what I've seen here  
on FreeBSD lists and in some private mails from him), I think he  
either will use all constructive criticism to improve the framework,  
or come up with an explanation why it is not possible to integrate  
this suggestion in the framework.


Note: some people pointed out that Pouls initial behavior was  
needlessly rude and notified core@ because of this. Regardless from  
the fact if I agree or not, I want to tell you that I'm not pissed off  
at all and haven't switched to some aggressive countermeasure mode.  
While this may be more or less normal behavior for a human being in  
such a situation, I have the opinion that such reactions just result  
in a drop of life quality. I managed to teach myself to stay more and  
more calm in such situations. Typically I switch to a reduced emotions  
mode where I try to come up with logical arguments. So if someone  
reads my mail in some aggressive way, please start again and imagine a  
calm intonation with the intend of going forward in a way which is  
beneficial for the FreeBSD project. I would also suggest that everyone  
who wants to answer tries to step back for a moment to analyze his own  
feelings. If those feelings are not calm, then I suggest to sleep a  
night over an answer.

Bye,
Alexander.

-- 
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137
You know you've been spending too much time on the computer when your
friend misdates a check, and you suggest adding a "++" to fix it.