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
> version.
>   

I agree.

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)

+j