tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
RE: sysctl question
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 |
----------------------------------------------------------------------
Home |
Main Index |
Thread Index |
Old Index