On 01/10/2012 09:55 AM, Daniel P. Berrange wrote: > These 2 things feel like overloading the API with two different > semantics. On the one hand I see a simple XML -> struct -> XML > transformation, which is driver indepedant and does not need to > get any HV state. I call this canonicalization We still want it to be connection-dependent, though, so that the canonicalization is tied to the version of the driver the user is connected to, and not to the version of the libvirt.so client, in the case where the driver and client are at different versions. > > The other case I see XML -> struct -> munge struct info -> XML > which makes changes based on the HV state. I call this XML > enhancement. I'm not even convinced this is desirable. IMHO the way > virsh detach device is going about this task is just plain wrong. > It should be just requesting the full XML document, and then doing > an XPath query on it, to pull out the <interface> element it > needs. This removes the need to create any XML from scratch. Agreed - the new API should _not_ do any munging of user info; any munging to solve the virsh situation should be done _after_ canonicalization, in virsh, and not by a hypervisor driver API. The XML that gets output by the new API should be semantically equivalent to the XML that was input. And the idea of converting a user's subset of XML into XPath queries against the domain's XML in order to extract the full device from the domain sounds like it might work. >> * This function parses the incoming @xml, with root element >> * according to @type, and returns the same XML normalized to the >> * same form it would appear via the corresponding vir*GetXMLDesc >> * function if it had described a real libvirt object. No >> * machine state is checked or changed, so while the XML may be >> * valid, subsequent use of the XML might still fail for other >> * reasons such as an attempt to reuse a UUID. >> * > > This does look more useful, but as mentioned above, IMHO the normalization > should be purely syntactic normalization, and not rely on any semantic > state from the hypervisor drivers. I think we're in violent agreement - since "no machine state is checked or changed", the API is round-trip only, with no modification of the XML other than what happens as a result of virDomainParseDef+virDomainFormatDef (that is, canonicalizing the order of <interleave> elements, flattening integers to their canonical form, and adding in any default attributes/elements). -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list