Re: [Qemu-devel] qdev for programmers writeup

[Paolo Bonzini]

On 07/11/2011 04:44 PM, Peter Maydell wrote:
> > That's true, but the only way to plug in those device models would be with C
> > code.  You cannot just play with -device to reconfigure them.
>
> I think the C source level reuse is more important and more useful
> than plugging stuff around with -device, because in practice messing
> about with the memory map of an embedded board isn't something people
> typically want to do, because the kernel will have more-or-less
> hardcoded where the devices are anyhow.

That's just because ARM doesn't (yet?) do device trees... :)

> (Also if you have one bus type
> per board then you're still very limited in what you can do with -device
> because you can't plug in some random other sysbus device anyway.)

I'm not talking about one bus type per board!  I'm talking about as few 
as possible board-specific root devices, and sharing buses between 
boards as much as possible.

> So if
> we want to allow runtime configurability of boards like that we need
> to do it by providing runtime configurability of sysbus devices.

But we already have properties as a runtime configurability mechanism, 
and the additional functionality provided by SysBus is exactly to bypass 
it.  In that sense SysBus is bad (if used widely as it is now).

It is also bad because SysBus takes device metainformation (number of 
IRQ lines, size of MMIO and PIO areas) and puts it into per-device 
structure.

> I think it would be better to think of GPIO as a special (simple)
> case of a generic desire to plug devices into each other (this is what
> SystemC calls a "port": basically an interface (API) defined so that
> two things can make calls to arbitrary callback functions on the other
> end of a connection). How ports are wired up is a property of the
> machine model, not a property of the device at either end

But in practice you tend to have tree-like relationships.  Even if it is 
just a two-level tree with a GPIO chip or interrupt controller at one 
end, and everything else at the other.

> Also, you want to be able to actually name your output pins, so
> at a board level you can talk about wiring up sd_controller.wprot,
> not sd_controller.gpio[3]... (Yes, this is to some extent "just syntax"
> but I really don't want to end up with machine level modelling looking
> like:

It _is_ really just syntax.  In my examples I used the raw values for 
GPIO pin numbers because that's what we have.  So, right now there is no 
way to use symbolic values, but nothing forbids adding one.  Or even 
automatically generating the QEMU .conf from something else.

If you are using C code, of course you have #defines/enums.

> > Well, it is clear that buses should be modelled after the way data flows.
> > But what is data?  If data is "what is being written", buses should be
> > modelled after the way memory transactions flow.  If data is "what is being
> > made available", buses are modelled more "after the way interrupts flow.
> > GPIO is a strange thing in the middle. :)
>
> Actually I think we should really be modelling buses only where the
> hardware actually has a bus, ie a coherent collection of signals
> between multiple devices such that you could in theory plug in
> different devices in different slots. The memory transaction
> related connections are much more buslike than interrupt wiring.

I'm not sure, perhaps the naming is bad.  Abstracting from the name for 
a moment, unifying interrupts/GPIO with the qbus concept seemed natural 
to me in most of the cases I looked at.  And it makes the handling of 
GPIO in qdev less schizophrenic; qdev seems to treat the qbus (whatever 
it is) as the One True Mechanism to join devices, and then adds GPIO on 
the side while providing no way to configure it.  If you try to match 
the qdev tree with the tree of qemu_irq, the design becomes a lot more 
coherent.

Paolo