On 11.04.14 09:46, Markus Armbruster wrote:
[Cc: Andreas, Anthony]
Alexander Graf <agraf@xxxxxxx> writes:
On 10.04.2014, at 17:52, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote:
On 10 April 2014 16:49, Alexander Graf <agraf@xxxxxxx> 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.
I've had plenty of discussions on this with Anthony over the years
(first time this came up was about 2 or 3 years ago) on this. Eventually
his conclusion was that it's not desirable to build the machine from
data. Instead it should get built from a script. The nice thing about a
script is that it's also run-time, but not as restricted and as much
special-cased as a mere description.
Unfortunately I don't know all of the rationale that went into the
conclusion :).
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?
Any leaf devices that are not hooked up to anything get connected by
machine specific code :). So the "pick connections the user didn't
specify" logic would be machine specific.
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
