Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> writes:
> On 05/01/2024 10: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 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?"
>
> For the moment I would definitely say no, and that is mainly because if we
> were to assume that QOM paths were stable today then I can see it being a
> barrier to updating older code to meet our current guidelines.
>
> These days I think more about QOM paths being related to the lifecycle of the
> objects e.g. a machine object has child devices, which may also consist of a
> number of other children in the case of a multi-function device. For me this
> means that using object_resolve_path_component() to look up a child object
> seems reasonable, in contrast with expecting the entire path to be stable.
>
> One thing I think about often is whether the use of device[n] is suitable
> within QOM tree. For example, if I have a command line like:
>
> -device foo,myprop=prop0,id=fooid0 -device foo,myprop=prop1,id=fooid1
>
> currently they would appear in "info qom-tree" as:
>
> /machine
> /unattached
> /device[0] (foo)
> /device[1] (foo)
Actually
/machine
/peripheral (container)
/fooid0 (foo
/fooid1 (foo)
If you omit id=..., you get
/machine
/peripheral-anon (container)
/device[2] (usb-mouse)
/device[3] (usb-mouse)
or similar; the actual numbers in [brackets] depend on the board.
> whereas it feels this could be done better as:
>
> /machine
> /unattached
> /foo[0] (fooid0)
> /foo[1] (fooid1)
>
> This would automatically place devices of the same type within a QOM array to
> allow them to be accessed separately by type, or even directly via the "id"
> if we assume they are unique. In particular if you have a machine with 2 foo
> in-built devices you could then potentially configure them separately using
> -global foo[0].myprop=newprop0 and/or -global foo[1].myprop=newprop1 which is
> something that currently isn't possible.
>
>
> ATB,
>
> Mark.
