Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2011-06-09 18:40, Markus Armbruster wrote:
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
>> On 2011-06-08 13:33, Peter Maydell wrote:
>>> At the moment you can't really implement one sysbus device by saying
>>> that it's composed of a set of other sysbus devices. This patch adds
>>> new functions sysbus_pass_mmio() and sysbus_pass_one_irq() which
>>> allow a sysbus device to delegate an MMIO or IRQ to another sysbus
>>> device (The approach is inspired by the existing sysbus_pass_irq()
>>> which lets a sysbus device delegate all its IRQs at once).
>>>
>>> This works; the most obvious deficiency is that the subcomponent
>>> device will still appear as its own device on the bus.
>>>
>>> So: is this a reasonable solution to the problem, or an unacceptable
>>> hack? Comments welcome :-)
>>
>> Sounds more like a little hack. :)
>>
>> The relationships should be expressed via qdev, not yet another
>> sysbus-specific extension. Generally, many services of sysbus should
>> rather be generic qdev things.
> 
> Examples?

Resource management, e.g. IRQs. That will be useful for other types of
buses as well.

> 
>> Is there anything that today prevents creating a local bus and attaching
>> the component devices to that? If it's multi-bus support, that should to
>> be added anyway. Passing-through of MMIO and IRQs is still a worthwhile
>> generic service, then probably qbus associated.
> 
> Do you mean making the container device a sysbus-sysbus-bridge, then
> hanging the component devices off the inner sysbus?

And how to apply this concept on a composed PCI device e.g.?

Maybe we could define something like Linux' struct resource + a set of
helper services for it.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux