Il 23/07/2013 14:22, Peter Maydell ha scritto: > On 23 July 2013 13:19, Paolo Bonzini <pbonz...@redhat.com> wrote: >> Il 22/07/2013 20:21, Peter Maydell ha scritto >>> you can't as a user of this sort of hardware >>> plug in an extra serial port to a SoC, because there's just nowhere >>> to plug it in. So why should it be possible to plug an extra >>> serial port into the QEMU model of the SoC? >> >> And why exactly should QEMU be limited to modeling an existing SoC? >> >> Perhaps the user is not working with an existing SoC. They are working >> with with IP building blocks that they can combine the way they prefer, >> and they haven't yet made up their mind on the exact set of devices >> they'll have. (because not all the world is a PC, but then not all the >> non-PC world is ARM either). > > This sounds like (a) a good thing (b) something that will > turn into an incredible incomprehensible mess if we try > to specify it on the command line. Why would we want to do that?
It is an incomprehensible mess on the command line, but it is actually quite fine if you use "-readconfig" instead. It will not support for "-serial" and similar "shortcut" options, but they aren't necessary. PCI-enabled or paravirtual boards have been able to run for years now with "-nodefaults" and only "-device" options. > That is, you're arguing for a scripting/config language for > putting together board models so you don't have to write them > in C. That's a good thing, but not what this patch series is doing. It is, modulo lack of support for "-serial" and similar "shortcut" options. Gluing those still requires C code (for PC as well). >> Perhaps the user is working on kernel support for device tree / ACPI, >> wants to test many device combinations, and does not want to touch C >> code in order to do that. >> >> Perhaps the user can plug daughterboards that connect to the SoC and add >> an extra serial port, visible as yet another MMIO device. > > Pluggable daughterboards should be implemented by actually > defining the bus/socket that exists between the mainboard > and the daughterboard, so you could say -device my-daughterboard > and have it plug in to the mainboard. The bus might just be the processor's data bus + the interrupt controller's pins, basically the same as sysbus. In fact, the main thing I dislike about Alex's patch is adding a new bus instead of making sysbus devices "just work" as pluggable devices. Paolo
