Subject: envsys(4), envstat(8) and detachable sensors.
To: None <tech-kern@NetBSD.org>
From: Jeff Rizzo <riz@tastylime.net>
List: tech-kern
Date: 04/15/2006 13:42:21
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig04BAAB7092035C3B383FDEED
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I wanted to check in here before going too far down any particular road
with this, in hopes of soliciting opinions of people more familiar with
the internals of the envsys stuff.

I've been working with onewire(4) devices a bit (primarily temperature
sensors, but I'll be working with other stuff soon, if I can get this
problem squared away), and they are able to attach and detach cleanly
from a device perspective.  Adding a new sensor works well;  I can
attach (say) another owtemp(4) device after boot, and successfully read
it with envstat(8).  However, if I detach a sensor, no sensors "after"
that one can be found.

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

At the very least, the code in envstat(8) doesn't handle this - the
first sensor number that doesn't have ENVSYS_FVALID set causes the
counting code to stop - so if sensor 0 is removed, no more sensors.  My
question here is, is there some bit of the API I've missed which allows
the kernel to return how many sensors there are, and/or what sensor
numbers userland should request?   If not, does adding such an ioctl
seem like the best approach to this problem?    I've only just begun to
think about the issues, and would appreciate input from anyone else
who's been thinking about it as well...

Thanks,
+j



--------------enig04BAAB7092035C3B383FDEED
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBREFasrOuUtxCgar5AQN22AQAnOprD919BzObQHow7Av/cW7gHhrByWPA
U841nifC5d0AhfdjHF27E1IAy8ENMeGX/6Js9R1akLznGkkkb1JatwP4eFtn3O8g
DhnClaOSv2pTD1Pc9l6LsssGT5mn6t7xiD4a7F4Y4G1EFpVFR9Qc/Qj/TKapvoE9
Tm7nw7W0YUw=
=XNOb
-----END PGP SIGNATURE-----

--------------enig04BAAB7092035C3B383FDEED--