sensors framework continued (architecture)

[Poul-Henning Kamp]

In message <20071109124421.3c1901b1 at deskjail>, Alexander Leidinger writes:

(sorry about the screwed up formatting, my mail-reader couldn't make
sense of the incoming formatting)

>The current state of affairs:
>
>We want a kernel sensors framework and a single-system sensors framework in
> FreeBSD.
>
>For the kernel sensors framework phk proposes (Message-ID: <81952.119278686
>4 at critter.freebsd.dk>, <82533.1192797289 at critter.freebsd.dk>) a fd which su
>pports select/poll/kevent as the interface between the kernel and the userl
>and (Julian and Max also proposed an fd based interface without going into 
>as much details regarding events like Poul did). An ioctl() could be used t
>o specify the polling intervall of sensors which are not event-driven. This
> implies that we have to move the polling intervall code for non-event driv
>en sensors from the userland to the kernel.

No it does not.

It would be prefectly sensible to have an ioctl(2) (or write(2)!)
that says "poll this sensor now" to keep control in userland if
that is desired.

Some sensors however, are hardware timed, and for those it makes
more sense to be able to tell them "we want one report every second"
and not worry more about it.

>Warner proposes to use an existing interface (devd) for event driven sensor
>s (<20071019.100516.74722974.imp at bsdimp.com>). Poul agrees that events (lik
>e "high temp" and similar, but not the actual raw data like "32=C2=B0C") co
>uld be send to devd instead. I like to extend this so that it is send over 
>the devd socket, but that devd should not react to every sensor related eve
>nt, but the signle-system sensor framework is supposed to handle such event
>s.

I'm on the fence on this one still.  I don't know what the overhead
of double-using the devd descriptor would be.  It's certainly not an
obviously good idea to mix the two functionalities too much, on the
other hand, splitting them is not an obvious good idea either.

Obviously a way to poke devd from sensord is required under all
circumstances.

(Which brings up the point that maybe devd(8) should have been called
syseventd(8) ?)

>Robert thinks that sysctl MIBs offer "a more semantically rich and, to be h
>onest, better defined way of interacting with live subsystems than device f
>iles do in a generic sense". Nobody objected to this opinion or provided re
>asons why a fd based approach is better than a sysctl MIB based approach. R
>icardo Nabinger Sanchez points out http://www.ietf.org/rfc/rfc3433.txt (RFC
> for sensor MIBs). 

Please notice that the two are not exclusive, as devd(8) so clearly
implements that.

>The single-system sensors framework should be implemented in a library whic
>h userland programs like systat, SNMP or other monitoring daemons use (jhb,
> Message-Id: <200710181450.38224.jhb at freebsd.org>). The kernel-userland int
>erface of the kernel sensors framework would be an internal interface of Fr
>eeBSD and every program which wants access to a sensor would have to use th
>e library as the official interface.

Agreed 100%.

>So to sum it up it looks like the architecture looks as follows:
> - using sysctls for centralized exporting of sensor data from kernel
>   to userland (polling interface for userland polling code)

I think you are jumping to conclusions here.

> - using devctl_notify() for change-events (the userland can then
>   read the changed value via the sysctl interface)

Agreed.

> - writting a library (the single-system sensors framework backend)
>   which abstracts away the kernel-userland interface of the kernel
>   sensors framework and provides an official interface for userland
>   programs to all sensors in the system

Agreed.

>Did I got the architecture/summary right or did I miss a mail on arch@ whic
>h made the fd based approach more beneficial than the sysctl+devctl based a
>pproach?

sysctl is by definition limited to polling, which, for any significant
number of sensors, becomes very expensive compared the ability of
an fd-based approach to queue and batch data.

I'm sure that it is no accident that Warner used the fd based approach
for devd(8).


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.