Re: [PATCH v5 2/3] tests/qtest: Add STM32L4x5 EXTI QTest testcase

[Markus Armbruster <armbru@redhat.com>]

Philippe Mathieu-Daudé <philmd@linaro.org> writes:

> On 5/1/24 11:13, Philippe Mathieu-Daudé wrote:
>> (+Mark & Eduardo)
>> On 4/1/24 14:37, inesvarhol wrote:
>>>
>>> Le jeudi 4 janvier 2024 à 14:05, Philippe Mathieu-Daudé <philmd@linaro.org> a écrit :
>>>
>>> Hello,
>>>
>>>>> +static void test_edge_selector(void)
>>>>> +{
>>>>> + enable_nvic_irq(EXTI0_IRQ);
>>>>> +
>>>>> + / Configure EXTI line 0 irq on rising edge */
>>>>> + qtest_set_irq_in(global_qtest, "/machine/unattached/device[0]/exti",
>>>>
>>>>
>>>> Markus, this qtest use seems to expect some stability in QOM path...
>>>>
>>>> Inès, Arnaud, having the SoC unattached is dubious, it belongs to
>>>> the machine.
>>>
>>> Noted, we will fix that.
>>> Should we be concerned about the "stability in QOM path" ?
>>
>> Don't worry about this Inès, I wanted to raise Markus attention on this.
>>
>> You showed a legit use of stable QOM path, and Markus told me recently
>> there is no contract for QOM paths (it shouldn't be considered as a
>> stable API). IIRC Markus explanation, "/unattached" container was
>> added as a temporary hack to allow migrating QDev objects to QOM (see
>> around commit da57febfed "qdev: give all devices a canonical path",
>> 11 years ago).

I'm not sure the hack was intended to be temporary.  Doesn't matter now.

The connection between parent and child is a child property of the
parent.  Like all properties, it has a name.  These names are the
components of the canonical path.

When the code that creates the child makes the connection, it can give
the property a sensible name.

When it doesn't, we sometimes do it in generic code, using the
/machine/unattached orphanage, and a name that contains a counter, like

    /machine/unattached/device[N]
    /machine/unattached/non-qdev-gpio[N]

The actual name depends on execution order, because the counter value
does.  Brittle.

> Hmm am I getting confused with "/peripheral-anon" (commit 8eb02831af
> "dev: add an anonymous peripheral container")?

Not the same, but related.  Devices added with -device / device_add go
into /machine/peripheral/ID when they have id=ID, else into
/machine/peripheral/anon/device[N].  Before the commit you quoted, the
latter were orphaned I believe.

>> I agree anything under "/unattached" can be expected to be stable
>> (but we need a community consensus). Then the big question remaining
>> is "can any qom-path out of /unattached be considered stable?"

Backwards?  Keeping /machine/unattached/FOO[N] stable is harder then the
paths the code picks explicitly.