qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
Date: Wed, 08 Jan 2014 05:24:44 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Am 08.01.2014 04:07, schrieb Peter Crosthwaite:
> On Wed, Jan 8, 2014 at 2:59 AM, Paolo Bonzini <address@hidden> wrote:
>> Il 07/01/2014 16:12, Markus Armbruster ha scritto:
>>>     aarch64     akita           info qtree crashes
>>>     aarch64     borzoi          info qtree crashes
>>>     aarch64     spitz           info qtree crashes
>>>     aarch64     terrier         info qtree crashes
>>>     aarch64     tosa            info qtree crashes
>>>     arm         akita           info qtree crashes
>>>     arm         borzoi          info qtree crashes
>>>     arm         spitz           info qtree crashes
>>>     arm         terrier         info qtree crashes
>>>     arm         tosa            info qtree crashes
>>>     cris        axis-dev88      info qtree crashes
>>
>> The crash is because of commit 7426aa7 (nand: Don't inherit from Sysbus,
>> 2013-06-18).   Should probably be reverted.
>>
> 
> Prefer not, under no reasonable definition is NAND a sysbus device.
> Whats the real problem here? What is TYPE_SYS_BUS_DEVICE doing WRT to
> qtree that TYPE_DEVICE is not?

Not fully aware of the context yet, but my response to complaints about
info qtree, whether here or from Igor, will be to simply drop it.

Anthony has clearly stated on a KVM call that we should not design code
to please info qtree but to use the new QOM paradigms. If people don't
listen, we must take qdev stuff away for people to realize it - 2.0 is
certainly a good point in time. And I had already informally posted a
qom-tree Python script to the list that I can turn into a formal patch.

My plan was to first extend the qom-test to assure that all machines'
properties can be qom-get'ed crash-free, but we can of course skip such
safety precautions if that helps avoid weird workarounds.

As a reminder, the CPU is not a SysBus device either (ICC on x86, device
elsewhere) and I certainly don't want to make it one, especially now
that we're about to refactor AddressSpaces.

Regards,
Andreas


P.S. PMM, reading aarch64 above in the context of machines, I don't see
a single check-qtest-aarch64-y line in tests/Makefile! Please enable
qom-test if qemu-system-aarch64 is already available. Thought you just
said it would be linux-user only for 2.0 though?

-- 
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]