[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] QOM: stability expectations of introspectable class_ini
From: |
Igor Mammedov |
Subject: |
Re: [Qemu-devel] QOM: stability expectations of introspectable class_init data |
Date: |
Fri, 15 Feb 2013 14:35:26 +0100 |
On Fri, 15 Feb 2013 10:50:16 -0200
Eduardo Habkost <address@hidden> wrote:
> Hi,
>
> This is an attempt to summarize my main question from the thread:
> Re: [Qemu-devel] [RFC v5] target-i386: Slim conversion to X86CPU
> subclasses + KVM subclasses
>
> My main unanswered question is about the "stability" expectations of the
> introspectable class data (especially property defaults).
>
> I am assuming and expecting that the introspectable QOM class data
> (especially property defaults) should simply reflect
> capabilities/behavior of the QEMU binary being queried, and would not
> change depending on the environment QEMU is running (host hardware and
> host kernel). This way, other components can use class introspection to
> probe for QEMU capabilities/behavior, and safely expect that the QEMU
> binary being queried will always have those capabilities/behavior.
>
> What Igor is proposing is to break my assumption, and make the default
> value of the "vendor" property on the X86CPU subclasses be different
> depending on the host CPU where QEMU is running.
i.e. reflecting actual value of CPUID.vendor of the host.
alternative proposed by Eduardo:
is to abstract default value of "vendor" property to "host" string.
>
> My question is: is that really OK?
>
> In another case, we are considering making other properties of a X86CPU
> subclass have different defaults depending on the capabilities of the
> host kernel (the "host" CPU class will have different feature property
> defaults depending on the capabilities reported by GET_SUPPORTED_CPUID).
> Would that be OK, too?
>