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=rfOSZQA@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.

thanks
-- PMM


Peter Maydell (9):
  ebpf: move ebpf skeleton source to ebpf/ directory
  tools: Move qemu-bridge-helper sources to tools/ directory
  tools: Move qemu-edid sources to tools/ directory
  tools: Move qemu-img sources to tools/ directory
  tools: Move qemu-io sources to tools/ directory
  tools: Move qemu-nbd sources to tools/ directory
  tools: Move qemu-keymap sources to tools/ directory
  tools: Move qemu-vmsr-helper up a directory level
  tools: Move elf2dmp from contrib/ to tools/

 MAINTAINERS                                   | 15 +++++++-------
 docs/tools/qemu-img.rst                       |  2 +-
 {tools/ebpf => ebpf/bpf-src}/Makefile.ebpf    |  2 +-
 {tools/ebpf => ebpf/bpf-src}/rss.bpf.c        |  0
 meson.build                                   | 20 +++++++++----------
 {contrib => tools}/elf2dmp/addrspace.c        |  0
 {contrib => tools}/elf2dmp/addrspace.h        |  0
 {contrib => tools}/elf2dmp/download.c         |  0
 {contrib => tools}/elf2dmp/download.h         |  0
 {contrib => tools}/elf2dmp/err.h              |  0
 {contrib => tools}/elf2dmp/kdbg.h             |  0
 {contrib => tools}/elf2dmp/main.c             |  0
 {contrib => tools}/elf2dmp/meson.build        |  0
 {contrib => tools}/elf2dmp/pdb.c              |  0
 {contrib => tools}/elf2dmp/pdb.h              |  0
 {contrib => tools}/elf2dmp/pe.h               |  0
 {contrib => tools}/elf2dmp/qemu_elf.c         |  0
 {contrib => tools}/elf2dmp/qemu_elf.h         |  0
 .../qemu-bridge-helper.c                      |  0
 qemu-edid.c => tools/qemu-edid.c              |  0
 qemu-img-cmds.hx => tools/qemu-img-cmds.hx    |  0
 qemu-img.c => tools/qemu-img.c                |  0
 qemu-io-cmds.c => tools/qemu-io-cmds.c        |  0
 qemu-io.c => tools/qemu-io.c                  |  0
 qemu-keymap.c => tools/qemu-keymap.c          |  0
 qemu-nbd.c => tools/qemu-nbd.c                |  0
 tools/{i386 => }/qemu-vmsr-helper.c           |  0
 tools/{i386 => }/rapl-msr-index.h             |  0
 28 files changed, 20 insertions(+), 19 deletions(-)
 rename {tools/ebpf => ebpf/bpf-src}/Makefile.ebpf (96%)
 rename {tools/ebpf => ebpf/bpf-src}/rss.bpf.c (100%)
 rename {contrib => tools}/elf2dmp/addrspace.c (100%)
 rename {contrib => tools}/elf2dmp/addrspace.h (100%)
 rename {contrib => tools}/elf2dmp/download.c (100%)
 rename {contrib => tools}/elf2dmp/download.h (100%)
 rename {contrib => tools}/elf2dmp/err.h (100%)
 rename {contrib => tools}/elf2dmp/kdbg.h (100%)
 rename {contrib => tools}/elf2dmp/main.c (100%)
 rename {contrib => tools}/elf2dmp/meson.build (100%)
 rename {contrib => tools}/elf2dmp/pdb.c (100%)
 rename {contrib => tools}/elf2dmp/pdb.h (100%)
 rename {contrib => tools}/elf2dmp/pe.h (100%)
 rename {contrib => tools}/elf2dmp/qemu_elf.c (100%)
 rename {contrib => tools}/elf2dmp/qemu_elf.h (100%)
 rename qemu-bridge-helper.c => tools/qemu-bridge-helper.c (100%)
 rename qemu-edid.c => tools/qemu-edid.c (100%)
 rename qemu-img-cmds.hx => tools/qemu-img-cmds.hx (100%)
 rename qemu-img.c => tools/qemu-img.c (100%)
 rename qemu-io-cmds.c => tools/qemu-io-cmds.c (100%)
 rename qemu-io.c => tools/qemu-io.c (100%)
 rename qemu-keymap.c => tools/qemu-keymap.c (100%)
 rename qemu-nbd.c => tools/qemu-nbd.c (100%)
 rename tools/{i386 => }/qemu-vmsr-helper.c (100%)
 rename tools/{i386 => }/rapl-msr-index.h (100%)

