[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.