qemu-devel
[Top][All Lists]
Advanced

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

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


From: Eduardo Habkost
Subject: Re: [PATCH v3 21/33] lance: replace PROP_PTR with PROP_LINK
Date: Thu, 24 Oct 2019 15:07:14 -0300

On Thu, Oct 24, 2019 at 12:52:28PM +0100, Peter Maydell wrote:
> On Thu, 24 Oct 2019 at 12:48, Philippe Mathieu-Daudé <address@hidden> wrote:
> > Just wondering, if we had a "bus_address" property to the abstract
> > SysBus class (and eventually "bus_name" for later) we could create/map
> > sysbus devices from command line?
> 
> 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?

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.

-- 
Eduardo




reply via email to

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