|
From: | Corey Bryant |
Subject: | Re: [Qemu-devel] [PATCH v7 6/6] block: Enable qemu_open/close to work with fd sets |
Date: | Wed, 08 Aug 2012 09:54:20 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 |
On 08/08/2012 09:02 AM, Stefan Hajnoczi wrote:
On Tue, Aug 07, 2012 at 11:58:28AM -0400, Corey Bryant wrote:@@ -2566,6 +2567,92 @@ FdsetInfoList *qmp_query_fdsets(Error **errp) return fdset_list; } +int monitor_fdset_get_fd(int64_t fdset_id, int flags) +{ + mon_fdset_t *mon_fdset; + mon_fdset_fd_t *mon_fdset_fd; + int mon_fd_flags; + + QLIST_FOREACH(mon_fdset, &mon_fdsets, next) { + if (mon_fdset->id != fdset_id) { + continue; + } + QLIST_FOREACH(mon_fdset_fd, &mon_fdset->fds, next) { + if (mon_fdset_fd->removed) { + continue; + }This makes me wonder about immediately closing in remove-fd and drop the removed field. This way, code using mon_fdset->fds does not need to worry about removed=true fds.
The reason we don't immediately close in remove-fd is so that the client doesn't have to keep track of what fd's are in use by QEMU.
Let's say libvirt uses add-fd to add fd=4 (O_RDONLY) and fd=5 (O_RDWR) to fd set 2 and they both refer to /mnt/nfs/data.img. libvirt can then issue a command that uses the fd (e.g. drive_add file=/dev/fdsets/2). QEMU then opens and closes that file as it desires by dup'ing the fd in the fd set that has matching access mode (O_RDONLY or O_RDWR) and closing the dup'd fd.
By not closing the fd immediately in remove-fd, we allow the client to issue a command like drive_open and immediately follow it with a remove-fd and not have to worry about determining when QEMU is done using the fd.
-- Regards, Corey
[Prev in Thread] | Current Thread | [Next in Thread] |