In message <44009889.5030803@tastylime.net>, Jeff Rizzo writes:

>
>(I debated whether this was more appropriate for current-users or
>tech-kern, and decided more potential _users_ would be reached on
>current-users.  If more discussion of details is warranted, it should
>probably be had on tech-kern)
>
>I'm currently working on a driver for one-wire devices (such as the
>DS18B20 temperature sensor) which attaches to gpio(4), and I'm wondering
>if anyone else would find this useful - my intended usage is to hook up
>a bunch of these devices to a soekris 4511 to monitor various stuff
>around the house.
>
>It's not clear to me whether this would be something appropriate to
>bring in to NetBSD or not - these devices are not commonly built into
>motherboards, and the usual usage is with microcontrollers (PIC, AVR,
>etc) - the bus protocol is such that the driver I've written has
>DELAY()s of up to 450ms, and I don't see a way to get rid of them and
>still retain the correct timing for bitbanging the protocol.  That said,
>the chips are fairly inexpensive (the DS18b20 is about US$5 in quantity
>1, the DS1822 less than US$4), and are easy to connect up for any
>moderately competent hobbyist.
>
>So, on to the questions.
>
>1)  Are people interested in having this available in NetBSD? Is it
>appropriate?
>
>2)  Should I do the work to integrate the temperature sensor parts into
>the ensys(4) API?  Right now, most of the actual work is done in
>userland, with the exception of the bus-scanning code to see what
>devices are connected.  If people aren't interested in general (or think
>it's a bad idea), I'll probably just leave things this way, because I
>don't have particularly complex needs right now.
>
>3) Does anyone have any further suggestions?  The code is currently
>"working", though I don't do much with it yet.  If people are
>interested, I can clean it up and post it for testing.  (It definitely
>needs work before I'm letting _anyone_ see it)
>

It strikes me as a useful thing to support.

As for your DELAY()s -- would a sleep in a high priority kernel process 
do the trick?

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb