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

[Mark Cave-Ayland]

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)

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.