Subject: Re: More braindead code
To: Jason Thorpe <firstname.lastname@example.org>
From: Lennart Augustsson <email@example.com>
Date: 01/15/2000 03:01:32
Jason Thorpe wrote:
> On Fri, 14 Jan 2000 13:20:18 +0100
> Lennart Augustsson <firstname.lastname@example.org> 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
> 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
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().