On Wed, 2 May 2001, Jonathan Stone wrote:

> >That's not true for LKMs, so it seems to me to be harsh to say that LKMs
> >are broken since they don't use the config model which doesn't work for
> >them. :-)
> 
> We (mostly Jason) have made significant changes to the
> autoconfiguration mechanism since 4.4bsd and Chris Torek's paper.

While I don't disagree with you, I'm confused as I don't see where I was
talking about the 4.4BSD book or Torek's paper. ??

> At least for direct buses, we *should* be able to re-run `config'
> after inserting an LKM and updating the configuration tree.
> 
> In a really nice world, we could identify all the parents who had new
> children added as a result of an LKM insertion, and rerun
> autoconfiguration from those nodes only.  If all the drivers properly
> reserve their bus-space regions, that should be workable.
> (modulo latency during device probes, tests for `cold', etc).

That would be nice.

> imho thats a much cleaner approach than having two different
> autoconfiguration mechanisms, one for boot-time devices,
> and a completely different one for LKMs.

I think the point is that we don't really have an autoconfig mechanism for
LKMs right now.

> >I think the best thing would be to add the function(s) we've been talking
> >about, and to add info in the pci bus code so that we remember what we
> >find.
> 
> [...]
> 
> Static schemes like that won't help hotswap insertions, if we ever
> want to extend to that. do they work for LKMs for bus-bridge devices,
> even?

I think you snipped too much. The next paragraph was:
 
>> The memory helps a couple of ways. For an LKM, if we've found and
didn't
>> configure one of the cards the LKM is for, we can just tell the LKM
about
>> it. Also for hot-swap, if we find devices we found last time, we don't
>> need to reconfigure them.
 
See that last sentance. :-)
 
For hot-swap, when we re-scan, if we find the device we found last time,
we don't have to do anything. And since there might be hardware which
won't like getting re-configured (and I think our drivers won't
necessarily like it), leaving things as they are is best. ;-)

This should work fine as long as we are sure we rescan fast enough. I
think that "fast enough" means that removing and re-inserting a card will
always generate a detach and attach sequence - we never hit the case where
the rescan happens after the card is re-inserted and thus we don't notice
it was removed.

Oh, also for hot-swap behind a pci bridge, we need to either leave enough
unmapped space on the bus for the new card, or we need to be able to
adjust register mappings on the fly on configured cards.

For devices which present pci bridges, the two problems I can see
are: 1) we need to have left enough pci bus numbers on the pci bus to give
to the new bridge (consider a hot-swap slot that is already behind a pci
bridge) or we need to be able to re-number busses on the fly. 2) If the
bridge itself has hot-swappable pci slots behind it, we need to be able to
rescan it fast enough too.

Take care,

Bill