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> (Mon, 15 Oct 2007 15:01:47 +0000):

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

You didn't comment on what I wrote about reducing the work of
reinventing a way to export the data we want to export again and again
and again and again...

> and in fact, it is exactly that a lot of crap gets bundled up
> under the wildcard term of "sensor" that I object to.

Exporting temperature readings / voltage measurement, system status is
not crap. And when you write some monitoring probes in a large server
farm, you don't want to hunt down every interesting data value in a lot
of places. If you have the possibility to get a description and
corresponding data value of several intersting stuff in a simple way,
regardless of what hardware is used or replaced by stuff from another
vendor, then it is a huge improvement. Specially if you work in a team
with multiple administrators with several knowledge levels, and
operators which have a low knowledge level but can follow some
procedures. This doesn't even talk about turn-around (people leaving
the company, entering the company) in the team itself.

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

The sensors are grouped in a hierarchy, the meta-data it contains
(hw.sensors.cpuX...) is good to feed to a monitoring solution in the
userland which lets the operator - which takes care about the
monitoring - understand enough what is going on.

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

One popular userland temperature/voltage reading tool (as it supports a
lot of popular devices) is mbmon. It is currently a SUID root
application. It is like this as it accesses the smbus and/or ISA I/O
ports directly. If we forget the ISA I/O ports part, we could maybe
switch to a mbmon-user, but I don't really want to have such an user be
able to query every device on the smbus.

systat and sysctl are not SUID/SGID and don't require some special
rights in /dev. I would say this is a big difference in favour of 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).
> 
> No, I have yet to see why we need this framework.

Several committers which voted for this project in the soc webinterface
seem to think otherwise, else they wouldn't have voted for it.

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

The unifying part is explained above. For the "badly designed" part I
would like to hear what you don't like about it or how you think a
better one looks like.

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

If you agree that needing higher privileges is not sensible, I agree.

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

Would you please explain how accessing the ISA I/O ports of those
devices or only specific devices on the smbus can be done properly
(without elevated privileges) without a kernel driver?

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

We're discussing it right now. And I was willing to discuss this even
back when you talked about it the first time. It was you which stopped
talking very fast. Several people think it is a good idea to have such
a framework, and so far I've only seen one voiced opinion, that it is a
bad idea to have such a framework.

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

How does this compare to your attitude of bringing stuff into the tree
and letting other people fixup collateral damage in the past? But I
drift away from the topic... so back to the sensors framework.

To be able to address our quality and architectural requirements, we
need first to know which quality and architectural requirements are
violated by which part of the code in question. As you seem to have
identified them, would you please so kind and share your concrete
findings?

> 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 did a psycho-analysis of Constantine so that you are able to tell
that he doesn't fix the issues while he agreed to improve the framework?

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

Great, so you know specific issues and can tell us about them (again,
other people pointed out specific stuff already and also pointed to
things which help to let Constantine improve the issues which where
pointed out).

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

And the judge first listens to your arguments and makes up his mind
before he issues a preliminary injunction.

So far I've seen from you only a "I don't like the idea of this
framework"... or maybe it can be described as "I don't see the benefit
this framework is supposed to deliver". I've seen also some very vague
descriptions of what is wrong. No pointing out specific issues from
you with a pointer to how it is done right.

Unfortunately my free time today was spend with writting mails in this
thread. As this created such a huge discussion, I would like to back
this out to let people calm down and come to a technical ground for
further discussion. I try to squeeze out some time somewhere today, but
if I fail I try to back it out tomorrow or on Wednesday (as soon as
time permits).

Bye,
Alexander.

-- 
      ...and that is how we know the Earth to be banana-shaped.
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137