[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 2/3] tests/qtest: Add STM32L4x5 EXTI QTest testcase
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH v5 2/3] tests/qtest: Add STM32L4x5 EXTI QTest testcase |
Date: |
Fri, 5 Jan 2024 10:24:15 +0000 |
User-agent: |
Mutt/2.2.10 (2023-03-25) |
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.
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.
None the less, you may still choose to move it out of /unattached
at your discretion.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Re: [PATCH v5 2/3] tests/qtest: Add STM32L4x5 EXTI QTest testcase, Philippe Mathieu-Daudé, 2024/01/04