From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TqJgM-0000up-Qp for qemu-devel@nongnu.org; Wed, 02 Jan 2013 03:28:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TqJgK-0002UP-Tr for qemu-devel@nongnu.org; Wed, 02 Jan 2013 03:28:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46278) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TqJgK-0002UD-Lr for qemu-devel@nongnu.org; Wed, 02 Jan 2013 03:28:12 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r028SAt5022298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 2 Jan 2013 03:28:11 -0500 Message-ID: <50E3EF98.4070300@redhat.com> Date: Wed, 02 Jan 2013 09:28:08 +0100 From: Michal Privoznik MIME-Version: 1.0 References: <50D4ADEB.3060205@redhat.com> In-Reply-To: <50D4ADEB.3060205@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] qemu-ga: Extend guest-network-get-interfaces List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: qemu-devel@nongnu.org On 21.12.2012 19:43, Eric Blake wrote: > On 12/21/2012 05:59 AM, Michal Privoznik wrote: >> Nowadays only basic information is reported. However, with the >> current implementation much more can be exposed to users. like >> broadcast/destination address (the former in case of standard >> ethernet device, the latter in case of PPP interface), if the >> interface is up, of type loopback, in promisc mode or capable of >> sending multicast. >> --- >> > >> +++ b/qga/qapi-schema.json >> @@ -480,26 +480,57 @@ >> # >> # @prefix: Network prefix length of @ip-address >> # >> -# Since: 1.1 >> +# @dest-address: The broadcast or peer address. >> +# >> +# Since: 1.1, @dest-address since 1.3 > > Actually, since 1.4 now (1.3 is already out). > >> ## >> { 'type': 'GuestIpAddress', >> 'data': {'ip-address': 'str', >> 'ip-address-type': 'GuestIpAddressType', >> - 'prefix': 'int'} } >> + 'prefix': 'int', >> + '*dest-address': 'str'} } > > Is this field always going to be present in 1.4? If so, then it doesn't > need to be marked optional (even though it wasn't present in 1.3). Not really. This field is gonna be there iff guest agent is able to dig the info out. For instance, for PPP interfaces, I was unable to get peer's address via getifaddrs(). Other utilities use netlink for that. However, if interface has an broadcast address, this can be easily obtained via getifaddrs(). That's why I am making this optional for now. > >> ## >> +# @GuestNetworkInterfaceType: >> +# >> +# @broadcast: Interface has a broadcast address. In which case it is >> +# contained in @dest-address in @GuestIpAddress. >> +# >> +# @ppp: Interface is of point-to-point type. The peer address is then in >> +# @dest-address in @GuestIpAddress. >> +# >> +# Since: 1.3 > > 1.4 > >> +## >> +{ 'enum': 'GuestNetworkInterfaceType', >> + 'data': ['broadcast', 'ppp'] } >> +## >> # @GuestNetworkInterface: >> # >> # @name: The name of interface for which info are being delivered >> # >> +# @up: If the interface is up >> +# >> +# @loopback: If the interface is of loopback type >> +# >> +# @promisc: If the interface is in promiscuous mode >> +# >> +# @multicast: If the interface is cappable of multicast > > s/cappable/capable/ > >> +# >> +# @type: If the interface has a broadcast address(-es) assigned, or is a PPP. >> +# >> # @hardware-address: Hardware address of @name >> # >> # @ip-addresses: List of addresses assigned to @name >> # >> -# Since: 1.1 >> +# Since: 1.1, @up, @loopback, @promisc, @multicast and @type since 1.3 > > 1.4 > >> ## >> { 'type': 'GuestNetworkInterface', >> 'data': {'name': 'str', >> + 'up': 'bool', >> + 'loopback': 'bool', >> + 'promisc': 'bool', >> + 'multicast': 'bool', >> + '*type': 'GuestNetworkInterfaceType', > > Again, is this field optional? Yes. Because this actually tells type of 'dest-address' field which is optional I think this one should be optional as well. > >> '*hardware-address': 'str', >> '*ip-addresses': ['GuestIpAddress'] } } >> >> > Michal