On Wed, 2 May 2001, Jonathan Stone wrote:

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

You seem to be focusing on points which I think we have left vague. We
aren't going to totally ignore the config system we have now. Yes, we'll
have to add to it, but we won't ignore it.

And all of the routines we're talking about would be needed anyway. For
instance, to see which parents gained matchable children due to an LKM
getting added, we'll still need to be able to find existing instances of
the to-be-matched device. So the routine(s) which started this thread
would still be needed.

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

Pretty much, but if we have more specific info about what devices are
where, then I don't see why we shouldn't use it.

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

I am suggesting we add a new structure which essentially would be the pci
match arguements. Keeping track of which devices are "new" and "old" is
easy - if when we look, the match arguements are what we remember, it is
"old".

We do not need to keep track of (all) of the config-space registers. Just
the match arguements.

And since there are at most 32 devices on a bus and at most 8 functions
within a device, we're only talking 256 slots of storage. And since we
only have 64-bits (8 bytes) of data per function (16 bits vendor, 16 bits
device, 24 bits of class code, and 8 bits of revision), we are only
talking about 2k of storage to add per PCI bus.

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

Not necessarily. My thought is that we can record PCI info even for pci
devices we don't configure. So this means we have, "no such device",
"already configured", and "found but not 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?

It's similar to what we do now.

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

Those actually would be easier than pci-pci bridges, I think. The pci
spec(s) impose rules on how the whole of all pci busses is
configured. Like busses have to be numbered and configured just so. When
you have a bridge to some other bus type, you don't have that problem. A
pci-vme bridge might have other troubles, but not these. ;-)

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

My concern is that pci match routines don't allocate anything. The BIOS
will have done that for us. All the match routines do is look at the info
I list above. So each time we scan a slot, we will match it. It's not like
on an indirect bus (ISA) where we use allocations to see if we can proceed
or not. When we go to map the resources, we have to write to the register
(you write all ones, and then read what you get) to determine how big a
space you need to allocate. I'm not sure what the device will do while
this happens. Say it is in the middle of some I/O transaction with
whatever it interfaces with (receiving or sending a packet, etc.) and
"doesn't like" having the registers twiddled... While I don't _know_ that
that will happen, I see no reason to take chances. :-)

Take care,

Bill