Re: [Xen-devel] [PATCH] linux: allow pciback to be built as a module

[Ryan <hap9@xxxxxxxxxxxxxx>]

On Wed, 2006-03-08 at 16:30 +0000, Keir Fraser wrote:
> On 8 Mar 2006, at 16:05, Ryan wrote:
> 
> > The reason that I did not code this as a module in the first place was
> > because the pcistub driver needs to be loaded before other device
> > drivers so that it gets first pick at seizing devices from the kernel.
> > That's why I use fs_initcall in the pcistub driver instead of
> > device_initcall or module_init, it gets called earlier in the kernel
> > boot process. As a module, you can't do that. If other PCI device
> > drivers (whether modules or not) are loaded before the pciback module,
> > they'll have a higher priority (because they're earlier in the linked
> > list of drivers) for grabbing devices. This functionality (using
> > fs_initcall) is somewhat of a "hack" (because I don't know of a cleaner
> > way to ensure that the pcistub driver gets probed for ALL pci devices).
> 
> Installing pciback early is definitely the best way to go, but it would 
> be nice to support later loading as a module despite the limitations 
> that imposes. I was minded to take Jan's patch, my main concern being 
> that using the pci_* functions instead of pcibios_* functions may have 
> adverse side effects (Jan uses them only because they are the ones 
> exported to modules).

> One way around that possible problem would be to define pciback_* 
> functions that call pcibios_* functions as in the current driver when 
> compiled into the kernel image, or call the pci_* functions when 
> compiled as a module. How does that sound?
> 

I don't think there's any problems with using the pci_* functions
instead, but I haven't tried it. Except for pci_enable_device (which
could be replaced by pci_enable_device_bars to avoid potential
side-effects in pci_fixup_device), I think in the worst case scenario,
you read a pci configuration space register twice (once in the frontend
and again in the backend) instead of once.

> 
> Another nice thing to support in pciback would be late binding to a PCI 
> device, if it hasn't already been bound to by some other driver. This 
> would avoid needing to specify hiding devices as a boot parameter if 
> the administrator knows that no driver will try to bind to that device.
> 

Do you mean if no other driver grabs a device, have that device attach
to the pcistub driver?

I have a type of "late binding" support coded up and working, but it
isn't quite ready for submission yet. You can add/remove PCI slots
to/from the pcistub driver at run-time. It doesn't automatically pick-up
devices that don't have a driver, but it is useful for working with the
bind/unbind driver attributes in sysfs in Linux. This would also be
useful in scenarios with cardbus where you *may* not know the slot
numbers in advance. Or if the administrator simply decides to change his
mind and take, for example, a network card out of service in dom0 and
put it in a domU or vice versa.

Ryan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel