Il 23/07/2013 14:40, Peter Maydell ha scritto:
> On 23 July 2013 13:34, Paolo Bonzini <pbonz...@redhat.com> wrote:
>> 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.
>
> Well, the justification for this whole new bus appears to be
> "so you can easily just add a new device on the command line".
"-readconfig" is another way to write command line options, e.g.
[drive "hd"]
file = /home/pbonzini/test.img
if = none
[device]
driver = "virtio-blk"
drive = hd
or something like 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.
>
> Yes, we should have easy support for defining a pluggable
> bus as a collection of pins.
And a container memory region too---in the end, this is what Alex's
platform bus does.
>> 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.
>
> Agreed, more or less. Actually I'd rather sysbus devices
> went away -- the requirement for interrupt and GPIO and
> memory regions to all be defined as single arrays (so you
> have to know what interrupt line 3 happens to be, and
> that memory region 1 is the registers, and so on) is
> pretty unfriendly. We should be able to define all these
> as named connections.
Yeah, that's the icing on the cake. :)
Paolo
