Subject: Re: envsys(4), envstat(8) and detachable sensors.
To: Tim Rightnour <firstname.lastname@example.org>
From: Jeff Rizzo <email@example.com>
Date: 05/05/2006 16:09:24
Mmm, slow-motion API discussions. My comments inline, below.
Tim Rightnour wrote:
>> I looked into this, and it looks to me like what envstat(8) does is to
>> look sequentially for sensors beginning with 0, and incrementing until
>> it finds the first sensor number that returns "invalid". This is
>> somewhat problematic, because what sysmon_envsys_unregister() does is to
>> simply remove the detached sensor from the list (sysmon_envsys_list),
>> and leave the abandoned sensor number unused. (New sensors get
>> ever-increasing numbers).
> Ok.. I've been thinking about this problem.. and here is what I propose:
> 1) We add a new ioctl.. maybe ENVSYS_GMAXSENS which would return an int
> containing the maximum number of sensors in the machine currently.
> 2) When a driver registers a new sensor, it should bump this number which would
> be a global in the kernel. (most of the time, see below)
OK, so this would effectively be a "high water mark"? IE, the maximum
number that have ever been in the machine, but not necessarily the
number in there now? I think this could work OK.
> 3) When we add a new sensor, we would walk the list of current sensors, and
> look for the first one that is not marked as being valid. If we hit one before
> we hit the max sensors value, we use that one and don't increment. If we hit
> the end, then we bump.
> 4) Removing a sensor would consist of just marking it invalid.
> 5) envstat should ask for the max sensors number from the kernel, and just skip
> the invalid ones, that way it could handle a sparse list of sensors.
This all makes sense.
> 6) We extend struct envsys_basic_info to include an ID for each sensor. Some
> sensors may not have this, but things like your one-wire which have a unique
> serial number, would fill this in at attach time. This could be used by
> envstat to find a particular sensor. For example, if I put a one-wire in a
> fish tank, I could write a script that would look for that sensor's serial
> number and monitor it, even as it moved position in the sensors array over
> different boots.
So, don't do anything in particular with this information in the kernel,
but allow userland to access it via envsys_basic_info? I like this -
keeps the kernel changes to a minimum.
> 7) Given these two changes.. I think we would need to bump the envsys API
I like the thinking you've done about this; unless someone else wants
to chime in, I'll take a stab at implementing your suggestions when I
get a chance, and send diffs to the list. (unless you'd like to do it;
the changes seem straightforward, but I'm unlikely to have time to get
to it real soon - I'm interested in this, but it's not real high on my
personal priority list right now)