-- 
2.43.0

On 5/8/2026 8:24 AM, Peter Maydell wrote:
> 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=rfOSZQA@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.
> 
> thanks
> -- PMM
> 
> 
> Peter Maydell (9):
>   ebpf: move ebpf skeleton source to ebpf/ directory
>   tools: Move qemu-bridge-helper sources to tools/ directory
>   tools: Move qemu-edid sources to tools/ directory
>   tools: Move qemu-img sources to tools/ directory
>   tools: Move qemu-io sources to tools/ directory
>   tools: Move qemu-nbd sources to tools/ directory
>   tools: Move qemu-keymap sources to tools/ directory
>   tools: Move qemu-vmsr-helper up a directory level
>   tools: Move elf2dmp from contrib/ to tools/
> 
>  MAINTAINERS                                   | 15 +++++++-------
>  docs/tools/qemu-img.rst                       |  2 +-
>  {tools/ebpf => ebpf/bpf-src}/Makefile.ebpf    |  2 +-
>  {tools/ebpf => ebpf/bpf-src}/rss.bpf.c        |  0
>  meson.build                                   | 20 +++++++++----------
>  {contrib => tools}/elf2dmp/addrspace.c        |  0
>  {contrib => tools}/elf2dmp/addrspace.h        |  0
>  {contrib => tools}/elf2dmp/download.c         |  0
>  {contrib => tools}/elf2dmp/download.h         |  0
>  {contrib => tools}/elf2dmp/err.h              |  0
>  {contrib => tools}/elf2dmp/kdbg.h             |  0
>  {contrib => tools}/elf2dmp/main.c             |  0
>  {contrib => tools}/elf2dmp/meson.build        |  0
>  {contrib => tools}/elf2dmp/pdb.c              |  0
>  {contrib => tools}/elf2dmp/pdb.h              |  0
>  {contrib => tools}/elf2dmp/pe.h               |  0
>  {contrib => tools}/elf2dmp/qemu_elf.c         |  0
>  {contrib => tools}/elf2dmp/qemu_elf.h         |  0
>  .../qemu-bridge-helper.c                      |  0
>  qemu-edid.c => tools/qemu-edid.c              |  0
>  qemu-img-cmds.hx => tools/qemu-img-cmds.hx    |  0
>  qemu-img.c => tools/qemu-img.c                |  0
>  qemu-io-cmds.c => tools/qemu-io-cmds.c        |  0
>  qemu-io.c => tools/qemu-io.c                  |  0
>  qemu-keymap.c => tools/qemu-keymap.c          |  0
>  qemu-nbd.c => tools/qemu-nbd.c                |  0
>  tools/{i386 => }/qemu-vmsr-helper.c           |  0
>  tools/{i386 => }/rapl-msr-index.h             |  0
>  28 files changed, 20 insertions(+), 19 deletions(-)
>  rename {tools/ebpf => ebpf/bpf-src}/Makefile.ebpf (96%)
>  rename {tools/ebpf => ebpf/bpf-src}/rss.bpf.c (100%)
>  rename {contrib => tools}/elf2dmp/addrspace.c (100%)
>  rename {contrib => tools}/elf2dmp/addrspace.h (100%)
>  rename {contrib => tools}/elf2dmp/download.c (100%)
>  rename {contrib => tools}/elf2dmp/download.h (100%)
>  rename {contrib => tools}/elf2dmp/err.h (100%)
>  rename {contrib => tools}/elf2dmp/kdbg.h (100%)
>  rename {contrib => tools}/elf2dmp/main.c (100%)
>  rename {contrib => tools}/elf2dmp/meson.build (100%)
>  rename {contrib => tools}/elf2dmp/pdb.c (100%)
>  rename {contrib => tools}/elf2dmp/pdb.h (100%)
>  rename {contrib => tools}/elf2dmp/pe.h (100%)
>  rename {contrib => tools}/elf2dmp/qemu_elf.c (100%)
>  rename {contrib => tools}/elf2dmp/qemu_elf.h (100%)
>  rename qemu-bridge-helper.c => tools/qemu-bridge-helper.c (100%)
>  rename qemu-edid.c => tools/qemu-edid.c (100%)
>  rename qemu-img-cmds.hx => tools/qemu-img-cmds.hx (100%)
>  rename qemu-img.c => tools/qemu-img.c (100%)
>  rename qemu-io-cmds.c => tools/qemu-io-cmds.c (100%)
>  rename qemu-io.c => tools/qemu-io.c (100%)
>  rename qemu-keymap.c => tools/qemu-keymap.c (100%)
>  rename qemu-nbd.c => tools/qemu-nbd.c (100%)
>  rename tools/{i386 => }/qemu-vmsr-helper.c (100%)
>  rename tools/{i386 => }/rapl-msr-index.h (100%)
> 

