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é <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" ?
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.
