Re: [Qemu-devel] KVM call agenfda for 2014-04-01

[Markus Armbruster]

[Cc: Andreas, Anthony]

Alexander Graf <address@hidden> writes:

> On 10.04.2014, at 17:52, Peter Maydell <address@hidden> wrote:
>
>> On 10 April 2014 16:49, Alexander Graf <address@hidden> wrote:
>>> For the next call, I would propose to revive the "platform bus"
>>> (aka: how to create non-PCI devices with -device) discussions

Rather: devices that connect to more than just a bus.

Since pseudo-bus sysbus provides exactly no connections, sysbus devices
generally connect to more.

Currently, the only way to make such additional connections is
special-purpose code.  -device's connection engine can only connect to a
bus.

>>> to make sure we're all on the same page.
>> 
>> I rather suspect we are not :-)  Do you have a link to
>> the current proposals for prior reading?
>
> The only thing I could find is the old thread about my platform bus
> approach (which Anthony disliked):
>
>   https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg03614.html
>
> So from what I remember the plan moving forward was to have a special
> device type similar to my platform bus devices that you can just
> create using -device, no bus involved. The machine file would then
> loop through them, interpret the "I sit at address x" and "I want
> interrupt number y" fields to link them to whatever the machine model
> thinks is a good fit.
>
> The same way the machine model today has to have knowledge on each
> device tree node type it generates, it would do the same for these
> devices. So the machine has to have awareness of all the "funky
> special options" a device tree node receives - the same as for any
> other device. Just that in this case it wouldn't be able to hardcode
> them, but have to generate them on the fly when it sees a device in
> the object tree.

The following is just my understanding of where we're trying to go.  The
people active in this field (Andreas?) should correct misunderstandings.

Our overall goal is building machines from components by *data* rather
than code.  Once it's data, it can be made run-time configuration.

The configuration describes how components are to be connected, and
generic connection code makes the connections guided by the
configuration.

The current generic connection code can only connect a device to a
single bus.

If you don't specify the bus, it picks one.  Which one it picks is
effectively ABI.

Picking a bus is a special case of "pick a connection if user didn't
specify one".  The current bus-picker doesn't depend on the machine
type, but that's not going to hold in general.

I like to think of the "pick connections the user didn't specify" engine
as conceptually separate from the "make connections driven by
configuration" engine.  The actual code isn't so separate, but that's
implementation.

How does your "platform device" proposal (for lack of a better
expression) fit into this general framework of ideas?