Date: Mon, 15 Oct 2007 23:32:25 -0400 From: "Constantine A. Murenin" <mureninc@gmail.com> To: "Alexander Leidinger" <netchild@freebsd.org> Cc: Scott Long <scottl@samsco.org>, src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, "Constantine A. Murenin" <cnst@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Wilko Bulte <wb@freebie.xs4all.nl> Subject: Re: 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 Message-ID: <f34ca13c0710152032h2dc35f84sa563cd3e75dfd081@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
On 15/10/2007, Alexander Leidinger <netchild@freebsd.org> wrote: > Quoting Scott Long <scottl@samsco.org> (from Mon, 15 Oct 2007 01:47:59 -0600): > > > Alexander Leidinger wrote: > >> Quoting Poul-Henning Kamp <phk@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f34ca13c0710152032h2dc35f84sa563cd3e75dfd081>