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