qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd


From: Corey Bryant
Subject: Re: [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd
Date: Mon, 09 Jul 2012 14:02:07 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1



On 07/09/2012 01:48 PM, Luiz Capitulino wrote:
On Mon, 09 Jul 2012 13:35:19 -0400
Corey Bryant <address@hidden> wrote:



On 07/09/2012 11:46 AM, Kevin Wolf wrote:
Am 09.07.2012 17:05, schrieb Corey Bryant:
I'm not sure this is an issue with current design.  I know things have
changed a bit as the email threads evolved, so I'll paste the current
design that I am working from.  Please let me know if you still see any
issues.

FD passing:
-----------
New monitor commands enable adding/removing an fd to/from a set.  New
monitor command query-fdsets enables querying of current monitor fdsets.
    The set of fds should all refer to the same file, with each fd having
different access flags (ie. O_RDWR, O_RDONLY).  qemu_open can then dup
the fd that has the matching access mode flags.

Design points:
--------------
1. add-fd
-> fd is passed via SCM rights and qemu adds fd to first unused fdset
(e.g. /dev/fdset/1)
-> add-fd monitor function initializes the monitor inuse flag for the
fdset to true
-> add-fd monitor function initializes the remove flag for the fd to false
-> add-fd returns fdset number and received fd number (e.g fd=3) to caller

2. drive_add file=/dev/fdset/1
-> qemu_open uses the first fd in fdset1 that has access flags matching
the qemu_open action flags and has remove flag set to false
-> qemu_open increments refcount for the fdset
-> Need to make sure that if a command like 'device-add' fails that
refcount is not incremented

3. add-fd fdset=1
-> fd is passed via SCM rights
-> add-fd monitor function adds the received fd to the specified fdset
(or fails if fdset doesn't exist)
-> add-fd monitor function initializes the remove flag for the fd to false
-> add-fd returns fdset number and received fd number (e.g fd=4) to caller

4. block-commit
-> qemu_open performs "reopen" by using the first fd from the fdset that
has access flags matching the qemu_open action flags and has remove flag
set to false
-> qemu_open increments refcount for the fdset
-> Need to make sure that if a command like 'block-commit' fails that
refcount is not incremented

5. remove-fd fdset=1 fd=4
-> remove-fd monitor function fails if fdset doesn't exist
-> remove-fd monitor function turns on remove flag for fd=4

What was again the reason why we keep removed fds in the fdset at all?

Because if refcount is > 0 for the fd set, then the fd could be in use
by a block device.  So we keep it around until refcount is decremented
to zero, at which point it is safe to close.

But then the refcount is associated with the set, not with any particular fd.


Exactly, yes that's what we're doing. Sorry, I thought that was clear in the design overview I sent earlier today.

--
Regards,
Corey





reply via email to

[Prev in Thread] Current Thread [Next in Thread]