From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41005) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y7Cdv-00040y-Md for qemu-devel@nongnu.org; Fri, 02 Jan 2015 19:32:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y7Cds-0002Jx-Cx for qemu-devel@nongnu.org; Fri, 02 Jan 2015 19:32:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45225) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y7Cds-0002Jn-5n for qemu-devel@nongnu.org; Fri, 02 Jan 2015 19:32:32 -0500 Date: Sat, 3 Jan 2015 00:32:21 +0000 From: "Richard W.M. Jones" Message-ID: <20150103003221.GA9693@redhat.com> References: <1418715038-4664-1-git-send-email-zhang.zhanghailiang@huawei.com> <1418715038-4664-2-git-send-email-zhang.zhanghailiang@huawei.com> <54905C92.7070203@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54905C92.7070203@redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH 1/2] qga: Introduce guest-get-os-version command with stubs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: lilei@linux.vnet.ibm.com, qemu-devel@nongnu.org, peter.huangpeng@huawei.com, lcapitulino@redhat.com, lersek@redhat.com, mdroth@linux.vnet.ibm.com, zhanghailiang On Tue, Dec 16, 2014 at 09:23:46AM -0700, Eric Blake wrote: > On 12/16/2014 12:30 AM, zhanghailiang wrote: > > +# Since: 2.3 > > +## > > +{ 'type': 'GuestOSVersion', > > + 'data': {'name': 'str', 'type': 'int'} } > > 'name' feels a bit vague; it looks like you are intending to use the > string as a free-form text field, where the guest can supply arbitrary > strings. Maybe name it 'info' instead? Is it worth being any stricter, > such as having actual enums of known values? On the other hand, tying > to known enums means we have to update qemu-ga every time a new guest > gains support for running the agent, while free-form string leaves us a > bit more flexible. Or maybe you want both, as in: > > { 'enum': 'GuestOSFamily', 'data': ['Windows', 'Linux', 'other'] } > { 'type': 'GuestOSVersion', > 'data': { 'info': 'str', 'family': 'GuestOSFamily', > 'word-width': 'int' } } I think it's better to tie this to libosinfo, rather than invent yet another new classification for OSes. Rich. > > + > > +## > > +# @guest-get-os-version: > > +# > > +# Get the guest's operating system version and bit. > > s/bit/word width/ > > > +# > > +# This is a read-only operation. > > +# > > +# Returns: version > > +# > > +# Since: 2.3 > > +## > > +{ 'command': 'guest-get-os-version', > > + 'returns': 'GuestOSVersion' } > > with my suggestions, a usage might be: > => { "execute": "guest-get-os-version" } > <= { "return": { "family": "Windows", > "info": "Microsoft Windows Server 2012 R2", > "word-width": 64 } } > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html