Porting OpenBSD's sysctl hw.sensors framework to FreeBSD

[Alexander Leidinger]

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.

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

>> > seen so far is that for software RAID the firmware you are talking to is
> the
>> > driver, not firmware on the card, so you use ioctls directly rather than
> an
>> > ioctl that sends a command to the firmware on the card.
>>
>> But you have to run this tool as root, don't you? You don't want to
>> let a user run such a tool (and nowadays even desktops start to have
>> RAID, so whoever sits at the machine may be interested to see some
>> status on his desktop).
>
> 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...

Bye,
Alexander.

-- 
In Christianity, a man may have only one wife.
This is called Monotony.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137