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