Am 08.05.2026 um 17:24 hat Peter Maydell geschrieben: > We have a set of binaries that we call "tools": they're built based on > the --enable-tools/--disable-tools configure setting, they're > documented in docs/tools, and they're standalone executables of one > form or another. > > Currently the sources for these are a bit scattered: many still in the > top level source directory, some in contrib, one or two actually in > the tools directory. > > As an initial attempt at cleanup, this patchset moves the sources for > qemu-bridge-helper, qemu-edid, qemu-img, qemu-io, qemu-nbd, > qemu-keymap, qemu-vmsr-helper and elf2dmp into the tools/ directory. > > The patchseries also moves the ebfp skeleton sources from tools/ebpf/ > to ebpf/bpf-src/, because this isn't a tool by the above definition. > > As per my thread from a while back, I would ultimately like us to > clean up contrib/: > https://lore.kernel.org/qemu-devel/CAFEAcA_5HvGriDsWnb1ALuA_dgG320eKv7yuM2kThv=rfos...@mail.gmail.com/ > But parts of that clearly need more discussion. So this is just doing > some parts that I hope are not controversial. > > Annoyingly, meson doesn't seem to provide any way for a subdirectory > meson.build to say "the foo.c in this subdir builds into a foo > executable that lives at the top level of the builddir". And we have a > lot of test harness stuff plus user muscle memory that assumes that > qemu-img and qemu-io live there. So the build runes for these tools > have to stay in the top level meson.build (and tools/meson.build > remains an empty file). The exception is that contrib/elf2dmp/elf2dmp > is now tools/elf2dmp/elf2dmp, but I think the set of people who were > running that from the build directory will be small.
Should qemu-storage-daemon be moved as well? I never particularly liked the storage-daemon/ directory that Paolo created in 7c58bb76 and that singled qemu-storage-daemon out among the tools. If the binary could move whereever all the other tools live, too, that would be even better. Kevin
