> 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)

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.

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.

7) Given these two changes.. I think we would need to bump the envsys API
version.

---
Tim Rightnour <root@garbled.net>
NetBSD: Free multi-architecture OS http://www.netbsd.org/
Genecys: Open Source 3D MMORPG: http://www.genecys.org/