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 ...
netchild at FreeBSD.org
Sun Oct 14 23:16:21 PDT 2007
Quoting Poul-Henning Kamp <phk at phk.freebsd.dk> (from Sun, 14 Oct 2007
> 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
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
> 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
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.
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.
More information about the cvs-src