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: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 1/2] hw: cannot_instantiate_with_device_add_yet due to pointer props
Date: Mon, 16 Dec 2013 09:33:39 +0000

On 16 December 2013 08:48, Markus Armbruster <address@hidden> wrote:
> Peter Maydell <address@hidden> writes:
>> I kind of think this whole thing is backwards anyway:
>> we should really say "the user can only instantiate
>> devices via command line or monitor that are specifically
>> intended to be hot-pluggable", rather than having an
>> enormous list of devices we flag as not instantiable
>> by the user. Even if someday we manage to make it technically
>> possible to instantiate an omap_i2c device (say) from the
>> command line, it will still be a completely bizarre thing to do
>> because it's only intended to work as a part of the omap SoC.
>
> "Hot-pluggable" doesn't apply here.  There are plenty of devices that
> can only be cold-plugged, yet are absolutely meant to be user-pluggable.
> Real ISA cards, for instance.

Mmm. Just plain "pluggable" would be more what I meant:
modelling something that on real hardware is really a
simple pluggable socket.

> However, the current code lets users plug absolutely everything, even
> stuff that is known not to work.  The code still has the remnants of a
> mechanism meant to protect users from known-not-to-work plugs, but it
> got broken some time ago.  My "Clean up and fix no_user" series fixes
> that regression in a way that's hopefully agreeable with Anthony, who
> has been quite insistent on letting device_add plug more rather than
> less.  This series merely patches some holes on top.
>
> The list of non-pluggable devices may be larger than the list of
> pluggable ones, but: I count just 48 instances of
> "cannot_instantiate_with_device_add_yet = true".  I doubt marking
> devices that can be plugged instead of the ones than can't be would take
> fewer marks.  Moreover, each one comes with a comment explaining *why*
> the device cannot be plugged.  Sure nice to have when such a "why" goes
> away.  Some of them are expected to go away eventually.

I would expect 99% of actually pluggable devices to be pluggable
because they're using a pluggable bus: ISA, PCI, USB, ...

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

thanks
-- PMM



reply via email to

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