Keir Fraser wrote:
On 21/2/08 11:00, "Yosuke Iwamatsu" <y-iwamatsu@xxxxxxxxxxxxx> wrote:
- Interface changes
New xenbus states "Reconfiguring" and "Reconfigured" are introduced.
Not sure about this. If this is just to flag changes to individual devices,
could pcifront watch individual device nodes? Or at least I think a separate
configuration xenstore node would be sensible, with its own state-machine
enumeration. I'm reluctant to mess with the main state node as we currently
have something that works!
PCI device attach/detach may result in changing several nodes such as
"num_devs", "root-#" and "root_num". So I thought switching the main
state might be suitable here.
If you are unwilling to change the main state node,
watching individual device nodes may be a possible solution.
In that case, we prepare pci slots for hotplug and make pciback/pcifront
watch all the states of these slots. But I wonder if it is acceptable
that pv drivers watch lots of xenstore nodes.
I'm not sure about the idea to have a separate configuration node
per device. Does that mean having pv drivers for each pci device?
- Xenstore changes
Substates(state-#) and virtual pci slots(vdev-#) entries are added
for pciback driver. For example, when PCI devices 00:1d.0 and 00:1d.1
are connected, xenstore-ls will show information like this.
Why vdev-#? Aren't the dev-# names already the virtual names (mapped to
physical slots transparently by pciback)?
dev-# names are the physical names.
vdev-# becomes the same as dev-# when compiled with PCIDEV_BACKEND_PASS,
but different when compiled with other options (VPCI, SLOT).
vdev-# names are necessary for pcifront to recognize which devices are
to be detached.
Thanks,
Yosuke
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
| 
Home