Hello, Am Donnerstag 10 März 2011 09:54:52 schrieb Daniel Veillard: > Okay, overall I would tend to ACK that patch based purely on the code, > but I would like to get first a small discussion about somehow merging > it in the xen:/// framework. Once commited it will be hard to change > and impossible after a release, so we need to decide there before > pushing it IMHO. > Option might be if the default xen driver isn't registered, or > make both exclusive, or a temporary user environment, but I will have > a slight feeling of failure if we can't get to hide properly the > underneath change, I think it would be great to follow a model similar to ext4dev: It was included early into the Linux kernel but was clearly marked as experimental: Those brave soles wanting to test new stuff and help with the development could enable it, but you were warned to not use it in production environments and to make regular backups. Later on when it was more stable, it got renamed to just ext4. This would help to get the xen-light driver more tested, and get it updated when internal libvirt-API are changed, but still be able to change the implementation details if it needs to be. Application developers using libvirt.xenlight to connect to Xen servers should expect, that they might have to update their code for newer libvirt version, because it is not yet fully stable. Sincerely Philipp Hahn -- Philipp Hahn Open Source Software Engineer hahn univention de Univention GmbH Linux for Your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/
Description: This is a digitally signed message part.