[fm-discuss] Re: Sensor design doc now available

[cindi]

Garrett D'Amore wrote:
> So we have sensors, and indicators.  What about control points?  E.g. I 
> want to be able to have a common framework for fans, etc.  (That way I 
> can have a rule that says
> 
> if (component.temp() > component.temp.warn_threshold() &&
>    component.has_fan() && component.fan.get_speed() < 
> component.fan.maxspeed()) {
>        component.fan.increase_speed();
> }
> 
> without knowing anything about the implementation of component, or fans.

We could extend the facility type to include component associations like 
fans.  In that way, we can define:

hc://chassis=0/fan=0
hc://chassis=0/chip=1/cpu=0
hc://chassis=0/chip=1/cpu=0?control=hc://chassis=0/fan=0
hc://chassis=0/chip=1/cpu=0?sensor=temperature


With libtopo, you may export these FMRIs with properties and methods, 
such that:

hc://chassis=0/fan=0
	property list:
	 fan-maxspeed=100
	 fan-get-speed() (property method)
	 fan-set-speed()

hc://chassis=0/chip=1/cpu=0
	property list:
	    get-temp()
	
hc://chassis=0/chip=1/cpu=0?sensor=temperature
	property list:
	   get-temp()
	   warn-threshold()

Of course, we could probably do the same thing with properties attached 
to the CPU temperature sensor node and not extend the FMRI namespace:

hc://chassis=0/chip=1/cpu=0?sensor=temperature
	property list:
	 get-temp()
	 warn-threshold()
	 fan=hc://chassis=0/fan=0
	 fan-maxspeed=100
	 fan-get-speed()
	 fan-set-speed()

BTW, libtopo documentation is coming very soon along with an updated 
version of the fmd programmer's reference manual.


> Also, is this framework really just for system-health related items, or 
> should there be some overlap, e.g. with lid switches on laptops? (Which 
> are just another sensor, in implementation.)

If you're asking is this a framework suitable for system events, I'd say 
no and refer you to sysevent.  If you're asking can sysevents be used in 
telemetry analysis, I'd say yes.

Cindi