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

[Constantine A. Murenin]

On 15/10/2007, Alexander Leidinger <netchild at freebsd.org> wrote:
> Quoting Scott Long <scottl at samsco.org> (from Mon, 15 Oct 2007 01:47:59 -0600):
>
> > Alexander Leidinger wrote:
> >> Quoting Poul-Henning Kamp <phk at phk.freebsd.dk> (from Sun, 14 Oct
> >> 2007 17:54:21 +0000):
>
> >>> 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.
>
> Talking about RAID status is not talking about alienating vendors. I
> don't talk about alienating vendors and I don't intent to do. You may
> not be able to display a full blown RAID status with the sensors
> framework, but it allows for a generic "wors/works not" or
> "OK/degraded" status display in drivers we have the source for. This
> is enough for status monitoring (e.g., nagios). I don't know if you
> talk about the OpenBSD bio framework or about some reverse engineered
> RAID drivers in OpenBSD (or bad mails from them to some vendors). From
> an user point of view the bio framework (as in "a generic interface
> for the sysadmin to do RAID stuff", and not as in "the concrete
> implementation in OpenBSD") is something you want to have. I don't
> think that it is a bad idea to port it (and improve it). OpenBSD has
> some RAID controllers converted to it and the framework already
> represents an usable interface for a lot of cases. I don't know if it
> needs improvement or not, I don't know if it can cover all current
> feature needs for such a framework for all possible RAID systems (most
> probably not), but it would be an improvement for vendors which want
> to write support for their RAID hardware as they don't have to come up
> with their own BSD code to manage those parts. And we could improve
> "our bio framwork" (if we had/get one) based upon vendor feedback (we
> already improved our network interfaces upon vendor feedback, haven't
> we?). In case you talk about porting some "alienated" raid drivers
> from OpenBSD... I agree that it is not a good idea to kick a vendor in
> the ass (a vendor which provides some kind of FreeBSD support... if
> there's a driver for raid hardware for which the vendor doesn't
> provide any support for a driver for FreeBSD at all, it depends upon
> the specific driver code from OpenBSD if it is a good idea to port it
> or not).
>
> So in short: having a generic framework would be beneficial for
> vendors. Kicking vendors in the ass is not my intention. Feel free to
> document pitfalls in the RAID stuff in OpenBSD, so that nobody in
> FreeBSd-land makes the same mistakes (but is able to get good parts if
> the idea of an unified interface into FreeBSD).
>
> Sorry for not taking the time to write a more readable mail.
>
> Bye,
> Alexander.

BTW, the RAID status part of the sensors framework was already ported
into NetBSD's sister framework, envsys(4).

So this approach to hardware monitoring is no longer unique to OpenBSD.

C.