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)
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.
