qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH not-for-merge 0/5] Instrumentation for "Fixes around device r


From: Mark Cave-Ayland
Subject: Re: [PATCH not-for-merge 0/5] Instrumentation for "Fixes around device realization"
Date: Mon, 18 May 2020 21:56:12 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

On 18/05/2020 06:19, Markus Armbruster wrote:

> This is the instrumentation mentioned in "[PATCH 00/24] Fixes around
> device realization".
> 
> PATCH 2/5 might have value on its own.  You tell me.
> 
> Shell script to smoke-test all machines:
> 
> #!/bin/sh
> success=0
> fail=0
> ulimit -c 0
> git-describe --dirty --match v\*
> git-log --oneline -1
> for i in bld/*-softmmu
> do
>     t=${i%-softmmu}
>     t=${t##*/}
>     q=$i/qemu-system-$t
>     echo "= $t ="
> 
>     for m in `$q -M help | sed -n '/(alias of/d;2,$s/ .*//p'`
>     do
>       echo "== $m =="
>       echo -e 'info qom-tree\ninfo qtree\nq' | $q -S -accel qtest -display 
> none -L smoke-mon-roms -M $m -monitor stdio
>       if [ $? -eq 0 ]
>       then echo "*** Success: $m ***"; let success++
>       else echo "*** Fail: $m"; let fail++
>       fi
>     done
> done
> echo $success succeeded, $fail failed
> 
> 
> Markus Armbruster (5):
>   qom: Instrument to detect missed realize
>   qom: Make "info qom-tree" show children sorted
>   qdev: Make "info qtree" show child devices sorted by QOM path
>   qdev: Instrument to detect missed QOM parenting
>   qdev: Instrument to detect bus mismatch
> 
>  hw/core/qdev.c     | 17 ++++++++++++++++
>  qdev-monitor.c     | 32 ++++++++++++++++++++++++++++-
>  qom/qom-hmp-cmds.c | 51 +++++++++++++++++++++++++++++++++++++++++++++-
>  3 files changed, 98 insertions(+), 2 deletions(-)

Thanks for sharing these patches! I certainly think that they have value and 
after a
quick read through I'm thinking:

- Patch 1 I assume is no longer needed once you previous series is merged

- Patches 2 & 3 would be really useful at the start of your previous series (as
someone who has gone crossed-eyed enough trying to spot these differences, this 
is
really helpful)

- Patches 4 and 5 are good sanity checks for developers but I'm wondering what 
is the
extent of work that needs to be done? Could existing failures be whitelisted 
with the
aim of removal which would then at least prevent new devices being added that 
aren't
correct?


ATB,

Mark.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]