Subject: Re: 1.6.2 kernel: ex driver sometimes can't allocate
To: Chapman Flack <email@example.com>
From: Jachym Holecek <firstname.lastname@example.org>
Date: 09/22/2004 00:54:23
> > > 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