On 19/04/13 11:35, harryxiyou wrote:
On Thu, Apr 18, 2013 at 11:03 PM, Eric Blake <eblake@redhat.com> 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