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

[Sam Leffler]

Alexander Leidinger wrote:
> Quoting Scott Long <scottl at samsco.org> (Mon, 15 Oct 2007 07:50:05 -0600):
>
>   
>> 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?
>>>       
>
> I would suggest to stop for some days, maybe Scott comes up with
> a description of something better.
>
>   
>> As has been discussed in various forums recently, this OpenBSD sensors 
>> stuff has been proceeding with little developer buy-in or discussion,
>>     
>
> Wait please. It was on the ides list before the soc and during the soc.
> There where links to an overview and to source files. And several
> committers voted in the Google soc interface for this framework (else
> another project would have been chosen instead). The code was shown
> around on public lists several times and some developers (I don't
> remember exactly which developers, we would have to check in the
> archives) provided some improvement suggestions during the soc which
> where incorporated/discussed.
>   

SoC projects are not expected to go into CVS.  It's nice when they do 
but that is not the purpose of them (IMO).

>   
>> and the developer input that has happened has largely been ignored.  So
>>     
>
> Sorry, but this is not true. Poul objected before, yes. We started to
> talk with him, and then he stopped talking with us. I'm not aware that
> we insulted him or gave him other reasons to stop talking with us. So
> saying that his objections where ignored is not fair, I think.
>
> In total we have Poul on one side not wanting this framework, and
> several committers which agreed that the framework would be nice to
> have.
>
> I may be wrong, but I think Poul was also one of the people with voting
> rights and as far as I remember I didn't voted against the sensors
> framework (can probably be checked in the google webinterface for the
> soc).
>   

You seem to have selective hearing.  You have already received multiple 
responses (>3) that say BACK IT OUT but I only see your responding to 
phk (and to scott about the bio stuff).  Constantine received numerous 
mails while he was working on his SoC project that said folks did not 
entirely agree with his approach.  BUT because it was an SoC project and 
NOT code ready to be committed to CVS it was fine for him to continue 
down the path he did.  I for one always assumed that before any code 
went into CVS there'd be public review and a consensus agreement before 
a commit.  You have, for some reason, decided to push this stuff into 
CVS w/o taking the obvious step of requesting review.

>   
>> 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?
>>     
>
> It provides the possibility to do with raid, what ifconfig does with
> network interfaces. Like we have some standardized driver interfaces
> for network cards, the bio framework standardizes some interfaces
> (ioctls) for raid drivers. It is up to the raid driver writter to
> do the corresponding action. An example for such actions is blinking of
> LEDs in external enclosures or of harddisks (if possible/implemented in
> the driver) to identify parts for whatever reason (e.g., failed disk).
> Other examples are device listings, raid creation and hotspare handling.
>
> So it changes the need for the vendor/driver writter to come up with
> its own management application. He doesn't need to do the userland
> stuff, he only needs to provide the kernel driver.
>
> For the user this improves the administration situation, he doesn't
> need to know several applications with different syntax to do the raid
> management (if there's such an application at all), he just need to
> know one. Apart from ifconfig you maybe can also compare it with
> atacontrol for ATA and camcontrol for SCSI (camcontrol is not really a
> good example, but I include it regardless).
>
> This may not provide management controls for all possible features of
> a specific raid hardware, but as with our NIC driver interface which was
> extended from time to time, we can extend the bio framework as needed
> (which basically means to write down the name of an ioctl and describing
> the semantic of it).
>
> Bye,
> Alexander.
>
>