As well, feel free to send a patches for contrib/plugins, moving them to
plugins/plugins as you offered first.
We didn't find a better alternative, and it does not really matters to
be honest. You have my reviewed-by.

Regards,
Pierrick

On 5/8/2026 8:24 AM, Peter Maydell wrote:
> 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=rfOSZQA@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.
>

It's a deliberate design more than an annoyance. It pushes users to make
things explicit at top level, which is good to understand what is built
and how, and hide details in subdirs in variables. QEMU's top level
meson.build is over complex, so it may appear more as a burden than a
benefit though.

> thanks
> -- PMM
> 
> 
> Peter Maydell (9):
>   ebpf: move ebpf skeleton source to ebpf/ directory
>   tools: Move qemu-bridge-helper sources to tools/ directory
>   tools: Move qemu-edid sources to tools/ directory
>   tools: Move qemu-img sources to tools/ directory
>   tools: Move qemu-io sources to tools/ directory
>   tools: Move qemu-nbd sources to tools/ directory
>   tools: Move qemu-keymap sources to tools/ directory
>   tools: Move qemu-vmsr-helper up a directory level
>   tools: Move elf2dmp from contrib/ to tools/
> 
>  MAINTAINERS                                   | 15 +++++++-------
>  docs/tools/qemu-img.rst                       |  2 +-
>  {tools/ebpf => ebpf/bpf-src}/Makefile.ebpf    |  2 +-
>  {tools/ebpf => ebpf/bpf-src}/rss.bpf.c        |  0
>  meson.build                                   | 20 +++++++++----------
>  {contrib => tools}/elf2dmp/addrspace.c        |  0
>  {contrib => tools}/elf2dmp/addrspace.h        |  0
>  {contrib => tools}/elf2dmp/download.c         |  0
>  {contrib => tools}/elf2dmp/download.h         |  0
>  {contrib => tools}/elf2dmp/err.h              |  0
>  {contrib => tools}/elf2dmp/kdbg.h             |  0
>  {contrib => tools}/elf2dmp/main.c             |  0
>  {contrib => tools}/elf2dmp/meson.build        |  0
>  {contrib => tools}/elf2dmp/pdb.c              |  0
>  {contrib => tools}/elf2dmp/pdb.h              |  0
>  {contrib => tools}/elf2dmp/pe.h               |  0
>  {contrib => tools}/elf2dmp/qemu_elf.c         |  0
>  {contrib => tools}/elf2dmp/qemu_elf.h         |  0
>  .../qemu-bridge-helper.c                      |  0
>  qemu-edid.c => tools/qemu-edid.c              |  0
>  qemu-img-cmds.hx => tools/qemu-img-cmds.hx    |  0
>  qemu-img.c => tools/qemu-img.c                |  0
>  qemu-io-cmds.c => tools/qemu-io-cmds.c        |  0
>  qemu-io.c => tools/qemu-io.c                  |  0
>  qemu-keymap.c => tools/qemu-keymap.c          |  0
>  qemu-nbd.c => tools/qemu-nbd.c                |  0
>  tools/{i386 => }/qemu-vmsr-helper.c           |  0
>  tools/{i386 => }/rapl-msr-index.h             |  0
>  28 files changed, 20 insertions(+), 19 deletions(-)
>  rename {tools/ebpf => ebpf/bpf-src}/Makefile.ebpf (96%)
>  rename {tools/ebpf => ebpf/bpf-src}/rss.bpf.c (100%)
>  rename {contrib => tools}/elf2dmp/addrspace.c (100%)
>  rename {contrib => tools}/elf2dmp/addrspace.h (100%)
>  rename {contrib => tools}/elf2dmp/download.c (100%)
>  rename {contrib => tools}/elf2dmp/download.h (100%)
>  rename {contrib => tools}/elf2dmp/err.h (100%)
>  rename {contrib => tools}/elf2dmp/kdbg.h (100%)
>  rename {contrib => tools}/elf2dmp/main.c (100%)
>  rename {contrib => tools}/elf2dmp/meson.build (100%)
>  rename {contrib => tools}/elf2dmp/pdb.c (100%)
>  rename {contrib => tools}/elf2dmp/pdb.h (100%)
>  rename {contrib => tools}/elf2dmp/pe.h (100%)
>  rename {contrib => tools}/elf2dmp/qemu_elf.c (100%)
>  rename {contrib => tools}/elf2dmp/qemu_elf.h (100%)
>  rename qemu-bridge-helper.c => tools/qemu-bridge-helper.c (100%)
>  rename qemu-edid.c => tools/qemu-edid.c (100%)
>  rename qemu-img-cmds.hx => tools/qemu-img-cmds.hx (100%)
>  rename qemu-img.c => tools/qemu-img.c (100%)
>  rename qemu-io-cmds.c => tools/qemu-io-cmds.c (100%)
>  rename qemu-io.c => tools/qemu-io.c (100%)
>  rename qemu-keymap.c => tools/qemu-keymap.c (100%)
>  rename qemu-nbd.c => tools/qemu-nbd.c (100%)
>  rename tools/{i386 => }/qemu-vmsr-helper.c (100%)
>  rename tools/{i386 => }/rapl-msr-index.h (100%)
> 

