Re: [Xen-devel] [PATCH] PCI Backend - Late Binding

[Ryan <hap9@xxxxxxxxxxxxxx>]

On Thu, 2006-03-23 at 10:00 +0000, Keir Fraser wrote:
> On 23 Mar 2006, at 00:32, Ryan wrote:
> 
> > # Add a new slot to the PCI Backend's list
> > echo -n 0000:01:04.d > /sys/bus/pci/drivers/pciback/new_slot
> > # Now that the backend is watching for the slot, bind to it
> > echo -n 0000:01:04.d > /sys/bus/pci/drivers/pciback/bind
> 
> Thanks for the patches, which I've now applied. But why the two-stage 
> process to bind to a PCI device? Does writing to 'bind' get swallowed 
> by sysfs and not make it to pciback unless you've already registered 
> interest with sysfs?

The bind attribute calls the probe handler on the device driver with the
specified device. Unfortunately, there's no way for me (at least, not
that I'm aware of) to detect in my probe routine if the user is wanting
to forcibly bind the device to the backend or if it's a normal probe
from a device insertion or driver registration. This same problem exists
for existing drivers (see http://lwn.net/Articles/143397/ ) where the
driver must want to bind to the device. The driver core people expected
this and added an attribute whereby a user can tell a driver to be
interested in other device ids through the new_id driver attribute (PCI
class, vendor, device, etc.). But since the PCI backend registers that
it is interested in *every* device (so that it can check the slot number
instead of any kind of device ID), I had to add those new attributes
(new_slot/remove_slot) which serve the same purpose as new_id but are
specific to the needs of the PCI backend. It would probably be possible
to have a call to new_slot do the binding as well (like call
pci_find_device or something similar and then driver_attach), but I
figured since the sysfs infrastructure already did it for me, I wouldn't
duplicate that code. In addition, you may wish to add/remove slots for
devices which aren't inserted in the system yet (they would get
automatically bound when they are inserted through the normal probing
that occurs).

I'm open to suggestions for a better way, but I thought this achieved
the desired functionality while closely matching the kernel's usual
interface (my new_slot/remove_slot matches the purpose of the new_id
sysfs attribute).

Ryan


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