qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: Michal Privoznik <mprivozn@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v4] qemu-ga: Add guest-network-info command
Date: Tue, 28 Feb 2012 11:22:22 -0300	[thread overview]
Message-ID: <20120228112222.31482e44@doriath.home> (raw)
In-Reply-To: <20120228020728.GB2725@illuin>

On Mon, 27 Feb 2012 20:07:28 -0600
Michael Roth <mdroth@linux.vnet.ibm.com> wrote:

> What about something like this instead:
> 
> { 'enum': 'GuestIpAddressType',
>   'data': [ 'ipv4', 'ipv6' ] }
> 
> { 'type': 'GuestIpAddress',
>   'data': {'ip-address': 'str',
>            'ip-address-type': 'GuestIpAddressType',
>            'prefix': 'int'} }
> 
> { 'type': 'GuestNetworkInterface',
>   'data': {'interface': {'name': 'str',
>                          '*hardware-address': 'str',
>                          '*ip-addresses': ['GuestIpAddress'] } } }
> 
> { 'type': 'GuestNetworkInfo',
>   'data': { 'interfaces': ['GuestNetworkInterfaces'] } }
> 
> { 'command': 'guest-network-info',
>   'returns': 'GuestNetworkInfo' }
> 
> In the future we might have:
> 
> { 'type': 'GuestNetworkInfo',
>   'data': { 'interfaces': ['GuestNetworkInterfaces'],
>             'routes': ['GuestNetworkRoute'],
>             'bridges': ['GuestNetworkBridge'],
>             'firewall-rules': ['firewall-rule'], # yikes
>             etc. } }

Both approaches are fine to me, but another possibility is to split this into
multiple commands, like guest-interfaces-info, guest-routes-info etc. This would
allow for simpler commands with less clutter.

> > Once we settle down on this I can send another version for review.
> > Personally, if guest agent would report description (see my other e-mail
> > [1]) I don't see big advantage in introducing dozens of error codes here.
> 
> descriptions are mapped to QERRs though, so it'd only be useful if you
> defined specific errors for these cases. I agree with Luiz, but at the
> same time it's not exactly tractable to enumerate all possible errors for every
> command into a unique QERR except for common things like FD_NOT_FOUND. So maybe
> just a QERR_QGA_INTERFACE_ENUMERATION_FAILED, that took a stringified error
> message? I don't really have a strong opinion either way.

Well, turns out I'm not sure what to do here either. On the one hand it's a
huge work (and probably unnecessary) to add all possible errors. On the other
hand, it's really hard to debug a problem when all information you have is
a generic error.

As this a relatively simple query command, I'm fine with simple/generic errors.

  reply	other threads:[~2012-02-28 14:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-19 11:15 [Qemu-devel] [PATCH v4] qemu-ga: Add guest-network-info command Michal Privoznik
2012-02-22 17:10 ` Michal Privoznik
2012-02-23 14:20 ` Luiz Capitulino
2012-02-27 18:49   ` Michal Privoznik
2012-02-28  2:07     ` Michael Roth
2012-02-28 14:22       ` Luiz Capitulino [this message]
2012-02-28 17:09         ` Michael Roth
2012-02-28 17:41           ` Luiz Capitulino
2012-02-29 13:17             ` Michal Privoznik
2012-02-29 15:01               ` Luiz Capitulino
2012-02-29 15:32                 ` Michael Roth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120228112222.31482e44@doriath.home \
    --to=lcapitulino@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=mprivozn@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).