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
|
Home