sensors framework continued (architecture)

Alexander Leidinger Alexander at Leidinger.net
Sat Nov 10 11:33:05 PST 2007


Quoting "Poul-Henning Kamp" <phk at phk.freebsd.dk> (Sat, 10 Nov 2007 10:04:22 +0000):

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

Sorry, I included the text into my MUA after writting it in a normal
editor. It seems the wordwrap wasn't done as usual in the MUA then.

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

Two kinds of behavior come into my mind when I read this.

First behavior ("poll this sensor now"): If the userland application
wants to poll the non-event driven sensors (or sensors which are not
hardware timed), it has to issue 2 syscalls for each sensor, one to let
it poll (ioctl), and one to read the data. The polling interval is
handled by the userland.

What I like here is, that the polling interval handling is in the
userland for non-event driven and non-hardware-timed sensors (let's
call those "simple" sensors). What I don't like is that we have to issue
more than one syscall.

Why not just do one syscall (be it read for a fd based solution, or
sysctl, doesn't matter ATM) to get the data, and let the sensor decide
if he returns a cached value (for event driven or hardware timed
sensors), or does a real readout (for the simple sensors). This way you
can read at any time (imagine an admin which not only has a network wide
monitoring application, but also goes to the data center to do some
work which involves checking one of the sensors on one machine with a
local application), and get the benefit of event driven or hardware
timed sensors too. When you tell "give me a value", you want the value
now, and not when some event (e.g. the polling timer) triggers a data
transfer to the userland. How recent the value can be, depends upon the
sensor. For simple sensors it's the current value, for event driven
sensors it's also the current value, only the data from hardware timed
sensors may be not actual. If this is critical or not, depends upon the
sensor and the use of the data from this sensor. I don't know of
hardware timed sensors in normal PC hardware. I'm only aware of
external devices which monitor machines ("machines" in the sense of
"it's not a computer") which are hardware timed. I think such sensors
(at least the advanced onces) can not be completely handled by a
generic sensors framework and need some configuration interface (either
via a driver specific command line tool, or via the sysctl MIB
(dev.XXX) of this device, or whatever interface is suitable for the
device, maybe to configure it you have to use a serial line) for the
setup from a PC (if the setup is not handled on the sensor-device
itself).


Second behavior (your previous proposal to put the polling interval
into the kernel via an ioctl): The userland does a syscall for a
non-event driven and non-hardware-timed sensor to specify the polling
interval and the application waits for events (select/kevent/...) from
the sensors framework. This would mean that we need some polling code
in the kernel which starts some timers (it may be the case that the
admin has different interval requirements for different kinds of
sensors) for the non-event driven and non-hardware-timed sensors.

I don't like to have the polling code in the kernel. I would like to
have it in the userland. See my proposal above, where I talk about
reading cached values for event based sensors and doing a readout of
the sensor data for simple sensors. For sensors where it is not good to
readout the sensor data from the device too often, a cached value can
also be returned. For those types we don't really need the polling code
in the kernel. And for the "smart" sensors, you don't need the polling
code at all.

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

It obviously depends upon the amount of events which occur and how they
are processes by the programs listening to events. Typically you don't
want much events to happen.

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

Really?

I see devd as an action based daemon. He gets an event, and based upon
his config he starts some more or less complex and configurable action
(scripts) or not.

A sensorsd (which could be bsnmpd) just consumes the data from the
events (yes, an event triggers an action, namely reading the sensors
data, but this is not configurable, and not complex at all).

Both programs want to listen to events, but they don't need to
interact. Both can listen on /dev/devctl (yes, the devctl access needs
to be changed for this).

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

Currently devd could also be named eventactiond. I don't think devd
should start an action for all sensor events (transfering data to
sensorsd/snmpd). I could imagine a eventdispatcherd (if you don't want
more than one program to access /dev/devctl) which has a fanin of 1
(devctl), and a fanout of N (eventactiond, sensorsd/snmpd, ...). But
we're drifting away here, let's not continue here with this.

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

devd receives events. A sensorsd may want to get data for different
sensors in different intervals. As written above I don't like to have
the polling code in the kernel, so I still agree with Robert that a
sysctl MIB looks better for this.

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

As written, nobody came up with strong arguments (actually there where
no replies at all) to Roberts mail. Given the amount of mails in a
short timeframe to this topic before, and the large amount of time
without any reply to Roberts mail, it doesn't feel like jumping to
conclusions. If you (or someone else) have some strong arguments, but
not enough time ATM, feel free to tell us when you expect to have time
to tell us about those arguments. I'm sure Robert (and others) are
willing to listen to your arguments.

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

See my caching argument above.

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

You want to react to events fast. A sysctl doesn't not make sense for
devd. For sensor monitoring most of the use cases are polling based.
So having the generic case handled via a polling based interface makes
sense. For the parts where it isn't polling based, I wrote about
sensible ways to handle it:
 - devctl for events
 - caching of data where it makes sense (the driver and in some
   cases some configuration item knows best if caching is needed
   or not)

The normal system startup procedure (rc.d) would be responsible to
setup any smart sensor in a sensible way.

Apart from this, maybe some of such smart sensors are better handled by
the userland part of the single-system sensor framework, than by the
kernel sensor framework.

So far this approach covers all the use cases you presented here,
without the need to have some polling code in the kernel and without
the need of a more complex handling of the polling (higher amount of
syscalls for the more common polling case).

Bye,
Alexander.

-- 
No one wants war.
		-- Kirk, "Errand of Mercy", stardate 3201.7
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137


More information about the freebsd-arch mailing list