Re: Cleaning up contrib/ and tools/

[Pierrick Bouvier <pierrick.bouvier@linaro.org>]

On 3/24/26 10:09 AM, Peter Maydell wrote:
> We have a couple of directories in our source tree which have
> accumulated things in them that don't really belong there; this is a
> proposal to clean up by moving things to more appropriate locations
> (as 11.1 work, obviously).
> 
> Firstly, contrib/ has a tendency to be a dumping ground for stuff that
> we didn't think hard enough about finding a good home for, and for
> things in a weird "not really maintained" state. We should either
> (a) care enough about something to give it a correct home and to
> maintain it, or (b) not care about it, and kick it out of our tree.
> 
> Secondly, tools/ exists but is very under-used. I think it should be
> for the set of standalone tools that we build if you configure
> --enable-tools and which we document in docs/tools.  Currently it
> contains two things, one of which doesn't match that idea...
> 
> So, starting with tools/:
> 
>   * tools/ebpf/ is the source for the pre-generated
>     ebpf/rss.bpf.skeleton.h ; it should move to ebpf/
>   * tools/i386/qemu-vmsr-helper.c is the source for the
>     qemu-vmsr-helper tool; it can stay (should it lose its
>     i386/ subdir ?)
>   * the tools which currently are in the top level directory
>     should move into tools/:
>      - qemu-bridge-helper.c
>      - qemu-edid.c
>      - qemu-img.c
>      - qemu-io.c
>      - qemu-keymap.c
>      - qemu-nbd.c
> 
> And for contrib/, easy ones first:
>   * contrib/vhost-user-{blk,bridge,gpu,input,scsi} move to tools/
>   * contrib/elf2dmp moves to tools/
>   * contrib/ivshmem-client and contrib/ivshmem-server move to tools/
>   * contrib/plugins moves to plugins/plugins (or a different subdir
>     name of your choice)
>

I would suggest plugins/contrib or plugins/community, to make clear they 
are the community contributed ones.
@Alex, do you have a different suggestion/preference?

Moving those sources will break build folder hierarchy also, which is an 
issue for all existing binaries built from contrib anyway.
I'm not sure there is anything sane to do to fix that except accepting 
the breaking change.

> For contrib/, ones I'm less sure about:
> 
>   * contrib/vmapple/uuid.sh is a one-liner; we should either commit to
>     having this, by giving it a better name and documentation and
>     installing it in 'make install', or else junk it and have
>     docs/system/arm/vmapple.rst give you the plutil command and tell
>     you to run it directly.
>   * contrib/gitdm moves to scripts/ ? It's just config data for
>     generating statistics about patches, so with other
>     developer-related stuff makes sense.
>   * contrib/systemd -- we don't do anything with these (e.g.
>     'make install' ignores them), so I am sceptical about their
>     usefulness. We could drop them, or move them to scripts/, or put
>     them in tools/ and qga/ with the tools that they are systemd
>     scripts for.
> 
> Then we can delete contrib/ entirely.
> 
> (scripts/ is also in danger of being "miscellaneous dumping
> ground", of course. I have tried not to suggest it as the
> destination when I could think of an alternative.)
> 
> -- PMM

Regards,
Pierrick