On 06/20/2012 10:53 AM, Eric Blake wrote:
On 06/20/2012 07:31 AM, Corey Bryant wrote:
It sounds like the flow would be:
'pass-fd drive-virtio1' of O_RDONLY fd --> guest gets fd 21
No -f, so qemu errors out if an fd named 'drive-virtio1' already exists;
otherwise it succeeds, and returns the fd assigned by SCM_RIGHTS as well
as adding the name to its internal list.
'pass-fd -f drive-virtio1' of O_WRONLY fd --> guest gets fd 21?
-f says to fail if 'drive-virtio1' does not already exist in the
internal list. Otherwise, this is a reopen attempt, and the fd passed
in by SCM_RIGHTS (let's assume it is 23 at this time) is then passed
through dup2() to overwrite the fd already associated with
'drive-virtio1' (21 in this case), then the SCM_RIGHTS fd (23) is
closed. In this way, the name 'drive-virtio1' remains associated with
fd 21, but we have reopened it with different mode. At this point, code
that wants to reopen /dev/fd/21 with a new mode will see the new
permissions on the reassigned fd. And yes, it means that libvirt would
not be allowed to call 'closefd drive-virtio1' until the block device
for drive-virtio1 is no longer around, whether or not the /dev/fd/nn
reuses the fd as-is or whether it dup()s the fd to something else (say
22) for use by the block device.
That makes sense. Thanks for the explanation.
Essentially dup2(23, 21) will give fd 21 the new access mode. I assume
we can go ahead and close fd 23 after the dup2?
I'll go ahead and add this support in the next version of the patch
series if there are no objections.
--
Regards,
Corey
But I'm not clear as to how you would retain file descriptor 21 in the
guest when using 'pass-fd -f drive-virtio1'. The fd is created as a
result of passing via SCM_RIGHTS, which assigns the next available fd.
We don't have control over what fd is assigned, do we?
The use of -f says that 'pass-fd' uses dup2() to reuse an existing fd.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list