In message <Pine.NEB.4.21.0105021144520.343-100000@candlekeep.home-net.internet
connect.net>Bill Studenmund writes:
>On Wed, 2 May 2001, Jonathan Stone wrote:

>
>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. ??

Sure. my point was that we have added enough machinery that
*re-running* config from a particular node should be almost viable, at
least for direct busses.


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

Right. so, do we invent a new one out of whole cloth; or do we adapt
the one we have so that it can handle LKMs?

[hotswap]
>See that last sentance. :-)

It didnt make sense to me (which is probalby my fault, not yours).
Take the PCI bus we have today. Devices are configured by scanning
PCI config space. Each device that's found gets handed to the
match routine of all attach-at-pci devices, to see if they recognize
its PCI locators.

That scan is _supposed_ to be idempotent.

Isn't that pretty much what we want for an LKM?


>For hot-swap, when we re-scan, if we find the device we found

What does "found" mean? Sounds like you're assuming we add some new
structure, a copy of the PCI config-space registers, and machinery to
keep track of which devices are "found" and which are "new".

that's the moral equivalent to using extents to mark the PCI
configuration-space for "already configured" devices as having been
"already configured".

apart from pci-pci-bridges, that sounds like it's pretty much a
duplicate of what we already have to scan PCI config-space. Or is that
too abstract?

for bridges: I was acutallly thinking of heterogenous bridges:
say, turbochannel-VMe or something equally horrible.


>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. ;-)

Devices would still only get onfigured once. If a driver is already
configured, then a (well-written) driver has already mapped and
reserved (via bus-specific extent maps) the bus-space resources for
that device. The match routine won't be able to touch the device-space
registers.  The only time a device woudl get "re-configured" is if its
(LKM) driver is unloaded and then reloaded. Which sounds like the
right behaviour to me.

Is the concern here about possible side-effects of scanning through
PCI config-space, or about something else?