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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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


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