On Thu, 3 May 2001, Matthias Drochner wrote:

> wrstuden@zembu.com said:
> > The thing is that our current autoconfiguration philosophy implicitly
> > assumes that we scan the bus once
> 
> One _can_ scan the bus later again if the bus support code provides a hook
> for this. scsi has this, and for pci it would be easy to add.
> There should be some ressource management which keeps track of child
> devices so that a driver working on a device is not stomped on.
> 
> > 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. :-) 
> 
> Why not? The LKM init code can have some pci_rescan() or so code scan
> the bus(es), which would work more or less like the initial autoconfiguration
> and call the xxxmatch() finction(s) of the driver(s) within the LKM.
> This needs some thoughts and work, but is much better than having two
> contradicting configuration frameworks within one system.

I don't think we were talking about two contradicting configuration
frameworks. Yes, many details were left vague, but I don't think we were
going to come up w/ two totally independent frameworks...

> > 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.
> 
> The least thing I'd like to have is some control which physical devices the
> LKM driver should care about, in case there is more than one present.
> Just like the initial autoconfiguration provides through its config(8)
> generated locators.

The problem here is that we'd need to also extend the config system to be
able to inject more locators once booted (and also be able to delete
them). My thoughts had been to let the lkm code implicitly add a
driverfoo* at pci ? device ? function ? ..

> As I said, I'm afraid if we start to provide such a pci_scan function,
> it will be used, and that would be catastrophic from the architectural
> cleanlyness POV imho.

Is architectural purity worth pciide drivers not working?

From my understanding of Manuel's comments, there are pciide chips out
there where the vendor didn't bump the version of the pciide component
when changing it. The only way to correctly deal with these chips is to
look at the version of another pci device, and act accordingly.

So what do we do?

Take care,

Bill