Jason Thorpe wrote:

> On Fri, 14 Jan 2000 13:20:18 +0100
>  Lennart Augustsson <lennart@augustsson.net> wrote:
>
>  > Again, I can't believe my eyes!  There is code in there that may loop for up to 500ms
>  > using delay().  I.e. the kernel will busy wait for 0.5s.  And looking a little further the I
>  > see that it can loop for 0.1s during reset.  I've not checked, but the only reason for
>  > using delay() rather than tsleep() is that these routines are called from an interrupt
>  > context, which in my opinion makes using delay() even more unforgivable since it may
>  > block important interrupts.
>  > Clearly, the MII code needs a little restructuring to get rid of these atrocities.
>  >
>
> Look a little more carefully... when it's called from ANY context other than
> via ioctl, it's all asynchronous; no busy-wait.

OK, so if it only busy waits from ioctl, which I assume occur from process context,
why not use tsleep() instead of delay?  It's not like a few extra ms of waiting matters
here.


> I'm doing some work on the MII code currently, to make it even MORE asynch,
> but between moving to a new house and vacation, I haven't gotten it finished
> yet.

As I indicated in an earlier mail, I'd like all method calls (downcalls, or whatever
you want to call them) to occur from a process context.  Otherwise I cannot make
the USB adapters work.  Unless we accept long delay()s.

Bill Paul has written three Ethernet-USB drivers.  They cover all know USB-Ethernet
adapters, and I'm working on getting them into NetBSD.  But I refuse to commit the
hacks he used to make it work; they involve using delay().


--

        -- Lennart