Peter Maydell <peter.mayd...@linaro.org> writes:
> On 7 January 2014 12:33, Andreas Färber <afaer...@suse.de> 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.
