Re: [Qemu-devel] [PATCH v3] qemu-ga: add guest-get-osrelease command

[Eric Blake]

On 05/24/2017 04:51 PM, Tomáš Golembiovský wrote:
> So what about the following, would that be acceptable?
> 
> 
> ##
> # @GuestOSRelease:
> #
> # @content:
> #           POSIX systems the @kernel_version, @kernel_release and
> #           @machine_hardware correspond to the values release, version and
> #           machine returned by uname(2). On Windows, they correspond to the
> #           version number, build number and architecture.

You'll have to actually document each field, not just a catch-all
@content.  You can list per-OS on which field is likely to be present or
absent.

> #
> #           On Linux-based system where os-release info is available either
> #           from /etc/os-release or from /usr/lib/os-release, the fields @id,
> #           @name, @pretty_name, @version, @version_codename, @variant,
> #           correspond to the fields of the same name defined in 
> os-release(5).
> #           On Windows, the data is generated based on the available
> #           inforamtion.

s/inforamtion/information/

> #
> # Since: 2.10
> ##
> { 'struct': 'GuestOSRelease',
>   'data': {
>       'kernel_release': 'str',

Please name this 'kernel-release'; new interfaces should use '-' rather
than '_'.

>       'kernel_version': 'str',

Etc.

>       'machine_hardware': 'str'
>       'id': '*str',

If a field doesn't make sense for all guests, then it should be marked
optional (for example, a Linux guest that does not have
/etc/os-release).  Marking a field optional is done as '*id':'str' (you
got it backwards).


>       'name': '*str',
>       'pretty_name': '*str',
>       'version': '*str',
>       'version_codename': '*str',
>       'variant': '*str',
>   } }
> 
> 

It's probably a reasonable start at the interface, though.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature