Hello,

> > > is it fast enough to do within bus_dma_alloc( ...NOWAIT) ?  what are the
> > > latency requirements there?
> > 
> > As bus_dma_alloc(...NOWAIT) can be used from an intr handler, another
> > flag allowing this "extra effort" could be appropriate, so that device
> > driver writers can disable it on latency-critical paths?
> 
> That's a possibility, but then it still leaves the possibility that some
> necessary driver operation fails because only of what the userland happens
> to be doing at the time, and that seems undesirable.  It seems to me a
> design should consider several questions (and I don't know NetBSD kernel
> well enough to guess at the answers) ...
> 
> [... questions ...]

Don't know about these.

> o  hmm, is bus_dma_alloc() commonly called from driver routines other
>    than attach()? Is this problem one that can only arise when attach()
>    is called after the system has booted?

It can happen in other situations as well, but drivers can/should already
deal with such failure in a generic way. So attach-time failure seems to
be the problem to solve.

>                                           does that mean it can only
>    be a problem for hot-pluggable drivers like cardbus and usb?  do all
>    such drivers have kernel threads that manage them?  does that mean it's
>    possible to do blocking alloc() in all those attach functions, and
>    sidestep the latency questions?

I don't think that't the case, driver bus independent design comes to way.
Consider for example that ic/ath.c calls bus_dmamem_alloc from it's attach(),
which may be called either from cardbus/if_ath_cardbus.c (which has a kernel
thread around) or from pci/if_ath_pci.c (which doesn't have one). So you'd
have to make bus-independent driver cores "is this a hotplug"-aware.
That doesn't seem very nice, but it certainly is the simplest way...

	-- Jachym Holecek