Re: [PATCH v3 00/11] hw: Strengthen SysBus & QBus API

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

On 11/10/24 05:56, Paolo Bonzini wrote:
> On 2/8/24 19:12, Philippe Mathieu-Daudé wrote:
>> Hi,
>>
>> This series ensure following is called *before* a
>> device is realized:
>> - qbus_new()
>> - sysbus_init_mmio()
>> - qdev_init_gpio_in_named_with_opaque()
>>
>> and these are called *after* it is:
>> - sysbus_mmio_map()
>> - sysbus_connect_irq(),
>> - qdev_connect_gpio_out()
>> - qdev_connect_gpio_out_named()
> 
> This series is missing a _why_.  The original vision for qdev was that 
> the whole machine would be realized at once from vl.c, and therefore 
> there would be no need for realizing subcomponents by hand.
> 
> This probably will never happen, but it is still worth explaining why 
> it's now considered so conceptually wrong, that it is (or will be) 
> enforced by the API.

When looking at a roadmap toward "dynamic machines" with Markus we
needed to clarify the QOM life cycle before thinking about possible
DSL to declare machines and components. See:

= Problem 4: The /machine/unattached/ orphanage =
= Problem 5: QOM lacks a clear life cycle =
= Problem 7: Design of the machine specification DSL =
in https://lore.kernel.org/qemu-devel/87o7d1i7ky.fsf@pond.sub.org/,
in particular:

     '''
     We need to manage a state transition from "object created,
     but not ready for use" to "object configured and ready for
     use".  In what order do the objects change state?
     '''

and:

     '''
     Ideally, a composite object's components go through the life
     cycle together.  First, create all the components and assign
     parents.  This also creates all the properties.  Then configure
     the object by setting property values.  Finally, complete / realize
     all components.
     '''

We need a better QOM documentation, "Device Life-cycle" in
docs/devel/qom.rst doesn't reallyr describe the life cycle, and
doesn't mention the "realization" API contract.
Since you have more experience and historical view on the APIs,
I wouldn't mind if you want to clarify that; otherwise I'll try
to do it.

Regards,

Phil.


> Paolo