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@xxxxxxxxxxxxx
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/
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list