On Tue, Mar 24, 2026 at 7:09 PM 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) > > 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. > Not sure that we need qemu-guest-agent.service at all. Fedora/CentOS don't use it and create a different service file. I think this one can be dropped. Best Regards, Kostiantyn Kostiuk. > > 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 > >