Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages

NetBSD 6.1.5 - man page for sysmon_envsys_sensor_attach (netbsd section 9)

SYSMON_ENVSYS(9)		  BSD Kernel Developer's Manual 		 SYSMON_ENVSYS(9)

     sysmon_envsys -- kernel part of the envsys 2 framework

     #include <dev/sysmon/sysmonvar.h>

     struct sysmon_envsys *

     sysmon_envsys_destroy(struct sysmon_envsys *);

     sysmon_envsys_register(struct sysmon_envsys *);

     sysmon_envsys_unregister(struct sysmon_envsys *);

     sysmon_envsys_sensor_attach(struct sysmon_envsys *, envsys_data_t *);

     sysmon_envsys_sensor_detach(struct sysmon_envsys *, envsys_data_t *);

     sysmon_envsys_sensor_event(struct sysmon_envsys *, envsys_data_t *, int);

     sysmon_envsys_foreach_sensor(sysmon_envsys_callback_t, void *, bool);

     sysmon_envsys_update_limits(struct sysmon_envsys *, envsys_data_t *);

     sysmon_envsys is the kernel part of the envsys(4) framework.  With this framework you are
     able to register and unregister a sysmon_envsys device, attach or detach sensors into a
     device, and enable or disable automatic monitoring for some sensors without any user inter-
     activity, among other things.

     To register a new driver to the sysmon_envsys framework, a sysmon_envsys object must be
     allocated and initialized; the sysmon_envsys_create() function is used for this.  This
     returns a zero'ed pointer to a sysmon_envsys structure.

     Once the object has been initialized, actual sensors may be initialized and attached (see
     the SENSOR DETAILS section for more information).	This is accomplished by the
     sysmon_envsys_sensor_attach() function, which will attach the envsys_data_t (a sensor) spec-
     ified as second argument into the sysmon_envsys object specified in the first argument.

     Finally, after all sensors have been attached, the device needs to set some required (and
     optional) members of the sysmon_envsys structure before calling the sysmon_envsys_register()
     function to register the device.

     In case of errors during the initialization, the sysmon_envsys_destroy() function should be
     used.  This detachs all previously attached sensors and deallocates the sysmon_envsys

     Some sensors can be monitored, and when the sensor value changes an event can be delivered
     to the powerd(8) daemon.  Sensor monitoring can be performed by the sysmon_envsys framework
     on a polled basis.  Alternatively, the sensor's device driver can call the
     sysmon_envsys_sensor_event() function to deliver the event without waiting for the device to
     be polled.

     The sysmon_envsys_foreach_sensor() function can be used by other parts of the kernel to
     iterate over all registered sensors.  This capability is used by the i386/apm(4) driver to
     summarize the state of all battery sensors.

     Drivers can also call the sysmon_envsys_update_limits() function when it is necessary to
     reinitialize a sensor's threshhold values.  This is used by the acpibat(4) driver when a new
     battery is inserted.

     The sysmon_envsys structure is defined as follows (only the public members are shown):

     struct sysmon_envsys {
	     const char      *sme_name;
	     int	     sme_flags;
	     int	     sme_class;
	     uint64_t	     sme_events_timeout;
	     void	     *sme_cookie;
	     void (*sme_refresh)(struct sysmon_envsys *, envsys_data_t *);
	     void (*sme_set_limits)(struct sysmon_envsys *, envsys_data_t *,
				    sysmon_envsys_lim_t *, uint32_t *);
	     void (*sme_get_limits)(struct sysmon_envsys *, envsys_data_t *,
				    sysmon_envsys_lim_t *, uint32_t *);

     The members have the following meaning:

     sme_class		 This specifies the class of the sysmon envsys device.	See the DEVICE
			 CLASSES section for more information (OPTIONAL).

     sme_name		 The name that will be used in the driver (REQUIRED).

     sme_flags		 Additional flags for the sysmon_envsys device.  Currently supporting
			 SME_DISABLE_REFRESH.  If enabled, the sme_refresh function callback
			 won't be used to refresh sensor data and the driver will use its own
			 method (OPTIONAL).

     sme_events_timeout  This is used to specify the default timeout value (in seconds) that will
			 be used to check for critical events if any monitoring flag was set

     If the driver wants to refresh sensors data via the sysmon_envsys framework, the following
     members may be specified:

     sme_cookie 	 Typically a pointer to the device struct (also called ``softc'').  This
			 may be used in the sme_refresh, sme_get_limits, or sme_set_limits func-
			 tion callbacks.

     sme_refresh	 Pointer to a function that will be used to refresh sensor data in the
			 device.  This can be used to set the state and other properties of the
			 sensor depending on the data returned by the driver.  NOTE: You don't
			 have to refresh all sensors, only the sensor specified by the
			 edata->sensor index.  If this member is not specified, the device driver
			 will be totally responsible for all updates of this sensor; the
			 sysmon_envsys framework will not be able to update the sensor value.

     sme_get_limits	 Pointer to a function that will be used to obtain from the driver the
			 initial limits (or thresholds) used when monitoring a sensor's value.
			 (See the SENSOR DETAILS section for more information.)  If this member
			 is not specified, the ENVSYS_FMONLIMITS flag will be ignored, and limit
			 monitoring will not occur until appropriate limits are enabled from
			 userland via envstat(8).

     sme_set_limits	 Pointer to a function that alerts the device driver whenever monitoring
			 limits (or thresholds) are updated by the user.  Setting this function
			 allows the device driver to reprogram hardware limits (if provided by
			 the device) when the user-specificied limits are updated, and gives the
			 driver direct control over setting the sensor's state based on hardware

			 The sme_set_limits callback can be invoked with the third argument (a
			 pointer to the new limits) set to a NULL pointer.  Device drivers must
			 recognize this as a request to restore the sensor limits to their origi-
			 nal, boot-time values.

			 If the sme_set_limits member is not specified, the device driver is not
			 informed of changes to the sensor's limit values, and the sysmon_envsys
			 framework performs all limit checks in software.

     Note that it's not necessary to refresh the sensors data before the driver is registered,
     only do it if you need the data in your driver to check for a specific condition.

     The timeout value for the monitoring events on a device may be changed via the
     ENVSYS_SETDICTIONARY ioctl(2) or the envstat(8) command.

     To unregister a driver previously registered with the sysmon_envsys framework, the
     sysmon_envsys_unregister() function must be used.	If there were monitoring events regis-
     tered for the driver, they all will be destroyed before the device is unregistered and its
     sensors are detached.  Finally the sysmon_envsys object will be freed, so there's no need to
     call sysmon_envsys_destroy().

     The sme_class member of the sysmon_envsys structure is an optional flag that specifies the
     class of the sysmon envsys device.  Currently there are two classes:


	    This class is for devices that want to act as an AC adapter.  The device writer must
	    ensure that at least there is a sensor with units of ENVSYS_INDICATOR.  This will be
	    used to report its current state (on/off).


	    This class is for devices that want to act as a Battery.  The device writer must
	    ensure that at least there are two sensors with units of ENVSYS_BATTERY_CAPACITY and

	    These two sensors are used to ensure that the battery device can send a low-power
	    event to the powerd(8) daemon (if running) when all battery devices are in a critical
	    state.  (The critical state occurs when a battery is not currently charging and its
	    charge state is low or critical.)  When the low-power condition is met, an event is
	    sent to the powerd(8) daemon (if running), which will shutdown the system gracefully
	    by executing the /etc/powerd/scripts/sensor_battery script.

	    If powerd(8) is not running, the system will be powered off via the cpu_reboot(9)
	    call with the RB_POWERDOWN flag.

     NOTE: If a SME_CLASS_ACADAPTER or SME_CLASS_BATTERY class device doesn't have the sensors
     required, the low-power event will never be sent, and the graceful shutdown won't be possi-

     Each sensor uses a envsys_data_t structure, it's defined as follows (only the public members
     are shown);

     typedef struct envsys_data {
	     uint32_t	     units;
	     uint32_t	     state;
	     uint32_t	     flags;
	     uint32_t	     rpms;
	     int32_t	     rfact;
	     int32_t	     value_cur;
	     int32_t	     value_max;
	     int32_t	     value_min;
	     int32_t	     value_avg;
	     sysmon_envsys_lim_t limits;
	     int	     upropset;
	     char	     desc[ENVSYS_DESCLEN];
     } envsys_data_t;

     The members for the envsys_data_t structure have the following meaning:

     units	    Used to set the units type.

     state	    Used to set the current state.

     flags	    Used to set additional flags.  Among other uses, if one or more of the
		    ENVSYS_FMONxxx flags are set, automatic sensor monitoring will be enabled.
		    Periodically, the sensor's value will be checked and if certain conditions
		    are met, an event will be sent to the powerd(8) daemon.  NOTE that limits (or
		    thresholds) can be set at any time to enable monitoring that the sensor's
		    value remains within those limits.

     rpms	    Used to set the nominal RPM value for fan sensors.

     rfact	    Used to set the rfact value for voltage sensors.

     value_cur	    Used to set the current value.

     value_max	    Used to set the maximum value.

     value_min	    Used to set the minimum value.

     value_avg	    Used to set the average value.

     limits	    Structure used to contain the sensor's alarm thresholds.

     upropset	    Used to keep track of which sensor properties are set.

     desc	    Used to set the description string.  NOTE that the description string must be
		    unique in a device, and sensors with duplicate or empty description will
		    simply be ignored.

     Users of this framework must take care about the following points:

     o	 The desc member needs to have a valid description, unique in a device and non empty to
	 be valid.

     o	 The units type must be valid.	The following units are defined:

	 ENVSYS_STEMP		  For temperature sensors.
	 ENVSYS_SFANRPM 	  For fan sensors.
	 ENVSYS_SVOLTS_AC	  For AC Voltage.
	 ENVSYS_SVOLTS_DC	  For DC Voltage.
	 ENVSYS_SOHMS		  For Ohms.
	 ENVSYS_SWATTS		  For Watts.
	 ENVSYS_SAMPS		  For Ampere.
	 ENVSYS_SWATTHOUR	  For Watts hour.
	 ENVSYS_SAMPHOUR	  For Ampere hour.
	 ENVSYS_INDICATOR	  For sensors that only want a boolean type.
	 ENVSYS_INTEGER 	  For sensors that only want an integer type.
	 ENVSYS_DRIVE		  For drive sensors.
	 ENVSYS_BATTERY_CAPACITY  For Battery device classes.  This sensor unit uses the
				  ENVSYS_BATTERY_CAPACITY_* values in value_cur to report its
				  current capacity to userland.  Mandatory if sme_class is set to
	 ENVSYS_BATTERY_CHARGE	  For Battery device classes.  This sensor is equivalent to the
				  Indicator type, it's a boolean.  Use it to specify in what
				  state is the Battery state: true if the battery is currently
				  charging or false otherwise.	Mandatory if sme_class is set to

     o	 When initializing or refreshing the sensor, the state member should be set to a known
	 state (otherwise it will be in unknown state).  Possible values:

	 ENVSYS_SVALID	      Sets the sensor to a valid state.
	 ENVSYS_SINVALID      Sets the sensor to an invalid state.
	 ENVSYS_SCRITICAL     Sets the sensor to a critical state.
	 ENVSYS_SCRITUNDER    Sets the sensor to a critical under state.
	 ENVSYS_SCRITOVER     Sets the sensor to a critical over state.
	 ENVSYS_SWARNUNDER    Sets the sensor to a warning under state.
	 ENVSYS_SWARNOVER     Sets the sensor to a warning over state.

     o	 The flags member accepts one or more of the following flags:

	 ENVSYS_FCHANGERFACT	Marks the sensor with ability to change the rfact value on the
				fly (in voltage sensors).  The rfact member must be used in the
				correct place of the code that retrieves and converts the value
				of the sensor.

	 ENVSYS_FPERCENT	This uses the value_cur and value_max members to make a percent-
				age.  Both values must be enabled and have data.

	 ENVSYS_FVALID_MAX	Marks the value_max value as valid.

	 ENVSYS_FVALID_MIN	Marks the value_min value as valid.

	 ENVSYS_FVALID_AVG	Marks the value_avg value as valid.

	 ENVSYS_FMONCRITICAL	Enables and registers a new event to monitor a critical state.

	 ENVSYS_FMONLIMITS	Enables and registers a new event to monitor a sensor's value
				crossing limits or thresholds.

	 ENVSYS_FMONSTCHANGED	Enables and registers a new event to monitor battery capacity or
				drive state sensors.  The flag is not effective if the units mem-

	 ENVSYS_FMONNOTSUPP	Disallows setting of limits (or thresholds) via the
				ENVSYS_SETDICTIONARY ioctl(2).	This flag only disables setting
				the limits from userland.  It has no effect on monitoring flags
				set by the driver.

	 If the driver has to use any of the value_max, value_min, or value_avg members, they
	 should be marked as valid with the appropriate flag.

     o	 If units is set to ENVSYS_DRIVE, the value_cur member must be set to one of the follow-
	 ing predefined states:

	 ENVSYS_DRIVE_EMPTY	   Drive state is unknown.
	 ENVSYS_DRIVE_READY	   Drive is ready.
	 ENVSYS_DRIVE_POWERUP	   Drive is powering up.
	 ENVSYS_DRIVE_ONLINE	   Drive is online.
	 ENVSYS_DRIVE_OFFLINE	   Drive is offline.
	 ENVSYS_DRIVE_IDLE	   Drive is idle.
	 ENVSYS_DRIVE_ACTIVE	   Drive is active.
	 ENVSYS_DRIVE_BUILD	   Drive is building.
	 ENVSYS_DRIVE_REBUILD	   Drive is rebuilding.
	 ENVSYS_DRIVE_POWERDOWN    Drive is powering down.
	 ENVSYS_DRIVE_FAIL	   Drive has failed.
	 ENVSYS_DRIVE_PFAIL	   Drive has been degraded.
	 ENVSYS_DRIVE_MIGRATING    Drive is migrating.
	 ENVSYS_DRIVE_CHECK	   Drive is checking its state.

     o	 If units is set to ENVSYS_BATTERY_CAPACITY, the value_cur member must be set to one of
	 the following predefined capacity states:

	 ENVSYS_BATTERY_CAPACITY_NORMAL    Battery charge is normal.
	 ENVSYS_BATTERY_CAPACITY_CRITICAL  Battery charge is critical.
	 ENVSYS_BATTERY_CAPACITY_LOW	   Battery charge is low.
	 ENVSYS_BATTERY_CAPACITY_WARNING   Battery charge is on or below the warning capacity.

     o	 The envsys(4) framework expects to have the values converted to a unit that can be con-
	 verted to another one easily.	That means the user should convert the value returned by
	 the driver to the appropriate unit.  For example voltage sensors to mV, temperature sen-
	 sors to uK, Watts to mW, Ampere to mA, etc.

	 The following types shouldn't need any conversion: ENVSYS_BATTERY_CAPACITY,


     The following example illustrates how to enable automatic monitoring in a virtual driver for
     a critical state in the first sensor (sc_sensor[0]):

     mydriver_initialize_sensors(struct mysoftc *sc)
	     /* sensor is initialized with a valid state */
	     sc->sc_sensor[0].state = ENVSYS_SVALID;

	      * the monitor member must be true to enable
	      * automatic monitoring.
	     sc->sc_sensor[0].monitor = true;

	     /* and now we specify the type of the monitoring event */
	     sc->sc_sensor[0].flags |= ENVSYS_FMONCRITICAL;

     mydriver_refresh(struct sysmon_envsys *sme, envsys_data_t *edata)
	     struct mysoftc *sc = sme->sme_cookie;

	     /* we get current data from the driver */
	     edata->value_cur = sc->sc_getdata();

	      * if value is too high, mark the sensor in
	      * critical state.
	     if (edata->value_cur > MYDRIVER_SENSOR0_HIWAT) {
		     edata->state = ENVSYS_SCRITICAL;
		     /* a critical event will be sent now automatically */
	     } else {
		      * if value is within the limits, and we came from
		      * a critical state make sure to change sensor's state
		      * to valid.
		     edata->state = ENVSYS_SVALID;

     The envsys 2 framework is implemented within the files:





     envsys(4), envstat(8)

     The first envsys framework first appeared in NetBSD 1.5.  The envsys 2 framework first
     appeared in NetBSD 5.0.

     The (current) envsys 2 framework was implemented by Juan Romero Pardines.	Additional input
     on the design was provided by many NetBSD developers around the world.

     The first envsys framework was implemented by Jason R. Thorpe, Tim Rightnour, and Bill

BSD					  April 10, 2010				      BSD

All times are GMT -4. The time now is 01:42 PM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password