Re: Soliciting opinions on desired envstat -S behavior
On Sun, 21 Mar 2010, Jukka Ruohonen wrote: This part certainly gets complicated, and a C3 variation may sound like the right thing to do. I think it would be best if the drivers could reset the limits internally with an appropriate reset command issued directly to the underlying hardware as opposed to the bookkeeping of the values in the software (otherwise, what would happen after a soft reboot?), but I'm unaware regarding whether or not such hardware support is usually present. Additionally, the limit values can be in read-only registers, etc. If the registers are read-only, the driver should not provide a xxx_set_limits() callback. Furthermore, it should either prevent the user from changing the limits values (with the FMONNOTSUPP flag) or leave value/limit checking to the software framework. In either case, if the registers are read-only, the driver falls into category A or B. - | 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 | -
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 | -
Re: Soliciting opinions on desired envstat -S behavior
On 19/03/2010, Paul Goyette p...@whooppee.com wrote: 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. Indeed it is. 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. I disagree that the current behaviour works as documented, since it doesn't restore the defaults as per the driver (and it is documented to restore the setting that the drivers use by default). Therefore, I absolutely agree with your re-import proposal. 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. This part certainly gets complicated, and a C3 variation may sound like the right thing to do. I think it would be best if the drivers could reset the limits internally with an appropriate reset command issued directly to the underlying hardware as opposed to the bookkeeping of the values in the software (otherwise, what would happen after a soft reboot?), but I'm unaware regarding whether or not such hardware support is usually present. ... I think a new option should be used for the removal of all the hardware-set limits (both internally from sysmon_envsys(9) and from the underlying hardware if the hardware-based monitoring is applicable), which should be separate from -S. Perhaps it could even conveniently be called -H? The -S option is already documented to specifically remove [only] the properties that were set in the configuration file, and I think it should be left alone for the currently documented task only. br, cnst.su.
