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: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd
Date: Mon, 09 Jul 2012 17:46:00 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

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?

The removed flag would make sense for a fdset after a hypothetical
close-fdset call because the fdset needs to be kept around until the
last user closes it, but I think removed fds can be deleted immediately.

I think I might have confused remove-fd and close-fdset in earlier
emails in this thread, so I hope this isn't inconsistent with what I
said before.

> 6. qemu_close (need to replace all close calls in block layer with 
> qemu_close)
> -> qemu_close decrements refcount for fdset
> -> qemu_close closes all fds that have (refcount == 0 && (!inuse || remove))
> -> qemu_close frees the fdset if no fds remain in it
> 
> 7. disconnecting the QMP monitor
> -> monitor disconnect visits all fdsets on monitor and turns off monitor 
> in-use flag for fdset

And close all fds with refcount == 0.

> 8. connecting the QMP monitor
> -> monitor connect visits all fdsets on monitor and turns on monitor 
> in-use flag for fdset
> 
> 9. query-fdsets
> -> returns all fdsets and fds that don't have remove flag on

Kevin



reply via email to

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