qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 00/15] QOM'ify x86 CPU, part 2: properties


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH 00/15] QOM'ify x86 CPU, part 2: properties
Date: Tue, 24 Apr 2012 11:00:49 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120328 Thunderbird/11.0.1

Am 19.04.2012 20:27, schrieb Eduardo Habkost:
> By the way, do you still plan to make cpudefs register new
> classes/types? I remember that you did that on a previous series.

Generally I do, yes. However the CPU QOM'ification is not making as much
progress as I would've liked, specifically there's still five targets
left in my queue for base QOM'ification for 1.1.

This series, x86 part 2, goes further and prepares properties a) for
general inspection and modification (but without having the CPU exposed
as a child yet), b) for use in instantiating subclasses in part 3. It
was intended for 1.1.

Question is, do we want CPU subclasses for 1.1? ARM has them now but we
won't manage to unify this across targets in time for the Hard Freeze.

For ARM there was a dislike of the ARMCPUClass-based approach and a
preference towards hardcoding things imperatively in initfns. I don't
see how that would work for cpudef, so I would stick with extending
X86CPUClass.

There was a dislike of duplicating fields between X86CPUInfo and
X86CPUClass. However to avoid incurring a sub-struct access the only way
would be to move the field definitions to a macro and use it in both
locations. Further opinions or suggestions welcome.

I've also not yet seen a discussion whether we need to allow modifying
built-in classes via cpudef or whether adding new classes is sufficient.
I had implemented both in my RFC but would prefer the latter if there is
agreement.

> Is it possible to have property get/setters for ObjectClass QOM objects,
> too? It would be interesting to use QOM properties for the cpudef fields
> as well (it would make the work of defining boolean feature fields much
> simpler).

No. Classes do not have property infrastructure and I personally see
them as immutable. cpudef is independent of classes though, so you could
invent a new mechanism to set/unset features, whatever the backend
they'll be written to.

> Reviewed-by: Eduardo Habkost <address@hidden>

Thanks, will send out v2 shortly with the requested changes.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]