From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41021) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z60fg-0005eA-7Y for qemu-devel@nongnu.org; Fri, 19 Jun 2015 14:05:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z60fb-0003Z7-Ra for qemu-devel@nongnu.org; Fri, 19 Jun 2015 14:05:44 -0400 Received: from mx2.parallels.com ([199.115.105.18]:52028) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z60fb-0003YD-L4 for qemu-devel@nongnu.org; Fri, 19 Jun 2015 14:05:39 -0400 Message-ID: <558459EB.8010102@openvz.org> Date: Fri, 19 Jun 2015 21:05:31 +0300 From: "Denis V. Lunev" MIME-Version: 1.0 References: <1434733075-24240-1-git-send-email-den@openvz.org> <1434733075-24240-3-git-send-email-den@openvz.org> <558451C6.3070603@redhat.com> In-Reply-To: <558451C6.3070603@redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 02/10] qga: implement guest-pipe-open command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Olga Krishtal , qemu-devel@nongnu.org, Michael Roth On 19/06/15 20:30, Eric Blake wrote: > On 06/19/2015 10:57 AM, Denis V. Lunev wrote: >> From: Olga Krishtal >> >> The command creates FIFO pair that can be used with existing file >> read/write interfaces to communicate with processes spawned via the >> forthcoming guest-file-exec interface. >> >> Signed-off-by: Olga Krishtal >> Signed-off-by: Denis V. Lunev >> Acked-by: Roman Kagan >> CC: Eric Blake >> CC: Michael Roth >> --- >> qga/commands-posix.c | 96 +++++++++++++++++++++++++++++++++++++++++++++++++--- >> qga/commands-win32.c | 8 ++++- >> qga/qapi-schema.json | 44 ++++++++++++++++++++++++ >> 3 files changed, 143 insertions(+), 5 deletions(-) > Just an interface review at this point: > >> +++ b/qga/qapi-schema.json >> @@ -215,12 +215,56 @@ >> 'returns': 'int' } >> >> ## >> +# @GuestPipeMode >> +# >> +# An enumeration of pipe modes >> +# read: pipe is opened for writing data >> +# write: pipe is opened for reading data >> +# >> +# Since: 2.4 >> +## >> +{ 'enum': 'GuestPipeMode', >> + 'data': [ 'read', 'write' ] } >> + >> +## >> +# @GuestPipeInfo >> +# >> +# Information about pipe. >> +# >> +# Since: 2.4 >> +## >> +{ 'struct': 'GuestPipeInfo', >> + 'data': {'fd': 'int'} } > Missing a field of type GuestPipeMode? yep, nice catch :) >> + >> +## >> +# @guest-pipe-open >> +# >> +# Open a pipe to in the guest to associated with a qga-spawned processes >> +# for communication. > Reads poorly. Maybe: > > Open a pipe in the guest for association with later qga-spawned processes. ok >> +# >> +# Returns: Guest file handle on success, as per guest-file-open. This >> +# handle is usable with the same interfaces as a handle returned by >> +# guest-file-open. >> +# >> +# Since: 2.4 >> +## >> +{ 'command': 'guest-pipe-open', >> + 'data': { 'mode': 'GuestPipeMode' }, >> + 'returns': ['GuestPipeInfo'] } > I'm assuming the array will always contain two elements? Would it be > any simpler to return a single dictionary of { 'read': 'int', 'write': > 'int' } for naming the two fds directly, instead of having to parse > through [ { 'fd': 1 }, { 'fd': 2 } ] ? this looks much better to me >> + >> +## >> +## >> # @guest-file-close: >> # >> # Close an open file in the guest >> # >> # @handle: filehandle returned by guest-file-open >> # >> +# Please note that closing the write side of a pipe will block until the read >> +# side is closed. If you passed the read-side of the pipe to a qga-spawned >> +# process, make sure the process has exited before attempting to close the >> +# write side. >> +# >> # Returns: Nothing on success. >> # >> # Since: 0.15.0 >>