[libvirt] [Qemu-devel] [PATCH v7 2/6] qapi: Introduce add-fd, remove-fd, query-fdsets

[Luiz Capitulino]

On Wed, 08 Aug 2012 15:07:02 -0400
Corey Bryant <coreyb at linux.vnet.ibm.com> wrote:

> 
> 
> On 08/07/2012 06:16 PM, Eric Blake wrote:
> > On 08/07/2012 11:07 AM, Corey Bryant wrote:
> >
> >>>> +#
> >>>> +# Since: 1.2.0
> >>>
> >>> We're not very consistent on '1.2' vs. '1.2.0' in since listings, but
> >>> that's probably worth a global cleanup closer to hard freeze.
> >>>
> >>
> >> I'll make a note of it.  Or does Luiz usually do a cleanup?
> >
> > No idea.
> >
> 
> Luiz, were you planning to take a pass at cleaning up the "since" 
> release?  If not let me know and I can submit a patch.  Just let me know 
> which to use, '1.2' or '1.2.0'.

I'd appreciate it if you submit a patch. I guess we should use 1.2.0.

> 
> >>>> +##
> >>>> +{ 'type': 'FdsetFdInfo', 'data': {'fd': 'int', 'removed': 'bool'} }
> >>>
> >>> Is it worth providing any additional information?  For example, knowing
> >>> whether the fd is O_RDONLY, O_WRONLY, or O_RDWR might be beneficial to
> >>> management apps trying to discover what fds are already present after a
> >>> reconnection, in order to decide whether to close them without having to
> >>> resort to /proc/$qemupid/fdinfo/nnn lookups.  It might even be worth
> >>> marking such information optional, present only when 'removed':false.
> >>>
> >>
> >> It makes sense but I'd like to limit the new functionality at this point
> >> so that I can get this support into QEMU 1.2.  Can this be added as a
> >> follow up patch?
> >
> > I'm personally okay with the idea of adding additional output fields in
> > later releases, but I know that has been questioned in the past, so you
> > may want to get buy-in from Luiz or Anthony.  I guess the other thing is
> > to see what libvirt would actually find useful, once I complete some
> > counterpart libvirt patches.  If libvirt can get by without any extra
> > information and without needing to hack things from procfs, then it's
> > not worth you spending the effort coding something that will be ignored;
> > conversely, if a piece of info is so important that I end up hacking
> > procfs anyways, that says we have a hole in QMP.  I'm okay waiting for now.
> >
> 
> Assuming the list of to-do's for the next patch version remains minimal, 
> I'll go ahead and add support to return the access mode flags  from 
> query-fdsets.  Also, I'm going to remove in-use from the returned data, 
> because it is always going to be true.
>