Porting OpenBSD's sysctl hw.sensors framework to FreeBSD

[John Baldwin]

On Friday 13 July 2007 11:48:19 am Constantine A. Murenin wrote:
> On 12/07/2007 14:04, John Baldwin wrote:
> 
> > On Thursday 12 July 2007 03:00:08 am Alexander Leidinger wrote:
> > 
> >>Quoting John Baldwin <jhb at freebsd.org> (from Wed, 11 Jul 2007 
> > 
> > 11:45:26 -0400):
> > 
> >>>On Wednesday 11 July 2007 07:49:59 am Alexander Leidinger wrote:
> >>
> >>>>On the other hand you don't want to allow an userland tool to directly
> >>>>mess around with the registers on your RAID or NIC to get some status...
> >>>
> >>>Err, that's how all the RAID utilities I've used work.  They send 
firmware
> >>>commands from userland and parse the replies in userland.  One exception 
> > 
> > I've
> > 
> >>That's sad... they should provide this functionality in the driver  
> >>instead, it would allow to use access restrictions for some parts.
> > 
> > 
> > Not really, it avoids having to duplicate a lot of work in drivers that 
can be 
> > written once in a cross-platform userland utility.  Drivers aren't really 
the 
> > place to be monitoring raid status sending pages, e-mails, etc.  It's best 
to 
> > let userland invoke sendmail, not the kernel. :)
> 
> John, I'm sorry to disappoint you, but RAID drivers in OpenBSD don't 
> implement SMTP and don't do emails, they only provide updates to the 
> sensors framework when there are some changes in the state of the drive. :)
> 
> sensorsd(8) is used to send alerts and emails based on the information 
> from the sensors framework, and user configuration.
> 
> bioctl(8) is used to configure RAID for _all drivers_. There are no 
> separate utilities for RAID configuration based on brand-name, just like 
> nowadays there are no separate utilities for configuring Ethernet 
> adapters. [0]

According to the various manpages on www.openbsd.org you cannot configure 
arrays on the OS for at least mfi(4), ciss(4), twe(4), mpi(4) (like mpt(4) in 
FreeBSD) or ami(4) (like amr(4) in FreeBSD).  You can only do monitoring via 
hw.sensors for ciss(4) and ami(4), and the example for monitoring ami(4) in 
the manpage shows that you can only get volume level data, and as a _string_ 
and that you can't get backing physical drive status to know which physical 
drive has failed and needs to be replaced:

           $ sysctl hw.sensors.ami0
           hw.sensors.ami0.drive0=online (sd0), OK
           hw.sensors.ami0.drive1=degraded (sd1), WARNING
           hw.sensors.ami0.drive2=failed (sd2), CRITICAL

-- 
John Baldwin