| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home