[Top][All Lists]
[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
- [Qemu-devel] [PATCH 11/15] target-i386: Add property getter for CPU model-id, (continued)
- [Qemu-devel] [PATCH 08/15] target-i386: Add property getter for CPU family, Andreas Färber, 2012/04/17
- [Qemu-devel] [PATCH 07/15] target-i386: Add "model-id" property to X86CPU, Andreas Färber, 2012/04/17
- [Qemu-devel] [PATCH 09/15] target-i386: Add property getter for CPU model, Andreas Färber, 2012/04/17
- Re: [Qemu-devel] [PATCH 00/15] QOM'ify x86 CPU, part 2: properties, Eduardo Habkost, 2012/04/19
- Re: [Qemu-devel] [PATCH 00/15] QOM'ify x86 CPU, part 2: properties,
Andreas Färber <=
- Re: [Qemu-devel] [PATCH 00/15] QOM'ify x86 CPU, part 2: properties, Michael Roth, 2012/04/19