On 11-Nov-99 Bill Squier wrote:
>> Any chance we can select() on the device node and read from it instead of
>> having to (blegh) poll it with ioctl's?
> 
> This has come up, and I'm not opposed to it.  With a no-frills API like
> ENVSYS 
> 1.0, it seems easy to accomplish with a union type over envsys_*_data with a 
> type field for polymorphism.  One downside is that a change to the data 
> structures which mandates an increase in the size of the union would require
> a 
> re-compile of userland apps.

Two things:

1) select on the device node wouldn't really be feasable, as it would require
the device to poll internally, which we are attempting to avoid with this API. 
(why spend CPU looking up the temp if nobody cares?)  A read and seek pair
would probably suffice, with userland polling.

2) My problem with the read API is that it locks us in to the current structure
union, like Bill says.  What I'm afraid of.. is that some newfangled chip will
come out, that measures somehting that won't fit into our API provided
structures.  The driver author can either rev the API, and break lots of stuff,
so his chip works.. or he can take the easy way out and make an ioctl on the
side..

If we just do the ioctl from the start..  then when said chip appears..  the
driver author just adds a new structure type, doesn't affect anything that
allready works, and spits out envsys v 1.1.

---
Tim Rightnour <root@garbled.net>
NetBSD: Free multi-architecture OS http://www.netbsd.org/
NetBSD Mailing lists on the web: http://mail-index.netbsd.org/