For series:
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>

On Fri, 8 May 2026 at 17:00, Pierrick Bouvier
<pierrick.bouvier@oss.qualcomm.com> wrote:
>
> On 5/8/2026 8:24 AM, Peter Maydell wrote:
> > 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=rfOSZQA@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.
> >
>
> It's a deliberate design more than an annoyance. It pushes users to make
> things explicit at top level, which is good to understand what is built
> and how, and hide details in subdirs in variables. QEMU's top level
> meson.build is over complex, so it may appear more as a burden than a
> benefit though.

Personally I think if the build system doesn't let you do a
pretty normal and reasonable thing that's annoying. Meson
annoys me because it has a tendency to be over-opinionated.

-- PMM

Hi

On Fri, May 8, 2026 at 8:23 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Fri, 8 May 2026 at 17:00, Pierrick Bouvier
> <pierrick.bouvier@oss.qualcomm.com> wrote:
> >
> > On 5/8/2026 8:24 AM, Peter Maydell wrote:
> > > 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=rfOSZQA@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.
> > >
> >
> > It's a deliberate design more than an annoyance. It pushes users to make
> > things explicit at top level, which is good to understand what is built
> > and how, and hide details in subdirs in variables. QEMU's top level
> > meson.build is over complex, so it may appear more as a burden than a
> > benefit though.
>
> Personally I think if the build system doesn't let you do a
> pretty normal and reasonable thing that's annoying. Meson
> annoys me because it has a tendency to be over-opinionated.
>

I have to agree that meson is sometimes lacking. In this case, it
would be convenient to have a link created at build time. But you have
to resort to fairly annoying custom_target python code today. In the
meantime, there is also fs.copyfile() that could work (although it's
also somewhat limited or buggy). For later, we could try adding
fs.symlink() perhaps. Paolo might have better chances than me getting
it accepted ;)

-- 
Marc-André Lureau

On Mon, May 11, 2026 at 12:23:32AM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Fri, May 8, 2026 at 8:23 PM Peter Maydell <peter.maydell@linaro.org> wrote:
> >
> > On Fri, 8 May 2026 at 17:00, Pierrick Bouvier
> > <pierrick.bouvier@oss.qualcomm.com> wrote:
> > >
> > > On 5/8/2026 8:24 AM, Peter Maydell wrote:
> > > > 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=rfOSZQA@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.
> > > >
> > >
> > > It's a deliberate design more than an annoyance. It pushes users to make
> > > things explicit at top level, which is good to understand what is built
> > > and how, and hide details in subdirs in variables. QEMU's top level
> > > meson.build is over complex, so it may appear more as a burden than a
> > > benefit though.
> >
> > Personally I think if the build system doesn't let you do a
> > pretty normal and reasonable thing that's annoying. Meson
> > annoys me because it has a tendency to be over-opinionated.

Being opinionated is a double edge sword. A big part of the mess you
get with traditional build tools is that they are not opinionated so
every project ends up doing something slightly different and thus it
is harder to understand each project.  Being opinionated is what keeps
meson simpler to understand and learn, at the cost of loss of flexiblity.

Meson may not have the balance entirely right, but overall I think it
has been beneficial to be very opinionated, even if that means some
places needs to be relaxed over time.


