# Garrett D'Amore 2006-07-04:
> Jachym Holecek wrote:
> > # matthew green 2006-07-03:
> >   
> >>    
> >>    	/* Allocate recursion context of max depth 16, topdown dir. */
> >>    	di = device_iterator_alloc(16, DIF_WAITOK | DIF_TOPDOWN);
> >>
> >>
> >>
> >> why have this '16' limit at all?  i don't see why it's necessary
> >> or even a good idea.
> >>     
> >
> > The idea was to avoid any allocation in device_iterator_foreach(),
> > so that it could be used from interrupt context if needed (ie.
> > in config_{de,}activate()) -- we probably want to avoid allocations
> > within hardintrs.
> >
> > [... options ...]
> 
> I'm of the considered opinion that we should use M_WAITOK, and not
> support this iteration in interrupt context.  The only case I can think
> of for interrupt context device tree traversal is hot detach (removal of
> a PCMCIA card, for example, or removal of a USB node.)

This would make things simpler, so I'm not against it (see below).

> From what I can tell, those busses that support "hot detach" (without
> user interaction) do so without necessarily requiring a clean detach
> notification in the driver.  Indeed, in the case of PCMCIA some
> controllers don't even bother to issue an interrupt on removal, but the
> OS has to poll for it.  And  on other hardware, the interrupt for the
> PCMCIA detach doesn't necessarily block the interrupts triggered by the
> device hardware.
> 
> I am unaware of any buses besides pcmcia and USB/firewire which are
> designed to support hot detach without advance notification to the
> driver.  Indeed, even Cardbus doesn't support this properly -- a detach
> notification is required from userland _before_ physical removal in
> order to guarantee safe operation.

If we can agree to require user intervention before removing hotplug
devices (which is what Windows XP does, not sure about other systems),
then we "should" get rid of ca_activate (as we know it now, anyway).
There was a short thread on this recently, the argument for keeping
them was exactly "we need a quick deactivation from hardintr when
we get a device-gone interrupt".

I don't have enough experience with various hotplug architectures
to have a strong opinion on this.

	-- Jachym