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 f

[Scott Long]

Joao Barros wrote:
> On 10/15/07, Scott Long <scottl at samsco.org> wrote:
>> Alexander Leidinger wrote:
>>> 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.
>>>
>> For the love of God, please don't use RAID as an example to support your
>> argument for the sensord framework.  Representing RAID state is several
>> orders of magnitude more involved than representing network state.
>> There are also landmines in the OpenBSD bits of RAID support that are
>> best left out of FreeBSD, unless you like alienating vendors and risking
>> legal action.  Leave it alone.  Please.  I don't care what you do with
>> lmsensors or cpu power settings or whatever.  Leave RAID out of it.
>>
>> Thanks,
>>
>> Scott
> 
> Are you saying I shouldn't proceed with the bio port?
> 

As has been discussed in various forums recently, this OpenBSD sensors 
stuff has been proceeding with little developer buy-in or discussion,
and the developer input that has happened has largely been ignored.  So
with that said, let's all turn over a new leaf and get this process back
on track.  What exactly is the "bio port"?  What does it do, what areas
of the kernel and userland does it involve, what does it change, why is 
it a good idea?

Scott