[libvirt] [Qemu-devel] [PATCH v7 6/6] block: Enable qemu_open/close to work with fd sets

[Stefan Hajnoczi]

On Wed, Aug 8, 2012 at 2:54 PM, Corey Bryant <coreyb at linux.vnet.ibm.com> wrote:
>
>
> On 08/08/2012 09:02 AM, Stefan Hajnoczi wrote:
>>
>> On Tue, Aug 07, 2012 at 11:58:28AM -0400, Corey Bryant wrote:
>>>
>>> @@ -2566,6 +2567,92 @@ FdsetInfoList *qmp_query_fdsets(Error **errp)
>>>       return fdset_list;
>>>   }
>>>
>>> +int monitor_fdset_get_fd(int64_t fdset_id, int flags)
>>> +{
>>> +    mon_fdset_t *mon_fdset;
>>> +    mon_fdset_fd_t *mon_fdset_fd;
>>> +    int mon_fd_flags;
>>> +
>>> +    QLIST_FOREACH(mon_fdset, &mon_fdsets, next) {
>>> +        if (mon_fdset->id != fdset_id) {
>>> +            continue;
>>> +        }
>>> +        QLIST_FOREACH(mon_fdset_fd, &mon_fdset->fds, next) {
>>> +            if (mon_fdset_fd->removed) {
>>> +                continue;
>>> +            }
>>
>>
>> This makes me wonder about immediately closing in remove-fd and drop the
>> removed field.  This way, code using mon_fdset->fds does not need to
>> worry about removed=true fds.
>>
>>
>
> The reason we don't immediately close in remove-fd is so that the client
> doesn't have to keep track of what fd's are in use by QEMU.
>
> Let's say libvirt uses add-fd to add fd=4 (O_RDONLY) and fd=5 (O_RDWR) to fd
> set 2 and they both refer to /mnt/nfs/data.img.  libvirt can then issue a
> command that uses the fd (e.g. drive_add file=/dev/fdsets/2). QEMU then
> opens and closes that file as it desires by dup'ing the fd in the fd set
> that has matching access mode (O_RDONLY or O_RDWR) and closing the dup'd fd.
>
> By not closing the fd immediately in remove-fd, we allow the client to issue
> a command like drive_open and immediately follow it with a remove-fd and not
> have to worry about determining when QEMU is done using the fd.

I see.  So as long as the fd set's refcount > 0 the fd will not get closed.

Stefan