From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2Nwi-0002wI-TD for qemu-devel@nongnu.org; Tue, 28 Feb 2012 09:22:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S2Nwg-0003Id-Ti for qemu-devel@nongnu.org; Tue, 28 Feb 2012 09:22:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52828) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2Nwg-0003IP-LP for qemu-devel@nongnu.org; Tue, 28 Feb 2012 09:22:26 -0500 Date: Tue, 28 Feb 2012 11:22:22 -0300 From: Luiz Capitulino Message-ID: <20120228112222.31482e44@doriath.home> In-Reply-To: <20120228020728.GB2725@illuin> References: <2c332c139b3d6b38e2ef93e2efc951f8565c4a52.1329649806.git.mprivozn@redhat.com> <20120223122034.728c259c@doriath.home> <4F4BD034.5030400@redhat.com> <20120228020728.GB2725@illuin> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4] qemu-ga: Add guest-network-info command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: Michal Privoznik , qemu-devel@nongnu.org On Mon, 27 Feb 2012 20:07:28 -0600 Michael Roth 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.