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: Kevin Wolf
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

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 via email to

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