Re: [PATCH v3 21/33] lance: replace PROP_PTR with PROP_LINK

[Peter Maydell]

On Thu, 24 Oct 2019 at 19:07, Eduardo Habkost <address@hidden> wrote:
> On Thu, Oct 24, 2019 at 12:52:28PM +0100, Peter Maydell wrote:
> > I don't think this is a good plan -- users shouldn't have to know
> > about the memory map of their boards. Plus it doesn't deal with
> > the complications of multiple address spaces, DMA, wiring up
> > irq lines to an interrupt controller, SoC reset handling,
> > clocks, power-managment...  Command line -device was designed
> > for pluggable devices, where in the world of real hardware
> > the device can be physically plugged and unplugged and there's
> > a clear interface that can be modelled. You can't add an
> > extra UART to an embedded board in real hardware either.
> >
> > The only plausible argument I've seen for command-line
> > plugging of embedded devices is as a sort of side-effect
> > of having a configuration language syntax for them for
> > the purpose of being able to write board models as
> > data-driven config files rather than in C code. But
> > that would be a lot of design and engineering work, and
> > if we want that I think we should approach it forwards,
> > not arrive at it backwards by adding gradual tweaks like
> > 'address' properties to devices.
>
> The QEMU community spent years designing QOM and QMP with that
> goal.  Which other pieces to you consider to be missing, to
> make you reject making gradual changes towards it?

QOM is an *internal* object model. It's fine for building
machine models *in C*. We have no mechanism for doing
this on the command line or via QMP, because there are
lots of parts of machine models (listed in the first
paragraph above) which aren't possible to do with purely
generic links and properties.

> I agree we shouldn't be introducing new external interfaces
> without careful thought.  But I welcome gradual internal API
> changes that are helpful for our long term goals.

Yeah, I have no objection to useful internal changes that
move generally in directions we'd like to go. But if
"machines via config files" really is a goal I'd like to
see at least a sketch of a design, rationale, summary of
what would need to change and proposals for what would be
done. And I don't think we should be exposing "MMIO addresses"
to users without at least some idea of why that would
fit in with other things we would be doing to move
towards where we're going.

(TBH: I also don't really see 'machines via config
files' as a serious project goal -- we haven't really moved
towards doing that in a decade, as far as I can see.)

thanks
-- PMM