RE: sysctl question

[Paul Goyette <paul%whooppee.com@localhost>]

On Sat, 21 Jun 2008, Tim Rightnour wrote:

> On 19-Jun-2008 Paul Goyette wrote:
> >         2. Modify sysmon_envsys to add a new mechanism
> >
> > #2 is a whole lot more work than I'm ready to sign up for at this time!
>
> Why do you think #2 is hard? It looks like most of the mechanics are already
> there for it, it just needs a little extra parsing logic in
> sme_userset_dictionary() to deal with warnings.  I think you can probably just
> copy the code for critical-min/max and change a few lines here and there.

Hmmm, maybe.   :)

I'm definitely no expert here.  But as I read the code, the current 
user_crit_{min,max} aren't readily available at the driver level at all; 
they are processed strictly within the sysmon_event code.  The driver 
would need to scan the list of monitor events for the sensor and extract 
the associated value for each event type.  (Perhaps there's already a 
routine to do this scan?  I didn't see it, but I wasn't exactly looking 
real hard!)

> #2 is definately the correct way to do it.  If anything, it is an 
> oversight in envsys2 that it doesn't allow the userland to set those 
> values.

OK, let me take a look and see what I can come up with.  I'll probably 
have a few (dozen) more questions before I get it right.  :)

At first glance, it appears that the following needs to be done:

1. Modify sme_userset_dictionary() as you've described above.  In
   addition, I'll need to make sure that the values for user_crit_min,
   user_warn_min, user_warn_max, and user_crit_max are in increasing
   order (or at least, non-decreasing order) when the properties are
   being set.

2. Modify sme_events_worker() to make sure that we don't send a WARNOVER
   event if we're also going to send a CRITOVER event.  It doesn't
   appear that the event work queue is in any particular sequence, so
   it's not good enough to just "remember" that we've sent a CRITOVER
   event; the WARNOVER event might come first?

3. Modify the output formatting from envstat(8) to accomodate two new
   columns.

4. Update the man pages, too.  :)

And now for some initial questions:

5. (See #2 above)  Should the work queue for a device be sorted by event
   type?  Right now sme_event_register() simply uses LIST_INSERT_HEAD()
   which implies no ordering.  Is there an existing mechanism to insert
   list entries in a particular sort order?

6. The current code seems to assume that zero is an invalid value for
   the user_crit_{min,max} setting.  Is this assumption valid?  While
   I can't imagine anyone actually trying to run their system in sub-
   freezing temperatures, the sensors I'm playing with are capable of
   registering temperatures from -256 to +255 degC!

7. I've noticed that the values for PENVSYS_EVENT_* defined in
   sys/power.h have values in increments of 10.  I don't seem to find
   any rationale for this.  Would it be acceptable to insert new values
   in between existing ones, or should the whole table be renumbered?
   (Inserting might make it easier if sorting the work queue is the
   right answer to #5).

8. If I modify the envsys framework to add the user_warn_{min,max}
   stuff, would it even make sense for the sensor's driver to set the
   hardware-based thresholds?  It seems to me that if I do that, I'll
   end up sending two events for every threshold crossing.  For example
   I'd send both a CRITOVER and USER_CRITOVER event if the sensor gets
   above the crit_max setting.


----------------------------------------------------------------------
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:   |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul%whooppee.com@localhost   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette%juniper.net@localhost |
----------------------------------------------------------------------