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

I don't think it is fair to make such a noise, without coming up with  
technical facts.

Note: I don't object to backing out the commit. But as this seems to  
be on the desk of core@, I wait for their decision regarding this (as  
it is self contained and doesn't interfere with other stuff, we don't  
need to hurry).

> In OpenBSD the sensors framework has already turned into a dumping
> ground, and I have all reason to belive that we will see the same
> under FreeBSD.

It will be what we make out of this.

> See for instance Marc Balmers presentation from EuroBSDcon2007 about
> putting radio-timecode receivers under the sensors framework, or

I don't see a need to port this part instead of using the existing  
time-infrastructure in our kernel (and I don't have my fingers in the  
time related code at all like you, so I hope other people think  
similar).

> listen to the various mumblings about putting RAID-controller status
> under sensors framework.

What's wrong with this? Currently each RAID driver has to come up with  
his own way of displaying the RAID status. It's like saying that each  
network driver has to implement/display the stuff you can see with  
ifconfig in its own way, instead of using the proper network driver  
interface for this.

> IFF we want to have a general catch-all framework for representing
> any oddball state, LED or measurement in the computer, then we want
> it to be much better structured than the code we are discussing now.

Again, please point out specific deficits, so that Constantine and  
others can explain why it is like it is and may be able to come up  
with improvements which address your concerns.

> But it is not even clear to me that we want such a framework, it makes
> much more sense to keep the various indicators, measurements and
> other input in their respective subsystems.

We're back to the old discussion... please have a look there. You  
failed to respond with a technical counterargument when I presented  
the reasons why a framework to export sensoric data out of the kernel  
is good to have (in short: similar reason why we have a standard way  
of exporting status data from the network interface to ifconfig).

> And IFF we add such an amount of code to FreeBSD, we want to have it
> properly integrate into our kernel, using our device discovery
> and registration (newbus) and not probing random (i2c) busses willy
> nilly.

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.

Bye,
Alexander.

-- 
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137
GREAT MOMENTS IN AMERICAN HISTORY (#17):

On November 13, Felix Unger was asked to remove himself from his
place of residence.