On Mon, Jan 09, 2012 at 10:29:08PM +0800, Osier Yang wrote: > The initial purpose was to fix a regression for detaching device, > (introduced by commit ea7182c29). There was a patch posted to > resolve the problem: > > https://www.redhat.com/archives/libvir-list/2011-December/msg00818.html > > But as Eric suggested, it's not the ideal way to go, we never known > how many stuffs like <address> will be involved in future. So new API > to invoke the internal parsing functions might be a right way then. > > However, things are not that simple (an API without internal driver > support, invoking the parsing functions directly). As the domain conf > is a neccessary argument to parse the device XML. (e.g. for an Input > device). Although we can bypass that by modification on > virDomainDeviceDefParse, it could be trap as we will parse the device > XML in another way which is different with the real parsing. So finally > I choosed to implement the driver support for the new API. There might > be something I didn't take into consideration, (e.g. Do we need some > flags for the XML parsing and formating?). But it can demo the thought > good enough. > > On the other hand, I'm wondering if it's deserved to introduce such > an API, comparing it's usage, is it two heavy if we need the internal > drivers support for such an API? > > Any thoughts and feedback is welcomed.
I don't really understand what the use case is for this API, from the description above. Can you give an example of how, for example, virt-manager would use this API todo something ? Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
