qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH v3 00/11] hw: Strengthen SysBus & QBus API
Date: Fri, 11 Oct 2024 19:11:18 -0300
User-agent: Mozilla Thunderbird

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]