Philippe Mathieu-Daudé <phi...@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é <phi...@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.
