qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 6/6] block: Enable qemu_open/close to work wi


From: Corey Bryant
Subject: Re: [Qemu-devel] [PATCH v5 6/6] block: Enable qemu_open/close to work with fd sets
Date: Mon, 06 Aug 2012 09:32:37 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1



On 08/06/2012 05:15 AM, Kevin Wolf wrote:
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?)

I'd prefer to have them associated with a monitor object so that we can more easily keep track of whether or not they're in use by a monitor connection.


2. Save a monitor reference with the fdset information.


Are you saying that each monitor would have the same copy of 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.

What if we also allow them to be added only to the default monitor?

--
Regards,
Corey





reply via email to

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