[Qemu-devel] [RFC] New Monitor command: 'info netdevices'

[Qemu-devel] [RFC] New Monitor command: 'info netdevices'

[Luiz Capitulino]

 Hi there,

 Miguel is working on converting 'info network' to QMP, but turns out that it's
been quite difficult to maintain the exact same output.

 The main problem seems to be the usage of the 'info_str' string, which some
drivers (like tap, xen, vde, socket, etc) write arbitrary data into it. Then,
it's difficult to maintain the same output when we store the same data in
a qdict.

 Another problem is wrt to maintaining the same ordering of devices, while
there's a solution for this one, the code gets ugly.

 We have to choices:

1. Convert it, anyway. Try our best not to break the output, even knowing
   this is likely to happen

2. Play it safe and introduce a new 'info netdevices' command, which
   just print one device per line

 I think 2 is better.

PS: As far as I know, 'info network' is not used by libvirt.

Re: [Qemu-devel] [RFC] New Monitor command: 'info netdevices'

[Markus Armbruster]

Luiz Capitulino <lcapitulino@redhat.com> writes:

>  Hi there,
>
>  Miguel is working on converting 'info network' to QMP, but turns out that it's
> been quite difficult to maintain the exact same output.
>
>  The main problem seems to be the usage of the 'info_str' string, which some
> drivers (like tap, xen, vde, socket, etc) write arbitrary data into it. Then,
> it's difficult to maintain the same output when we store the same data in
> a qdict.
>
>  Another problem is wrt to maintaining the same ordering of devices, while
> there's a solution for this one, the code gets ugly.
>
>  We have to choices:
>
> 1. Convert it, anyway. Try our best not to break the output, even knowing
>    this is likely to happen
>
> 2. Play it safe and introduce a new 'info netdevices' command, which
>    just print one device per line
>
>  I think 2 is better.

There's also

3. Convert it anyway.  Clean up the mess.  Change the output.

> PS: As far as I know, 'info network' is not used by libvirt.

Re: [Qemu-devel] [RFC] New Monitor command: 'info netdevices'

[Miguel Di Ciurcio Filho]

On Fri, May 14, 2010 at 6:46 AM, Markus Armbruster <armbru@redhat.com> wrote:
>
> There's also
>
> 3. Convert it anyway.  Clean up the mess.  Change the output.
>

I agree.

It seams to me that no one is concerned with any Monitor output change
with this particular command.

Plus, no one have shown any concerns about the problems I've found in
net/socket.c reported previously either.

[Qemu-devel] Re: [RFC] New Monitor command: 'info netdevices'

[Anthony Liguori]

On 05/13/2010 09:18 AM, Luiz Capitulino wrote:
>   Hi there,
>
>   Miguel is working on converting 'info network' to QMP, but turns out that it's
> been quite difficult to maintain the exact same output.
>
>   The main problem seems to be the usage of the 'info_str' string, which some
> drivers (like tap, xen, vde, socket, etc) write arbitrary data into it. Then,
> it's difficult to maintain the same output when we store the same data in
> a qdict.
>
>   Another problem is wrt to maintaining the same ordering of devices, while
> there's a solution for this one, the code gets ugly.
>
>   We have to choices:
>
> 1. Convert it, anyway. Try our best not to break the output, even knowing
>     this is likely to happen
>
> 2. Play it safe and introduce a new 'info netdevices' command, which
>     just print one device per line
>
>   I think 2 is better.
>
> PS: As far as I know, 'info network' is not used by libvirt.
>    

I'd vote for (2).

Regards,

Anthony Liguori

Re: [Qemu-devel] [RFC] New Monitor command: 'info netdevices'

[Luiz Capitulino]

On Fri, 14 May 2010 09:38:58 -0300
Miguel Di Ciurcio Filho <miguel.filho@gmail.com> wrote:

> On Fri, May 14, 2010 at 6:46 AM, Markus Armbruster <armbru@redhat.com> wrote:
> >
> > There's also
> >
> > 3. Convert it anyway.  Clean up the mess.  Change the output.
> >
> 
> I agree.
> 
> It seams to me that no one is concerned with any Monitor output change
> with this particular command.
> 
> Plus, no one have shown any concerns about the problems I've found in
> net/socket.c reported previously either.

 Sending patches increases the chances someone will look into it.