Re: [Qemu-devel] [PATCH 1/2] hw: cannot_instantiate_with_device_add_yet due to pointer props

[Markus Armbruster]

Peter Maydell <address@hidden> writes:

> On 15 December 2013 20:55, Andreas Färber <address@hidden> wrote:
>> Since you're mentioned by name, should I wait for you to review the
>> three OMAP parts?
>
> There's nothing particularly omap-specific in them.

The only OMAP-specific issue I can think of would be me misreading the
intent of the code.

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

I share your doubts on the wisdom of letting users plug components via
command line or monitor that are really just parts of bigger components,
like the OMAP SoC.

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.

> Being able to write board models in something other than C
> would be nice, but I really think that if we pursue the idea of
> being able to do it all on the command line we'll just end up with
> a horrifically confusing command line syntax.

Command line / monitor could be divorced from hardware configuration.
Doesn't make much sense with the rather primitive device_add we got now.
May well make sense when our means to wire up hardware by configuration
rather than code have moved closer to the complex wirings we need to
model.