On Wed, Jun 06, 2012 at 10:04:23AM -0400, Corey Bryant wrote:
>
>
> On 06/05/2012 02:30 PM, Luiz Capitulino wrote:
> >On Mon, 4 Jun 2012 09:10:08 -0400
> >Corey Bryant<cor...@linux.vnet.ibm.com> wrote:
> >
> >>This patch adds QMP support for the getfd command using the QAPI framework.
> >>Like the HMP getfd command, it is used to pass a file descriptor via
> >>SCM_RIGHTS. However, the QMP getfd command also returns the received file
> >>descriptor, which is a difference in behavior from the HMP getfd command,
> >>which returns nothing.
> >
> >I have a few comments regarding the qapi conversion below, but something
> >important to discuss is that returning an int the way you're doing it is
> >certainly incompatible.
>
> Thanks for your feedback.
>
> >
> >Today, we return a dict on success:
> >
> > { "return": {} }
> >
> >But this patch changes it to:
> >
> > { "return": 42 }
> >
> >There are two ways to do this without breaking compatibility:
> >
> > 1. Add a new command (say get-file-descriptor)
>
> What do you think about using getfd2 for the command name? I'm
> thinking getfd2 may be more obvious that it corresponds to closefd.
> That assumes we'll use the same array internally to store fds and
> closefd can be used to close the fd opened by
> get-file-descriptor/getfd2.
How about calling it 'passfd' instead ? I have always thought
the name 'getfd' to be a little wierd really, since we're not
getting an FD from QEMU, we're passing it one that we have.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
