[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 0/4] block: file descriptor passing using -f
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [RFC PATCH 0/4] block: file descriptor passing using -filefd and getfd_file |
Date: |
Tue, 22 May 2012 17:24:52 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 |
Am 22.05.2012 17:01, schrieb Eric Blake:
> On 05/22/2012 08:45 AM, Kevin Wolf wrote:
>
>>> I understand that open("/dev/fd/42") would be the same as dup(42), but
>>> I'm not sure that I'm entirely clear on how this would work. Could you
>>> give an example?
>>
>> With your approach you open the file outside qemu, pass the fd to qemu
>> along with a file name that it's supposed to replace and then you use
>> that fake file name:
>>
>> (qemu) getfd_file abc
>> (qemu) drive_add 0 file=abc,...
>>
>> Instead you could use the existing getfd command and avoid the translation:
>>
>> (qemu) getfd
>> 42
>> (qemu) drive_add 0 file=/dev/fd/42,...
>>
>> Er, well. Just that getfd doesn't return the assigned fd today, so the
>> management tool doesn't know it. We would have to add that.
>
> That actually sounds workable. As long as management knows _what_ fd
> qemu recieved (that is, 'getfd' is enhanced to tell libvirt the
> associated fd number), and as long as qemu makes the magic naming of
> /dev/fd/ work everywhere (even if it isn't normally part of the host
> OS), then libvirt could indeed reuse existing file mechanisms to open a
> file using an fd that it knows qemu should already own, without needing
> to invent a new 'getfd_file' monitor command.
Which OSes are you thinking of? I'm not sure if we need to support FD
passing on all OSes in all places where you can pass a file name.
The specific use case we have in mind is for bypassing a SELinux
limitation, so that would be useful only for Linux anyway.
> I guess in this instance,
> libvirt would have to unconditionally use 'closefd' after the command
> that reused the fd, since using file=/dev/fd/42 dups the fd rather than
> consuming it (this is different from commands that use fd:nnn to consume
> an fd).
I actually liked the fd: protocol approach, but Anthony doesn't seem to
want it any more. But yes, I think if we use /dev/fd/42 you need to
closefd unconditionally.
Kevin
- Re: [Qemu-devel] [RFC PATCH 2/4] qmp/hmp: Add getfd_file monitor command, (continued)
- Re: [Qemu-devel] [RFC PATCH 0/4] block: file descriptor passing using -filefd and getfd_file, Kevin Wolf, 2012/05/22
- Re: [Qemu-devel] [RFC PATCH 0/4] block: file descriptor passing using -filefd and getfd_file, Eric Blake, 2012/05/22
- Re: [Qemu-devel] [RFC PATCH 0/4] block: file descriptor passing using -filefd and getfd_file, Corey Bryant, 2012/05/22
- Re: [Qemu-devel] [RFC PATCH 0/4] block: file descriptor passing using -filefd and getfd_file, Corey Bryant, 2012/05/22
- Re: [Qemu-devel] [RFC PATCH 0/4] block: file descriptor passing using -filefd and getfd_file, Kevin Wolf, 2012/05/22
- Re: [Qemu-devel] [RFC PATCH 0/4] block: file descriptor passing using -filefd and getfd_file, Corey Bryant, 2012/05/22
- Re: [Qemu-devel] [RFC PATCH 0/4] block: file descriptor passing using -filefd and getfd_file, Eric Blake, 2012/05/22
- Re: [Qemu-devel] [RFC PATCH 0/4] block: file descriptor passing using -filefd and getfd_file, Corey Bryant, 2012/05/22