All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Corey Bryant <coreyb@linux.vnet.ibm.com>
Cc: aliguori@us.ibm.com, stefanha@linux.vnet.ibm.com,
	libvir-list@redhat.com, qemu-devel@nongnu.org,
	Luiz Capitulino <lcapitulino@redhat.com>,
	eblake@redhat.com
Subject: Re: [Qemu-devel] [PATCH v5 6/6] block: Enable qemu_open/close to work with fd sets
Date: Mon, 06 Aug 2012 11:15:19 +0200	[thread overview]
Message-ID: <501F8B27.2070508@redhat.com> (raw)
In-Reply-To: <501AFD68.8010009@linux.vnet.ibm.com>

Am 03.08.2012 00:21, schrieb Corey Bryant:
>>> @@ -84,6 +158,36 @@ int qemu_open(const char *name, int flags, ...)
>>>       int ret;
>>>       int mode = 0;
>>>
>>> +#ifndef _WIN32
>>> +    const char *fdset_id_str;
>>> +
>>> +    /* Attempt dup of fd from fd set */
>>> +    if (strstart(name, "/dev/fdset/", &fdset_id_str)) {
>>> +        int64_t fdset_id;
>>> +        int fd, dupfd;
>>> +
>>> +        fdset_id = qemu_parse_fdset(fdset_id_str);
>>> +        if (fdset_id == -1) {
>>> +            errno = EINVAL;
>>> +            return -1;
>>> +        }
>>> +
>>> +        fd = monitor_fdset_get_fd(default_mon, fdset_id, flags);
>>
>> I know that use of default_mon in this patch is not correct, but I
>> wanted to get these patches out for review. I used default_mon for
>> testing because cur_mon wasn't pointing to the monitor I'd added fd sets
>> to.  I need to figure out why.
>>
> 
> Does it make sense to use default_mon here?  After digging into this 
> some more, I'm thinking it makes sense, and I'll explain why.
> 
> It looks like cur_mon can't be used.  cur_mon will point to the monitor 
> object for the duration of a command, and be reset to old_mon (NULL in 
> my case) after the command completes.
> 
> qemu_open() and qemu_close() are frequently called long after a monitor 
> command has come and gone, so cur_mon won't work.  For example, 
> drive_add will cause qemu_open() to be called, but after the command has 
> completed, the file will keep getting opened/closed during normal QEMU 
> operation.  I'm not sure why, I've just noticed this behavior.
> 
> Does anyone have any thoughts on this?  It would require fd sets to be 
> added to the default monitor only.

I think we have two design options that would make sense:

1. Make the file descriptors global instead of per-monitor. Is there a
   reason why each monitor has its own set of fds? (Also I'm wondering
   if they survive a monitor disconnect this way?)

2. Save a monitor reference with the fdset information.

Allowing to send file descriptors on every monitor, but making only
those of the default monitor actually usable, sounds like a bad choice
to me.

Kevin

  reply	other threads:[~2012-08-06  9:15 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-23 13:07 [Qemu-devel] [PATCH v5 0/6] file descriptor passing using fd sets Corey Bryant
2012-07-23 13:08 ` [Qemu-devel] [PATCH v5 1/6] qemu-char: Add MSG_CMSG_CLOEXEC flag to recvmsg Corey Bryant
2012-07-23 22:50   ` Eric Blake
2012-07-24  2:19     ` Corey Bryant
2012-07-23 13:08 ` [Qemu-devel] [PATCH v5 2/6] qapi: Introduce add-fd, remove-fd, query-fdsets Corey Bryant
2012-07-25 18:16   ` Eric Blake
2012-07-26  2:55     ` Corey Bryant
2012-07-23 13:08 ` [Qemu-devel] [PATCH v5 3/6] monitor: Clean up fd sets on monitor disconnect Corey Bryant
2012-07-23 13:08 ` [Qemu-devel] [PATCH v5 4/6] block: Convert open calls to qemu_open Corey Bryant
2012-07-25 19:22   ` Eric Blake
2012-07-26  3:11     ` Corey Bryant
2012-07-23 13:08 ` [Qemu-devel] [PATCH v5 5/6] block: Convert close calls to qemu_close Corey Bryant
2012-07-23 13:08 ` [Qemu-devel] [PATCH v5 6/6] block: Enable qemu_open/close to work with fd sets Corey Bryant
2012-07-23 13:14   ` Corey Bryant
2012-08-02 22:21     ` Corey Bryant
2012-08-06  9:15       ` Kevin Wolf [this message]
2012-08-06 13:32         ` Corey Bryant
2012-08-06 13:51           ` Kevin Wolf
2012-08-06 14:15             ` Corey Bryant
2012-08-07 16:43               ` Corey Bryant
2012-07-24 12:07   ` Kevin Wolf
2012-07-25  3:41     ` Corey Bryant
2012-07-25  8:22       ` Kevin Wolf
2012-07-25 19:25         ` Eric Blake
2012-07-26  3:21           ` Corey Bryant
2012-07-26 13:13             ` Eric Blake
2012-07-26 13:16               ` Kevin Wolf
2012-07-27  4:07                 ` Corey Bryant
2012-07-25 19:43   ` Eric Blake
2012-07-26  3:57     ` Corey Bryant
2012-07-26  9:07       ` Kevin Wolf
2012-07-27  3:59         ` Corey Bryant
2012-07-27  4:03         ` Corey Bryant
2012-08-02 15:08       ` Corey Bryant
2012-07-24 12:09 ` [Qemu-devel] [PATCH v5 0/6] file descriptor passing using " Kevin Wolf
2012-07-25  3:42   ` Corey Bryant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=501F8B27.2070508@redhat.com \
    --to=kwolf@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=coreyb@linux.vnet.ibm.com \
    --cc=eblake@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.