[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Why is TYPE_CPU no-user?
|
From: |
Markus Armbruster |
|
Subject: |
Re: [Qemu-devel] Why is TYPE_CPU no-user? |
|
Date: |
Tue, 15 Oct 2013 16:01:47 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) |
Peter Maydell <address@hidden> writes:
> On 15 October 2013 13:24, Markus Armbruster <address@hidden> wrote:
>> To go beyond RFC with this series, I need to explain why TYPE_CPU
>> cannot_instantiate_with_device_add_yet.
>
> ...isn't this just because it's an abstract type?
Abstract types have TypeInfo member abstract set. Not inherited by
subtypes, obviously.
DeviceClass member cannot_instantiate_with_device_add_yet is something
else entirely. After this series, it means what the name suggests.
Unlike abstract, it's effectively inherited.
TypeInfo's abstract is here to stay, but DeviceClass's
cannot_instantiate_with_device_add_yet should eventually go away.
TYPE_CPU has both of them set.
- Re: [Qemu-devel] Should the i8259 devices remain no-user?, (continued)
[Qemu-devel] [PATCH RFC 5/9] ich9: Document why cannot_instantiate_with_device_add_yet, armbru, 2013/10/10
[Qemu-devel] [PATCH RFC 6/9] piix3 piix4: Document why cannot_instantiate_with_device_add_yet, armbru, 2013/10/10
[Qemu-devel] [PATCH RFC 7/9] vt82c686: Document why cannot_instantiate_with_device_add_yet, armbru, 2013/10/10
[Qemu-devel] Why is TYPE_CPU no-user? (was: [PATCH RFC 0/9] Clean up and fix no_user), Markus Armbruster, 2013/10/15
[Qemu-devel] Which functions of southbridges should be no-user? (was: [PATCH RFC 0/9] Clean up and fix no_user), Markus Armbruster, 2013/10/15