On Thu, 3 May 2001, Matthias Drochner wrote:

> wrstuden@zembu.com said:
> > I don't think we were talking about two contradicting configuration
> > frameworks.
> 
> Well, having devices look for the best matching driver or having drivers
> look for devices which could be handled are quite differing approaches
> to the "find bast match between x and y" problem.
> "contradicting" might be a harsh word, but it's not exactly the same
> philosophy either...

I'll agree with that.

> > 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).
> 
> Since it is part of my job to deal with homegrown and experimental hardware,
> I've been thinking about loadable device drivers for quite some time.
> What I had running in 1.3 times (actually, I'm still running 1.3 on a number
> of systems for that reason) was to have a (linked) list of configuration
> tables as generated by config(8), each consisting of the cfdata[] and cfroots[]
> arrays which are global and singular originally. LKMs could append their
> own lists, and the autoconfiguration functions considered the entries of all
> present lists instead of just the primary one. I had even a hacked version of
> config(8) for that purpose, so I could set up a config file snippet with
> all the attachment specifications and locators and options, and the resulting
> LKM did behave that way. (It was about VME devices partly, and for VME
> the locators are essential - worse than ISA...) There is a number of issues
> which are not so easy to solve, especially the connection points between
> these configuration tables, and some reference counting problems. I didn't
> have time do deal with all of this; what I did was just enough to work in
> an environment where the operator knows what he is doing.
> What I want to say: I know it is doable.

Wow! You got lkms working on an indirect bus??? Cool!

While pci lkms might (ab)use the scan routine we were talking about, I
think if we had a framework as clean as the one you describe, they would
use it instead.

> > Is architectural purity worth pciide drivers not working?
> 
> As I wrote in another mail, there is at least one other way: the bus/device/
> function numbers of the ISA bridge are probably well-known in this case because
> the IDE interface in within the same chipset. One could perhaps also
> use some parent-child-links within the "struct device", or even use
> a special pciide attachment to this special pcib device.
> I don't by any "there is no other way" argument, and even then there is
> no need to create a new pseudo-generic public interface.

I think one problem we'll have here is that the pci code wants to attach a
different driver to each pci function of the device. So the pcib and
pciide each expect to be handed disjoint things.

What might work is for us to have an MI viapcib attach to the pci bus, and
have the (MD) pcib attach to it. All the viapcib would do is note what
revision it is in a place which the via-specific pciide code could find.

Oh, and as for the pciide getting probed before the pcib/viapcib, what we
could do is have the via pciide code look to see if the version is
know. If it is, it acts accordingly. If it is not, it sets reasonable
defaults and flags that we need to go check what the hardware can do. Then
later we figure out what revision we have and set the interface up
accordingly.

Later could either be a device open (which I'm not sure pciide drivers
get), or later could be when the viapcib code attaches.

Thoughts?

Take care,

Bill