On Fri, Mar 19, 2010 at 11:16:31PM -0500, Constantine A. Murenin wrote: > On 19/03/2010, Paul Goyette <p...@whooppee.com> wrote: > > 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
This indeed makes the flag dangerous. > > 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. I agree with both of you. In the past some concerns have been raised about "mangling" the limit values in sensors that have system-wide responsibilities. If someone however decides to alter the limits in such sensors for whatever reason, this way it would be easy to restore these to the "defaults". > 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. > 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 I disagree for the reasons mentioned above. It is not a good idea to possibly alter the default system behavior (e.g. gracefully shutting down the system) with a single (unprivileged?) sensor-knob. - Jukka.
