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

[Markus Armbruster]

Mark Cave-Ayland <mark.cave-ayland@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é <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 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.