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

[Alexander Leidinger]

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.

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

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

-- 
      ...and that is how we know the Earth to be banana-shaped.
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137