On Wed, 08 Aug 2012 15:07:02 -0400 Corey Bryant <cor...@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. > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list