On 19/04/13 11:35, harryxiyou wrote:
On Thu, Apr 18, 2013 at 11:03 PM, Eric Blake <eblake@xxxxxxxxxx> wrote:
[...]
Exactly - we need to add a new libvirt API that can support renames at
the backend driver level, with instant effect (a directory pool
forwarding to rename(2), other pools using pool-specific renaming commands).
It might be worth still having virsh vol-rename have an option to do a
long-running copy/delete in the case of a backend that doesn't support
instant renames, but the default should be instant rename or failure.
Okay, i will give my V2 patch-set for these stuffs. My [1]CheckList for
*Rename* jobs have described my schedule for them one by one.
I also offer the [2]design plan for these stuffs.
[1] http://code.google.com/p/gsocxy/wiki/CheckList
[2] http://code.google.com/p/gsocxy/wiki/GeneralDesignForRenameAPIs
Eric, very thanks for your comments ;-)
There is no new things in the wiki.
Before writing the code, I'd suggest going through the HACKING
and the document for how to implement a new API for libvirt [1],
it's a bit out of date though, but still useful. And you can pick up
the patches which introduced new API as example. I think with
the document and the existing patches for new API, you will known
how/what to do next.
After that, if you are still not confident about your approach, send
RFC to list, instead of putting in your wiki. On one hand, it's not
convenient, I believe not everyone likes an external link. On the
other hand, it's not good for tracking the history, even you can
guarantee it won't be deleted/changed forever. Including draft
patches in RFC is not required, but having it is always better.
You might be not picked up finally for the project, but it's the generic
knowledge worth to learn if you are interested in contributing to libvirt.
[1] http://libvirt.org/api_extension.html
Osier
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list