[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [libvirt] [PATCH v4 0/7] file descriptor passing using

From: Luiz Capitulino
Subject: Re: [Qemu-devel] [libvirt] [PATCH v4 0/7] file descriptor passing using pass-fd
Date: Thu, 28 Jun 2012 10:53:31 -0300

On Wed, 27 Jun 2012 10:58:01 +0200
Kevin Wolf <address@hidden> wrote:

> Am 26.06.2012 20:40, schrieb Corey Bryant:
> >>> Here is a quick proof of concept (ie untested) patch to demonstrate
> >>> what I mean. It relies on Cory's patch which converts everything
> >>> to use qemu_open. It is also still valuable to make the change
> >>> to qemu_open() to support "/dev/fd/N" for passing FDs during
> >>> QEMU initial startup for CLI args.
> >>>
> >>> IMHO, what I propose here is preferrable for QMP clients that
> >>> our current plan of requiring use of 3 monitor commands (passfd,
> >>> XXXXX, closefd).
> >>
> >> Thanks for the PoC.
> >>
> >> Two other required updates that I can think of would be:
> >>
> >> 1) Update change, block_stream, block_reopen, snapshot_blkdev, and
> >> perhaps other monitor commands to support receiving fd's via SCM_RIGHTS.
> >>
> > 
> > Nevermind my comment.  I see that your PoC supports passing nfds for any 
> > QMP command.
> > 
> > I'm curious what Kevin's thoughts are on this and the overall approach.
> I'm not against introducing this nfd thing as a general feature for QMP
> commands instead of a separate pass-fd command. It's not obvious to me
> that everyone would agree with that, so let's CC Luiz at least.

I don't have objections either, but I want to point out two things.

First, we've agreed on adding new commands instead of extending existing
ones. I feel that not everyone is agreement with this and maybe we could
revisit this topic, but in principle new commands should be added.

Secondly, this is just a small suggestion, but we're in a point in time
where several block commands are being added. I think it's a good moment
to think hard how the ideal block API would look like and try to design
new commands based on that.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]