sensors framework continued (architecture)

[Alexander Leidinger]

Quoting Nikolay Pavlov <qpadla at gmail.com> (Fri, 9 Nov 2007 18:51:10 +0200):

> On Friday 09 November 2007 13:44:21 Alexander Leidinger wrote:
> > Robert thinks that sysctl MIBs offer "a more semantically rich and, to
> > be honest, better defined way of interacting with live subsystems than
> > device files do in a generic sense". Nobody objected to this opinion or
> > provided reasons why a fd based approach is better than a sysctl MIB
> > based approach. Ricardo Nabinger Sanchez points out
> > http://www.ietf.org/rfc/rfc3433.txt (RFC for sensor MIBs).
> 
> I think a MIB approach is much more usefull between "Single-system sensors 
> framework" and "Group-level sensors framework" and a good example here is 
> a SNMP(the general usage example of the MIB defined in rfc3433). I am not 
> a kernel developer and don't know whether it's a good for pass the data or 
> not, but as experienced administrator should mansion that sysctl mib's is 
> expected (IMHO) to be used as a configuration interface to define a kernel 
> and system behavior. It's much more easy to use userland utilities such as 

We have a lot of read only sysctls, so it's de-facto not only a
configuration interface, but also a status description interface
already. And if you use top or ps, you already use the sysctl framework
to get the information about the processes. Both utilities use libkvm,
which is the official userland interface to access this information.
The libkvm uses the internal interface via sysctls to get this
information. So we already have precedence of the use of sysctl for
such status data.

> vmstat, systat, netstat, sockstat than listing some stats and data via 
> sysctl. Also i suspect that such complex and rich thing as sensors 

You are not supposed to list stats and data via sysctl (the kernel
level sensors framework) as an administrator. You are supposed to use
the userland tools (the single-system sensors framework tools) to query
this data. Listing the sensors in systat would be one way of accessing
this information, and people already have though about this (this
thread is triggered by Google Summer of Code 2007 work where the
sensors are already displayed in systat). If you "by accident" know how
to get the sensor information the "inofficial" way, nobody prevents you
to do it (like nobody prevents you to get the same information as
top/ps gets via sysctl), but then you are supposed to not moan if we
change the way we export this data.

> framework often would be a subject to various changes and extensions, so i 
> vote to hide kernel part as much as possible. 

This was addressed further down in the text (the part which you didn't
quote here). The official user interface to the sensors from userland
would be the userland library. As we are an open source OS, we can not
hide something, we can only declare something as an official interface,
or an internal interface. sysctl would allow to export the data in an
hierarchical and unified way. sysctl is a well tested and working
interface in FreeBSD to export data from the kernel to the userland.

If or if not there are much changes and extensions in an incompatible
way, can not be determined in such a high level architectural
discussion. To be able to talk about this, we have to got more towards
the implementation direction. But anyway, the userland access library
we envision so far is supposed to handle this gracefully.

The implicit question we answered here is, if we invent a new interface
or augment an existing and well tested interface with some meta
information in a subtree. So far it looks we want to use existing
interfaces (a sysctl subtree for the data and devctl for notifications).

What such an hierarchical and MIB like interface allows is, that you
can get the notification "event sensor X switched to a critical value"
and directly poll the value in an easy way. If, for example, you want
to produce something similar via a pseudo-filesystem, you have to
actually write a filesystem. This is a more complex task to get right
than to use the functions in the kernel to handle sysctls. It also
involves more processing in the kernel (mounting, VFS
interaction, ...). With procfs we learned that a filesystem for
something like this is hard to get right. After switching from procfs
to sysctl's to gather data for top/ps/..., we noticed that it is more
easy to get right via sysctl's, and that sysctl's are a good interface
to export such data from the kernel.

Bye,
Alexander.

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