Re: [libvirt] [PATCH v5 6/6] block: Enable qemu_open/close to work with fd sets

>> @@ -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.