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

On 07/25/2012 03:43 PM, Eric Blake wrote: > On 07/23/2012 07:08 AM, Corey Bryant wrote: >> When qemu_open is passed a filename of the "/dev/fdset/nnn" >> format (where nnn is the fdset ID), an fd with matching access >> mode flags will be searched for within the specified monitor >> fd set. If the fd is found, a dup of the fd will be returned >> from qemu_open. >> >> Each fd set has a reference count. The purpose of the reference >> count is to determine if an fd set contains file descriptors that >> have open dup() references that have not yet been closed. It is >> incremented on qemu_open and decremented on qemu_close. It is >> not until the refcount is zero that file desriptors in an fd set >> can be closed. If an fd set has dup() references open, then we >> must keep the other fds in the fd set open in case a reopen >> of the file occurs that requires an fd with a different access >> mode. >> > >> +++ b/monitor.c >> @@ -2551,6 +2551,91 @@ static void monitor_fdsets_set_in_use(Monitor >> *mon, bool in_use) >> } >> } >> >> +void monitor_fdset_increment_refcount(Monitor *mon, int64_t fdset_id) >> +{ >> + mon_fdset_t *mon_fdset; >> + >> + if (!mon) { >> + return; >> + } > > Am I reading this code right by stating that 'if there is no monitor, we > don't increment the refcount'? How does a monitor reattach affect > things? Or am I missing something fundamental about the cases when > 'mon==NULL' will exist? > Yes you're reading this correctly. I'm pretty sure that mon will only be NULL if QEMU is started without a monitor. If QEMU has a monitor, and libvirt disconnects it's connection to the qemu monitor, then I believe mon will remain non-NULL.