All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Bryant <coreyb@linux.vnet.ibm.com>
To: Eric Blake <eblake@redhat.com>
Cc: kwolf@redhat.com, libvir-list@redhat.com, aliguori@us.ibm.com,
	stefanha@linux.vnet.ibm.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH 2/4] qmp/hmp: Add getfd_file monitor command
Date: Tue, 22 May 2012 09:37:26 -0400	[thread overview]
Message-ID: <4FBB9696.3010404@linux.vnet.ibm.com> (raw)
In-Reply-To: <4FBAB81F.7080408@redhat.com>



On 05/21/2012 05:48 PM, Eric Blake wrote:
> On 05/21/2012 02:19 PM, Corey Bryant wrote:
>> This patch provides support for the getfd_file monitor command.
>> This command will allow passing of a filename and its corresponding
>> file descriptor to a guest via the monitor.  This command could be
>> followed, for example, by a drive_add command to hot attach a disk
>> drive.
>>
>> Signed-off-by: Corey Bryant<coreyb@linux.vnet.ibm.com>
>
> Is the only difference between 'getfd' and 'getfd_file' the fact that
> 'getfd' introduces an abstract namespace usable only by the fd:
> protocol, while the 'getfd_file' introduces a name identical to the
> absolute naming of the file system and usable by the file: protocol?

The only difference is that getfd passes an fdname to associate to the 
fd, and getfd_file passes a filename to associate to the fd.  These 
name/fd pairs are stored separately so there won't be any conflicts (ie. 
fdname == filename).

> What happens if I pass 'getfd_file' a relative file name?  Must the
> filename passed to 'getfd_file' be in canonical form, or may it contain
> symlinks, .., and other non-canonical constructs?

As the code is now, the 'getfd_file' filename has to be the same as the 
'drive_add' filename, for example.  And the same goes for the '-drive' 
filename and the '-filfd' filename.  I didn't introduce any special 
handling to canonicalize the filenames, but I think it is necessary. 
Either in QEMU or libvirt, but it probably makes more sense to 
canonicalize in QEMU.

>
> Can the 'closefd' command be used to close the fd originally given to
> qemu via 'getfd_file'?
>

No, 'closefd' won't close an fd passed in by 'getfd_file'.  I was 
thinking I should probably add a 'closefd_file' that could do this.


-- 
Regards,
Corey

  reply	other threads:[~2012-05-22 13:38 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-21 20:19 [Qemu-devel] [RFC PATCH 0/4] block: file descriptor passing using -filefd and getfd_file Corey Bryant
2012-05-21 20:19 ` [Qemu-devel] [RFC PATCH 1/4] qemu-options: Add -filefd command line option Corey Bryant
2012-05-21 21:40   ` Eric Blake
2012-05-22 13:25     ` Corey Bryant
2012-05-22 13:38       ` Kevin Wolf
2012-05-22 14:26         ` Stefan Hajnoczi
2012-05-22 14:39           ` Kevin Wolf
2012-05-21 20:19 ` [Qemu-devel] [RFC PATCH 2/4] qmp/hmp: Add getfd_file monitor command Corey Bryant
2012-05-21 21:48   ` Eric Blake
2012-05-22 13:37     ` Corey Bryant [this message]
2012-05-22  9:18   ` Stefan Hajnoczi
2012-05-22 14:13     ` Corey Bryant
2012-05-22 19:06     ` Luiz Capitulino
2012-05-22 20:02       ` Corey Bryant
2012-05-22 20:26         ` Luiz Capitulino
2012-05-22 22:34           ` Corey Bryant
2012-05-23 13:33             ` Luiz Capitulino
2012-05-23 13:45               ` Corey Bryant
2012-05-21 20:19 ` [Qemu-devel] [RFC PATCH 3/4] block: Enable QEMU to retrieve passed fd before attempting open Corey Bryant
2012-05-21 21:50   ` Eric Blake
2012-05-22 14:06     ` Corey Bryant
2012-05-21 20:19 ` [Qemu-devel] [RFC PATCH 4/4] Example -filefd and getfd_file server Corey Bryant
2012-05-22  8:18 ` [Qemu-devel] [RFC PATCH 0/4] block: file descriptor passing using -filefd and getfd_file Kevin Wolf
2012-05-22 12:02   ` Eric Blake
2012-05-22 12:08     ` Kevin Wolf
2012-05-22 14:30   ` Corey Bryant
2012-05-22 14:45     ` Kevin Wolf
2012-05-22 15:01       ` Eric Blake
2012-05-22 15:24         ` Kevin Wolf
2012-05-22 15:29       ` Corey Bryant
2012-05-22 15:39         ` Kevin Wolf
2012-05-22 16:02           ` Corey Bryant
2012-05-22 16:15         ` Eric Blake
2012-05-22 17:17           ` Corey Bryant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FBB9696.3010404@linux.vnet.ibm.com \
    --to=coreyb@linux.vnet.ibm.com \
    --cc=aliguori@us.ibm.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.