Re: Soliciting opinions on desired "envstat -S" behavior

["Constantine A. Murenin" <mureninc%gmail.com@localhost>]

On 19/03/2010, Paul Goyette <paul%whooppee.com@localhost> 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.