Re: [Qemu-devel] [RFC 2/5] acpi: introduce TYPE_ACPI_DEVICE_IF interface

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]

On 06/05/2014 04:10 AM, Igor Mammedov wrote:

>> And my question in 4/5 remains - should 'source' and/or 'status' be
>> defined as an enum rather than an open-coded int?
> Using enum for 'source' event, might be possible if we restrict ourselves
> to a limit set of supported values and ignore the rest of
> unknown/not implemented values. It might be not a good idea to lose
> events because QEMU doesn't know about them.
> Also from maintainability PoV it would add a bunch of mapping code
> from 'int' into our enum, which would essentially prevent
> new source events be exposed to users until QEMU adds support for
> them.
> 
> For 'status' code it'd add a lot more mapping code to translate its
> known values into enum since it's changing depending on 'source'.
> Especially if it comes to expanding range of known values in
> table 6-160 of ACPI5.0 spec.
> 
> I think it would be better to expose raw values the guest reported
> via _OST and let management to pick-up ones it's interested in and
> allow it to handle not implemented ones as it wishes rather than
> hiding them at QEMU level.

Fair enough - if qemu is just doing passthrough, and is not doing any
particular change in behavior based on particular values being passed
through, then exposing raw status codes is the only scalable approach
(new codes are equally uninteresting to qemu, and passthrough handles a
raw value better than qemu trying to interpret and name all values being
passed through).  But probably worth documenting this rationale in the
commit message, so we can remember why we chose to go this way.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]