> I have to agree that meson is sometimes lacking. In this case, it
> would be convenient to have a link created at build time. But you have
> to resort to fairly annoying custom_target python code today. In the
> meantime, there is also fs.copyfile() that could work (although it's
> also somewhat limited or buggy). For later, we could try adding
> fs.symlink() perhaps. Paolo might have better chances than me getting
> it accepted ;)

IIUC, the main reason to want binaries in a specific location is
so that tests find them in that location.  That is a valid historical
approach, but meson offer an alternative approach that could be used
instead.

We can set the test environment so that meson modifies $PATH such that
all the built binaries appear at head of $PATH. Tests then don't need
to assume a location for them in the build directory, just let execvp
search $PATH as normal.  For execution outside of 'meson test', we have
"meson devenv" which sets up a local interactive shell environment, or
we can launch the test via the "run" script which wraps "meson devenv"
for a single command.

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

On Mon, 11 May 2026 at 09:37, Daniel P. Berrangé <berrange@redhat.com> wrote:
> IIUC, the main reason to want binaries in a specific location is
> so that tests find them in that location.  That is a valid historical
> approach, but meson offer an alternative approach that could be used
> instead.

It's not the only reason, though. The other half is humans.
People do run QEMU and the tools out of the build directory quite
frequently, and so the location of the binaries in the build tree
shouldn't have to depend on where we put the tool sources in the
source tree or where we want to put the meson runes in the
meson.build files. Just as we prefer to have qemu-system-foo
in the top level of the build tree, I think it's also preferable
to put the qemu-bar tools binaries there. It's more consistent,
and they're easier to find.

> We can set the test environment so that meson modifies $PATH such that
> all the built binaries appear at head of $PATH. Tests then don't need
> to assume a location for them in the build directory, just let execvp
> search $PATH as normal.  For execution outside of 'meson test', we have
> "meson devenv" which sets up a local interactive shell environment, or
> we can launch the test via the "run" script which wraps "meson devenv"
> for a single command.

I definitely don't want to have to run a separate command to
set up an environment: this is painful whenever I have to
interact with python venvs, and it's not something I think
we want or need here.

I think the least-worst option is that we say "all the
meson runes for building executables must live in the
top level meson.build even if the sources and most of
the meson runes for the source/object files are in a
subdirectory".

thanks
-- PMM

On 5/11/2026 2:27 AM, Peter Maydell wrote:
> On Mon, 11 May 2026 at 09:37, Daniel P. Berrangé <berrange@redhat.com> wrote:
>> IIUC, the main reason to want binaries in a specific location is
>> so that tests find them in that location.  That is a valid historical
>> approach, but meson offer an alternative approach that could be used
>> instead.
> 
> It's not the only reason, though. The other half is humans.
> People do run QEMU and the tools out of the build directory quite
> frequently, and so the location of the binaries in the build tree
> shouldn't have to depend on where we put the tool sources in the
> source tree or where we want to put the meson runes in the
> meson.build files. Just as we prefer to have qemu-system-foo
> in the top level of the build tree, I think it's also preferable
> to put the qemu-bar tools binaries there. It's more consistent,
> and they're easier to find.
> 
>> We can set the test environment so that meson modifies $PATH such that
>> all the built binaries appear at head of $PATH. Tests then don't need
>> to assume a location for them in the build directory, just let execvp
>> search $PATH as normal.  For execution outside of 'meson test', we have
>> "meson devenv" which sets up a local interactive shell environment, or
>> we can launch the test via the "run" script which wraps "meson devenv"
>> for a single command.
> 
> I definitely don't want to have to run a separate command to
> set up an environment: this is painful whenever I have to
> interact with python venvs, and it's not something I think
> we want or need here.
>

I agree, this kind of "source my_env" are really not convenient to work
with. Better to have things in the correct place instead.

> I think the least-worst option is that we say "all the
> meson runes for building executables must live in the
> top level meson.build even if the sources and most of
> the meson runes for the source/object files are in a
> subdirectory".
>

Which is the way meson devs expect you to write it. For people looking
for the definition of those executable, they can expect, without any
surprise, that definition will be in top level meson.build.
From there, it's easy to see which sources var it uses and where it's
declared.

> thanks
> -- PMM

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=rfOSZQA@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

On Mon, 11 May 2026 at 10:05, Kevin Wolf <kwolf@redhat.com> wrote:
>
> 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=rfOSZQA@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.

Yes, moving qemu-storage-daemon would probably also be a good idea.
This patchset is just starting with some of the easy stuff where
I was pretty sure the move was correct.

-- PMM