On 4/6/24 15:32, Peter Maydell wrote:
On Fri, 31 May 2024 at 16:17, Philippe Mathieu-Daudé <phi...@linaro.org> wrote:

Hi Peter,

On 31/5/24 16:21, Peter Maydell wrote:

If there are any other changes we want to make to our component
regexes, now would be a great time to suggest them, because this
change is going to involve "delete every existing component and
recreate"...
---
   scripts/coverity-scan/COMPONENTS.md | 104 ++++++++++++++--------------
   1 file changed, 52 insertions(+), 52 deletions(-)


diff --git a/scripts/coverity-scan/COMPONENTS.md 
b/scripts/coverity-scan/COMPONENTS.md
index 1537e49cd5a..98d4bcd6a50 100644
--- a/scripts/coverity-scan/COMPONENTS.md
+++ b/scripts/coverity-scan/COMPONENTS.md
@@ -1,157 +1,157 @@
   This is the list of currently configured Coverity components:


   block
-  ~ 
(/qemu)?(/block.*|(/include?)/(block|storage-daemon)/.*|(/include)?/hw/(block|ide|nvme)/.*|/qemu-(img|io).*|/util/(aio|async|thread-pool).*)
+  ~ 
.*/qemu(/block.*|(/include?)/(block|storage-daemon)/.*|(/include)?/hw/(block|ide|nvme)/.*|/qemu-(img|io).*|/util/(aio|async|thread-pool).*)

util/block-helpers.[ch]

I'd put hw/block/ to another bucket that the block subsystem.

MAINTAINERS considers both block/ and hw/block/ to be part of the
"block layer core".

Personally I'd look at hw/block/ issues and skip block/ ones :P

   disas
-  ~ (/qemu)?((/include)?/disas.*)
+  ~ .*/qemu((/include)?/disas.*)

Missing:

target/avr/disas.c
target/loongarch/disas.c
target/openrisc/disas.c
target/rx/disas.c

Why do these targets not put their disassembler in disas/
like all the others? We can't really catch them with a
wildcard, because the target entry earlier will match first.
I'm kind of inclined to leave these as-is, because if
somebody put the disassembler in target/ then having it
appear in the component for that target is fine for it being
basically classified to get the attention of the right person.

disas/ is for non-decodetree disassemblers imported from
BFD library. Decodetree based belong to each target/foo/.
So I agree keeping as-is is OK.

Regards,

Phil.

Reply via email to