Re: RFC qdev path semantics
On 06/16/2010 04:46 AM, Markus Armbruster wrote: A number of changes to qdev paths have been proposed in various threads. It's becoming harder to keep track of them, so let me sum them up in one place. Please correct me if I misrepresent your ideas. Honestly, I think we've gone off the deep end here. Let's simplify. We need to uniquely identify ram allocations for the purposes of savevm. Let's do this: qdev has a vmsd property. When the qdev device is initialized, it invokes vmstate_register_with_alias_id. Let's have vmstate_register_with_alias_id return a unique identifier. Today, it should be derived from the section header. In the future, it should be a qdev path (as should the section header). We need have a qdev-vmsd_base. pci_add_option_rom() will pass qdev-vmsd_base + a unique suffix to qemu_ram_alloc() which should be in the form '/suffix'. This suffix only need to identify the ram area uniquely for for pci_add_option_rom, it should probably be '/PCI-ROM'. Today, this means that the ram allocations will be consistent with VMState which is a good thing on the wire. In the future, when we have full qdev conversion, we can easily switch to using qdev paths as the vmsd_base with almost no code change. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC qdev path semantics
Hi, Bus names are chosen by the system as follows: * If the driver of the parent device model provides a name, use that. * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus number, counting from zero in creation order. * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM is the bus number, as above. ### Paul proposes to drop ID.NUM. ### Paul proposes to either drop TYPE.NUM (and require drivers to provide bus names), or make NUM count separately for each bus type. I agree, instance numbers are not stable. NUM in the child bus name has *nothing* to do with the savevm instance number. cheers, Gerd -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC qdev path semantics
Markus Armbruster arm...@redhat.com writes: A number of changes to qdev paths have been proposed in various threads. It's becoming harder to keep track of them, so let me sum them up in one place. Please correct me if I misrepresent your ideas. I'm going to describe the current state of things, and the proposed changes (marked with ###). The device tree has the main system bus as root. A child of a bus is a device. A child of a device is a bus. A qdev path consists of qdev path components separated by '/'. It resolves to a node in the device tree, either bus or device. The qdev path / resolves to the root, i.e. the main system bus. The qdev path IDENT, where IDENT is an identifier, resolves to the device whose id is IDENT. Err, this is not what the current code does. IDENT resolves to the *bus* whose name is IDENT. Device IDs don't come into play. Yes, bus names need not be globally unique. We use whichever bus we find first. We should really support device IDs as anchor of relative paths. As far as I can see, we don't currently support paths when we look for a device, only device IDs. But we'd like to change that. Say we extend device_del to accept a path, not just a device ID. But how to interpret an identifier argument then? Backward compatibility and common sense say it's a device ID. But it's also a relative qdev path with just one path component, a bus name. What a mess! If PATH resolves to device DEV, and a child of DEV has the name IDENT, then we resolve to that bus. then we resolve PATH/IDENT to that bus. [...] -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC qdev path semantics
I'm a little bit lost at how to implement something to print these semantics, but a couple comments below... On Wed, 2010-06-16 at 11:46 +0200, Markus Armbruster wrote: A number of changes to qdev paths have been proposed in various threads. It's becoming harder to keep track of them, so let me sum them up in one place. Please correct me if I misrepresent your ideas. I'm going to describe the current state of things, and the proposed changes (marked with ###). The device tree has the main system bus as root. A child of a bus is a device. A child of a device is a bus. A qdev path consists of qdev path components separated by '/'. It resolves to a node in the device tree, either bus or device. The qdev path / resolves to the root, i.e. the main system bus. The qdev path IDENT, where IDENT is an identifier, resolves to the device whose id is IDENT. If PATH resolves to device DEV, and a child of DEV has the name IDENT, then we resolve to that bus. Bus names are chosen by the system as follows: * If the driver of the parent device model provides a name, use that. * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus number, counting from zero in creation order. * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM is the bus number, as above. ### Paul proposes to drop ID.NUM. ### Paul proposes to either drop TYPE.NUM (and require drivers to provide bus names), or make NUM count separately for each bus type. I agree, instance numbers are not stable. Would it be reasonable to outlaw instance numbers of any kind for devices that are children of buses with BusState.allow_hotplug == 1? If PATH resolves to bus BUS, then we resolve PATH/IDENT as follows: * If a child of BUS has id IDENT, then we resolve to that device. ### Jan proposes to drop this rule. * Else, if a child of BUS has a driver with name IDENT, then we resolve to that device. If more than one exist, resolve to the first one. This assumes children are ordered. Order is the same as in info qtree. Currently, it's reverse creation order. This is *not* a stable address. * Else, if a child of BUS has a driver with alias name IDENT, then we resolve to that device. If more than one exist, resolve to the first one. This assumes children are ordered. Order is the same as in info qtree. Currently, it's reverse creation order. This is *not* a stable address. ### I propose: we resolve PATH/@BUS-ADDR to the child of BUS with bus address BUS-ADDR, if devices on this type of bus have bus addresses. The format of BUS-ADDR depends on the bus. ### Paul proposes to require all buses to define bus addresses. Make one up if necessary. That seems arbitrary and prone to breakage. How do we handle a subtle change in device instantiation order and still allow migration? If by code change or command line ordering my frobnitz moves from: /i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/0 to /i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/1 and it has a vmstate or ramblock associated with it, how do we match those up? ### Jan proposes: we resolve PATH/IDENT.NUM as follows: This isn't stable. Same as above. I don't think we can allow this on buses support hotplug. * If a child of BUS has a driver with name IDENT and an instance number NUM, then we resolve to that device. Need a suitable definition of instance number. Jan proposes to number devices with the same driver on the same bus. This assumes children are ordered, see above. This is *not* a stable address if the bus supports hot-plug. I propose to us bus-address as instance number. Works best together with Paul's proposal to define bus addresses. Syntax id...@bus-addr makes more sense then. * Else, same with driver alias name. ### Here's a possible synthesis of the above three proposals: require bus addresses, and permit any of PATH/IDENT PATH/@BUS-ADDR PATH/id...@bus-addr PATH/IDENT can't address instances that don't come first. IDENT in PATH/id...@bus-addr is redundant. Therefore, it can't be the canonical qdev path. That's fine, PATH/@BUS-ADDR serves. I can live with PATH/@BUS-ADDR if it's still felt that PATH/id...@bus-addr isn't canonical. What that means is that I'll probably code up vmstate and ramblocks to append IDENT themselves to keep all the goodness of having per PATH/IDENT namespaces. Do we want to settle on a standard end of path delineation? Should I use PATH/@BUS-ADDR$IDENT.foo ? Alex If the above rules resolve PATH to a device in a context where we expect a bus, and the device has exactly one bus, resolve it to that bus instead. ### Jan and I propose to drop this rule. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org
Re: RFC qdev path semantics
### Paul proposes to require all buses to define bus addresses. Make one up if necessary. That seems arbitrary and prone to breakage. How do we handle a subtle change in device instantiation order and still allow migration? If by code change or command line ordering my frobnitz moves from: /i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/0 to /i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/1 Two things are apparent here. (a) You've clearly misunderstood the proposals. The paths above make no sense. (b) You've picked a particularly poor definition of device address for the ISA bus. We can do much better than device creation order. ... I can live with PATH/@BUS-ADDR if it's still felt that PATH/id...@bus-addr isn't canonical. What that means is that I'll probably code up vmstate and ramblocks to append IDENT themselves to keep all the goodness of having per PATH/IDENT namespaces. As discussed elsewhere in this thread, addition of IDENT to the device path is neither necessary nor sufficient for migration. I really feel like we're going round in circles here. Paul -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC qdev path semantics
On Thu, 2010-06-17 at 23:01 +0100, Paul Brook wrote: ### Paul proposes to require all buses to define bus addresses. Make one up if necessary. That seems arbitrary and prone to breakage. How do we handle a subtle change in device instantiation order and still allow migration? If by code change or command line ordering my frobnitz moves from: /i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/0 to /i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/1 Two things are apparent here. (a) You've clearly misunderstood the proposals. The paths above make no sense. Sorry, hastily created paths. Though yes, I am a little unclear of the proposal, feel free to code up how it should work. I hope the other follow-up I just sent is more correct. (b) You've picked a particularly poor definition of device address for the ISA bus. We can do much better than device creation order. Ok, how? ... I can live with PATH/@BUS-ADDR if it's still felt that PATH/id...@bus-addr isn't canonical. What that means is that I'll probably code up vmstate and ramblocks to append IDENT themselves to keep all the goodness of having per PATH/IDENT namespaces. As discussed elsewhere in this thread, addition of IDENT to the device path is neither necessary nor sufficient for migration. I really feel like we're going round in circles here. Um, I believe I just agreed to remove IDENT from the canonical path and append it in a usage specific way. I think I've cited a couple relevant examples of how this can improve the robustness of migration and I have yet to hear anything but conjecture that this is only a false sense of security. Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC qdev path semantics (was: [Qemu-devel] [RFC PATCH 0/5] Introduce canonical device hierarchy string)
A number of changes to qdev paths have been proposed in various threads. It's becoming harder to keep track of them, so let me sum them up in one place. Please correct me if I misrepresent your ideas. I'm going to describe the current state of things, and the proposed changes (marked with ###). The device tree has the main system bus as root. A child of a bus is a device. A child of a device is a bus. A qdev path consists of qdev path components separated by '/'. It resolves to a node in the device tree, either bus or device. The qdev path / resolves to the root, i.e. the main system bus. The qdev path IDENT, where IDENT is an identifier, resolves to the device whose id is IDENT. If PATH resolves to device DEV, and a child of DEV has the name IDENT, then we resolve to that bus. Bus names are chosen by the system as follows: * If the driver of the parent device model provides a name, use that. * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus number, counting from zero in creation order. * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM is the bus number, as above. ### Paul proposes to drop ID.NUM. ### Paul proposes to either drop TYPE.NUM (and require drivers to provide bus names), or make NUM count separately for each bus type. If PATH resolves to bus BUS, then we resolve PATH/IDENT as follows: * If a child of BUS has id IDENT, then we resolve to that device. ### Jan proposes to drop this rule. * Else, if a child of BUS has a driver with name IDENT, then we resolve to that device. If more than one exist, resolve to the first one. This assumes children are ordered. Order is the same as in info qtree. Currently, it's reverse creation order. This is *not* a stable address. * Else, if a child of BUS has a driver with alias name IDENT, then we resolve to that device. If more than one exist, resolve to the first one. This assumes children are ordered. Order is the same as in info qtree. Currently, it's reverse creation order. This is *not* a stable address. ### I propose: we resolve PATH/@BUS-ADDR to the child of BUS with bus address BUS-ADDR, if devices on this type of bus have bus addresses. The format of BUS-ADDR depends on the bus. ### Paul proposes to require all buses to define bus addresses. Make one up if necessary. ### Jan proposes: we resolve PATH/IDENT.NUM as follows: * If a child of BUS has a driver with name IDENT and an instance number NUM, then we resolve to that device. Need a suitable definition of instance number. Jan proposes to number devices with the same driver on the same bus. This assumes children are ordered, see above. This is *not* a stable address if the bus supports hot-plug. I propose to us bus-address as instance number. Works best together with Paul's proposal to define bus addresses. Syntax id...@bus-addr makes more sense then. * Else, same with driver alias name. ### Here's a possible synthesis of the above three proposals: require bus addresses, and permit any of PATH/IDENT PATH/@BUS-ADDR PATH/id...@bus-addr PATH/IDENT can't address instances that don't come first. IDENT in PATH/id...@bus-addr is redundant. Therefore, it can't be the canonical qdev path. That's fine, PATH/@BUS-ADDR serves. If the above rules resolve PATH to a device in a context where we expect a bus, and the device has exactly one bus, resolve it to that bus instead. ### Jan and I propose to drop this rule. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC qdev path semantics (was: [Qemu-devel] [RFC PATCH 0/5] Introduce canonical device hierarchy string)
* Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM is the bus number, as above. ### Paul proposes to either drop TYPE.NUM (and require drivers to provide bus names), or make NUM count separately for each bus type. I revised this proposal: Drop the .NUM part, and require drivers provide a bus name if TYPE would result in ambiguous names. Paul -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC qdev path semantics
Markus Armbruster wrote: A number of changes to qdev paths have been proposed in various threads. It's becoming harder to keep track of them, so let me sum them up in one place. Please correct me if I misrepresent your ideas. I'm going to describe the current state of things, and the proposed changes (marked with ###). The device tree has the main system bus as root. A child of a bus is a device. A child of a device is a bus. A qdev path consists of qdev path components separated by '/'. It resolves to a node in the device tree, either bus or device. The qdev path / resolves to the root, i.e. the main system bus. Another aspect: A path may start with an arbitrary bus name, not only the system bus. Although this is ambiguous, we need to keep it for addressing the bus itself due to existing client use. But, IMO, we should at least start deprecating this for addressing elements below that bus (e.g. pci.0/e1000). And besides specifying devices via absolute qdev paths, we also support addressing them via their ID if present. I checked if ID/BUS[/...] was supported so far, but it wasn't. So I did not propose this yet although it might be a useful abbreviation. The qdev path IDENT, where IDENT is an identifier, resolves to the device whose id is IDENT. If PATH resolves to device DEV, and a child of DEV has the name IDENT, then we resolve to that bus. Bus names are chosen by the system as follows: * If the driver of the parent device model provides a name, use that. * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus number, counting from zero in creation order. * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM is the bus number, as above. ### Paul proposes to drop ID.NUM. ### Paul proposes to either drop TYPE.NUM (and require drivers to provide bus names), or make NUM count separately for each bus type. If PATH resolves to bus BUS, then we resolve PATH/IDENT as follows: * If a child of BUS has id IDENT, then we resolve to that device. ### Jan proposes to drop this rule. * Else, if a child of BUS has a driver with name IDENT, then we resolve to that device. If more than one exist, resolve to the first one. This assumes children are ordered. Order is the same as in info qtree. Currently, it's reverse creation order. This is *not* a stable address. * Else, if a child of BUS has a driver with alias name IDENT, then we resolve to that device. If more than one exist, resolve to the first one. This assumes children are ordered. Order is the same as in info qtree. Currently, it's reverse creation order. This is *not* a stable address. ### I propose: we resolve PATH/@BUS-ADDR to the child of BUS with bus address BUS-ADDR, if devices on this type of bus have bus addresses. The format of BUS-ADDR depends on the bus. ### Paul proposes to require all buses to define bus addresses. Make one up if necessary. ### Jan proposes: we resolve PATH/IDENT.NUM as follows: * If a child of BUS has a driver with name IDENT and an instance number NUM, then we resolve to that device. Need a suitable definition of instance number. Jan proposes to number devices with the same driver on the same bus. This assumes children are ordered, see above. This is *not* a stable address if the bus supports hot-plug. I propose to us bus-address as instance number. Works best together with Paul's proposal to define bus addresses. Syntax id...@bus-addr makes more sense then. I would be fine with this scheme, but I assume we still need instance numbers as fallback for buses without any usable addressing. Example: I have a patch queued that uses this for internal addressing of all hpet devices on the system bus (to connect them to the ISA IRQs). * Else, same with driver alias name. ### Here's a possible synthesis of the above three proposals: require bus addresses, and permit any of PATH/IDENT PATH/@BUS-ADDR PATH/id...@bus-addr PATH/IDENT can't address instances that don't come first. PATH/IDENT[.INSTANCE] would resolve the addressability. IDENT in PATH/id...@bus-addr is redundant. Therefore, it can't be the canonical qdev path. That's fine, PATH/@BUS-ADDR serves. If the above rules resolve PATH to a device in a context where we expect a bus, and the device has exactly one bus, resolve it to that bus instead. ### Jan and I propose to drop this rule. Thanks for this summary! Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC qdev path semantics
Markus Armbruster wrote: A number of changes to qdev paths have been proposed in various threads. It's becoming harder to keep track of them, so let me sum them up in one place. Please correct me if I misrepresent your ideas. I'm going to describe the current state of things, and the proposed changes (marked with ###). The device tree has the main system bus as root. A child of a bus is a device. A child of a device is a bus. A qdev path consists of qdev path components separated by '/'. It resolves to a node in the device tree, either bus or device. The qdev path / resolves to the root, i.e. the main system bus. Another aspect: A path may start with an arbitrary bus name, not only the system bus. Although this is ambiguous, we need to keep it for addressing the bus itself due to existing client use. But, IMO, we should at least start deprecating this for addressing elements below that bus (e.g. pci.0/e1000). I think this would be better served by adding explicit aliases/IDs for those use-cases. i.e. define the global ID pci.0 to be an alias for /i440FX-pcihost/pci Paul -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC qdev path semantics
Paul Brook wrote: Markus Armbruster wrote: A number of changes to qdev paths have been proposed in various threads. It's becoming harder to keep track of them, so let me sum them up in one place. Please correct me if I misrepresent your ideas. I'm going to describe the current state of things, and the proposed changes (marked with ###). The device tree has the main system bus as root. A child of a bus is a device. A child of a device is a bus. A qdev path consists of qdev path components separated by '/'. It resolves to a node in the device tree, either bus or device. The qdev path / resolves to the root, i.e. the main system bus. Another aspect: A path may start with an arbitrary bus name, not only the system bus. Although this is ambiguous, we need to keep it for addressing the bus itself due to existing client use. But, IMO, we should at least start deprecating this for addressing elements below that bus (e.g. pci.0/e1000). I think this would be better served by adding explicit aliases/IDs for those use-cases. i.e. define the global ID pci.0 to be an alias for /i440FX-pcihost/pci Makes sense. We could attach this ID to the BusState (corresponding to DeviceState:id) and manually set it during machine init. qbus_find_recursive would then look for a matching ID instead of a name. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: RFC qdev path semantics
I think this would be better served by adding explicit aliases/IDs for those use-cases. i.e. define the global ID pci.0 to be an alias for /i440FX-pcihost/pci Makes sense. We could attach this ID to the BusState (corresponding to DeviceState:id) and manually set it during machine init. qbus_find_recursive would then look for a matching ID instead of a name. If we accept your proposal that global ids are not accepted as local device identifiers, then these probably shouldn't be stored in the device tree at all. Allowing at most one global ID per node also seems like a rather arbitrary limitation. How about having a global alias table that maps an ID to a devtree path? The code to handle these becomes a straight string substitution followed by a normal path lookup. We don't need separate code for device v.s. bus, and global_device_id/busname just works. Paul -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC qdev path semantics
Markus Armbruster arm...@redhat.com writes: [...] Bus names are chosen by the system as follows: * If the driver of the parent device model provides a name, use that. * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus number, counting from zero in creation order. * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM is the bus number, as above. ### Paul proposes to drop ID.NUM. ABI change: -device lsi,id=my-scsi -device scsi-disk,bus=my-scsi.0 no longer works. ### Paul proposes to either drop TYPE.NUM (and require drivers to provide bus names), or make NUM count separately for each bus type. Likewise. I'm not saying we can't do this, just that we need to consider backward compatibility. [...] -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC qdev path semantics
Bus names are chosen by the system as follows: * If the driver of the parent device model provides a name, use that. * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus number, counting from zero in creation order. * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM is the bus number, as above. ### Paul proposes to drop ID.NUM. ABI change: -device lsi,id=my-scsi -device scsi-disk,bus=my-scsi.0 no longer works. IMO this is a fundamentally broken ABI, so I don't care. ### Paul proposes to either drop TYPE.NUM (and require drivers to provide bus names), or make NUM count separately for each bus type. Likewise. I'd be surprised if anyone actually uses absolute device paths at this time, and they're probably going to be broken by other changes. Using these default bus names as global identifiers is fixable using aliases (e.g. -device lsi,bus=pci.0). I'd expect this to cover most interesting uses. See http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg02149.html Paul -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: RFC qdev path semantics
Paul Brook wrote: I think this would be better served by adding explicit aliases/IDs for those use-cases. i.e. define the global ID pci.0 to be an alias for /i440FX-pcihost/pci Makes sense. We could attach this ID to the BusState (corresponding to DeviceState:id) and manually set it during machine init. qbus_find_recursive would then look for a matching ID instead of a name. If we accept your proposal that global ids are not accepted as local device identifiers, then these probably shouldn't be stored in the device tree at all. Allowing at most one global ID per node also seems like a rather arbitrary limitation. How about having a global alias table that maps an ID to a devtree path? The code to handle these becomes a straight string substitution followed by a normal path lookup. We don't need separate code for device v.s. bus, and global_device_id/busname just works. No principle concerns about such a table. It should nevertheless be reference-based to assist lifetime management of aliases that are created together with the devices they point to. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: RFC qdev path semantics
Paul Brook p...@codesourcery.com writes: Bus names are chosen by the system as follows: * If the driver of the parent device model provides a name, use that. * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus number, counting from zero in creation order. * Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM is the bus number, as above. ### Paul proposes to drop ID.NUM. ABI change: -device lsi,id=my-scsi -device scsi-disk,bus=my-scsi.0 no longer works. IMO this is a fundamentally broken ABI, so I don't care. Users of this ABI won't appreciate that attitude. I do support dropping ID.NUM, but we owe our users due ABI diligence. ### Paul proposes to either drop TYPE.NUM (and require drivers to provide bus names), or make NUM count separately for each bus type. Likewise. I'd be surprised if anyone actually uses absolute device paths at this time, and they're probably going to be broken by other changes. Yes. Using these default bus names as global identifiers is fixable using aliases (e.g. -device lsi,bus=pci.0). I'd expect this to cover most interesting uses. See http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg02149.html Keeping the old bus names work for the buses we create automatically shouldn't be hard. Only a few, and no ID.NUM there. It's the user-created buses that worry me. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
