qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/2] hw: cannot_instantiate_with_device_add_yet


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 1/2] hw: cannot_instantiate_with_device_add_yet due to pointer props
Date: Tue, 07 Jan 2014 15:08:09 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Peter Maydell <address@hidden> writes:

> On 7 January 2014 12:33, Andreas Färber <address@hidden> wrote:
>> Am 16.12.2013 10:33, schrieb Peter Maydell:
>>> Anyway, I don't actively object to this series. I just think
>>> Anthony's going in the wrong direction which is why I haven't
>>> been particularly eager to actively mark it as reviewed-by me
>>> either...
>>
>> Sorry for not taking the time to reply to these concerns earlier. I
>> thought it was self-speaking that the enterprise Linux distributors
>> among us want a safeguard to avoid customers from crashing a
>> long-running VM with some avoidable device_add.
>
> Sure. I think the right way to do that is to only allow
> them to plug in devices that are truly pluggable (ie which
> are on some pluggable bus like PCI or USB), rather than
> this way round, which is trying to blacklist devices rather
> than whitelist bus types.
>
> In short, we shouldn't be trying to cram all of "hotplug",
> "I want an extra PCI card in my VM" and "I want to do
> complete from-scratch construction of a machine model
> including wiring up all the interrupts and defining the
> memory map" into the same interface, because the flexibility
> you need for the last one of these is going to cause endless
> user errors when attempting the first two.

Your point is that having one tool (device_add) for two rather different
purposes ("wire components into a machine" and "plug stuff into sockets
meant for that") is problematic.  Makes sense to me.

Now let's imagine we had a separate tool for each purpose.  Let's call
them "wire up" and "plug".  Let's further imagine QOM/qdev and the
device are basically still in their current state.  Then you need a
separate predicate "tool is applicable to qdev" for each of the two
tools!

The predicate for "plug" could perhaps be "is this a usable plug/socket
pair", as you suggest.

The predicate for "wire up" will be pretty much exactly what
cannot_instantiate_with_device_add_yet is now: a long list of devices
that can only be wired up by special-purpose code, mostly due to
limitations of the "wire up" tool's general-purpose code, and the
QOM/qdev infrastructure below it.  As these limitations are addressed,
the list should shrink.  Anthony wants it to shrink to nothing
eventually.

In short, I doubt we're disagreeing on anything substantial.



reply via email to

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