Re: Cleaning up contrib/ and tools/

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Mar 24, 2026 at 05:09:33PM +0000, Peter Maydell wrote:
> 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 ?)

Given it is a single source file and we don't have a big
collection of other i386-only tools, I think we loose
nothing by removing the extra 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

ack

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

plugins/demos or plugins/examples or are they more formal than
demo-ware ?

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

Earlier versions of the vmapple patch series had the command
listed in the rst docs, but it was then pulled out into the
script to make it easier for users.

Rename to qemu-vmapple-extract-uuid  or something less verbose ?

>  * contrib/gitdm moves to scripts/ ? It's just config data for
>    generating statistics about patches, so with other
>    developer-related stuff makes sense.

Yes, scripts seems reasonable for that.

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

I think they should probably move to the respective dir
that contains the tool source, and be installed.

The qga one differs from what Fedora ships, but by adding
them as installed files, we likely motivate someone to
care more about what they contain.

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

One problem at a time :-) Unlike contrib/, scripts/ is not end-user
facing it is just a grab bag of tools targetted at QEMU contributors
or the build system. So those only need to stay working & supported
to the extent that we're using them ourselves.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|