Porting OpenBSD's sysctl hw.sensors framework to FreeBSD

[John Baldwin]

On Friday 13 July 2007 01:37:33 am Alexander Leidinger wrote:
> Quoting John Baldwin <jhb at freebsd.org> (from Thu, 12 Jul 2007 
14:04:33 -0400):
> 
> > 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
> 
> If the sensor querying is already cross-platform, it can also be used  
> in the kernel. You have the driver just call the cross-platform  
> function to get back a firmware command it then can send to the  
> hardware.

Not if the cross-platform code is in userland (think vendor-supplied 
binaries).

> > place to be monitoring raid status sending pages, e-mails, etc.  It's best 
to
> > let userland invoke sendmail, not the kernel. :)
> 
> I fully agree, but nobody wants to send mails from the kernel. We just  
> want to get the sensor data out of the kernel without the possibility  
> to fuck up the device from userland. You don't have a userland tool  
> for each NIC (which you need if you go the cross-platform-tool way),  
> we have a well defined interface there which allows to get back some  
> sensor data (wire speed, MAC address, IP address(es), ...) already and  
> we display it in ifconfig. There's one tool to query it (ifconfig),  
> and nobody complains about it being hard to do it in the driver  
> instead of in a cross-platform userland tool (and Sam enhanced  
> ifconfig to be able to get rid of the special tools for each WLAN NIC,  
> and everybody was happy about this). The sensors framework tries to  
> accomplish the same for sensor data. A driver (or something else in  
> the kernel) registers himself with the sensor framework, and then you  
> can use a generic tool to query all sensor data. No need to reinvent  
> the wheel (how to export, how to name, what unit to use), and a good  
> consistency (e.g. units used).

ifconfig doesn't use strings from sysctl.  It uses a more sophisticated 
interface with data structures, etc.  If you wanted to add a standard RAID 
monitoring interface, then I would add ioctl's for different RAID operations 
along with a set of generic RAID structures (probably based at least 
conceptually on DDF) so that there's an ioctl to return the current RAID 
config that gives you a list of virtual disks, basic virtual disks, etc.  You 
need to be able to enumerate volumes, enumerate disks, have generic state 
enums for volumes and disks, etc.

> > Whatever talks directly to the driver needs to run as root, yes, but  
> >  you could
> > always write a proxy app that receives requests from utilities running as
> > non-root and does its own access restrictions.
> 
> That's a lot of infrastructure you want to create for such a simple  
> task as displaying "resyncing 50% done" or "0 hotspares" or similar...

Strings are a horrible data interface.  The stuff I work on needs to send 
e-mails that are more like:

volume X on controller Y is degraded
the following disks(s) need to be replaced: drive 5 (enclosure 1, slot 2),
  drive 7 (enclosure 1, slot 4)

To do that sanely, I need to have access to data structures, not just 
arbitrary strings from a sysctl.

-- 
John Baldwin