tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Soliciting opinions on desired "envstat -S" behavior
Currently, the -S option for envstat(8) is documented to
...restore defaults to all devices registered with the framework.
This will remove all properties that were set in the configuration
file to the setting that the drivers use by default.
This was written this way long ago, before sysmon_envsys(9) learned how
to import/export limit setting with hardware drivers.
As a result, the current behavior is sub-optimal, as it removes _ALL_
sensor limits, regardless of whether those limits were learned from the
hardware driver or provided by the configuration file. Even worse, the
limits are removed from within the sysmon_envsys framework, but the
hardware driver is not notified of the removal; thus the hardware may
still be checking the limits, and with the recent introduction of
non-polled event delivery, the driver could actually report a limits
event for a sensor with no limits!
I'm soliciting opinions on what the correct behavior should be, for each
of the following sensor categories:
A. Sensors that have no hardware knowledge of limit values, and rely
only on the sysmon_envsys(9) framework.
I believe that the current behavior is correct - all knowledge of
limit values is discarded.
B. Sensors that can provide initial limit values, but which cannnot
handle changes to those values in hardware. All limit processing is
actually handled in the sysmon_envsys(9) framework and not in the
driver or hardware.
The current behavior works, but I believe that we should really
"re-import" the initial values from the driver/hardware. This is
closest to the documented behavior.
C. Sensors that can actually process limit checking in the hardware (or
in the driver) and that can accept new limit values to replace any
initial (or factory default) values.
I see at least three options here.
C1. In addition to current behavior (removing all limits from
the sysmon_envsys(9) framework), we should update the
driver/hardware to let it remove its own limits.
or C2. Behave as proposed in (B) above, and simply reimport the
current values from the hardware/driver after clearing
the framework.
or C3. Remember the initial values from when the sensor was first
registered, and after clearing the framework, reset both
the hardware/driver and the framework to the remembered
values.
I'd really appreciate comments/feedback/suggestions/etc.
-------------------------------------------------------------------------
| Paul Goyette | PGP DSS Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-------------------------------------------------------------------------
Home |
Main Index |
Thread Index |
Old Index