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

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

On 5/1/24 11:24, Daniel P. Berrangé wrote:
> On Thu, Jan 04, 2024 at 01:37:22PM +0000, 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" ?
> 
> QTest is a functional test harness that intentionally has knowledge
> about QEMU internals.
> 
> IOW, usage of particular QOM path in qtest does *not* imply that
> QOM path needs to be stable.  If QEMU internals change for whatever
> reason, it is expected that QTests may need some updates to match.

Good point.

> QOM path stability only matters if there's a mgmt app facing use
> case, which requires the app to have hardcoded knowledge of the
> path.
> 
> Even a mgmt app can use unstable QOM paths, provided it has a way
> to dynamically detect the path to be used, instead of hardcoding
> it.

I can understand this use to lookup "on which CDROM tray is
inserted the blkdrv named FOO", but to find a component on a
well specified system on chip, this is overkill.

> None the less, you may still choose to move it out of /unattached
> at your discretion.

Yeah we should clean those...

Thanks for clarifying,

Phil.