Quoting Poul-Henning Kamp <[EMAIL PROTECTED]> (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.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
