| Message ID | 20210204135425.1380280-1-wainersm@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] MAINTAINERS: Fix the location of tools manuals | expand |
On 2/4/21 2:54 PM, Wainer dos Santos Moschetta wrote: > The qemu-img.rst, qemu-nbd.rst, virtfs-proxy-helper.rst, qemu-trace-stap.rst, > and virtiofsd.rst manuals were moved to docs/tools, so this update MAINTAINERS > accordingly. > > Fixes: a08b4a9fe6c ("docs: Move tools documentation to tools manual") > Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com> > --- > v1: was "MAINTAINERS: Fix the location of virtiofsd.rst" > v2: Fixed the location of all files [philmd] > > MAINTAINERS | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 00626941f1..174425a941 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1829,7 +1829,7 @@ S: Odd Fixes > F: hw/9pfs/ > X: hw/9pfs/xen-9p* > F: fsdev/ > -F: docs/interop/virtfs-proxy-helper.rst > +F: docs/tools/virtfs-proxy-helper.rst Unrelated, but Paolo once said helpers are not tools. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
On 2/4/21 10:59 AM, Philippe Mathieu-Daudé wrote: > On 2/4/21 2:54 PM, Wainer dos Santos Moschetta wrote: >> The qemu-img.rst, qemu-nbd.rst, virtfs-proxy-helper.rst, qemu-trace-stap.rst, >> and virtiofsd.rst manuals were moved to docs/tools, so this update MAINTAINERS >> accordingly. >> >> Fixes: a08b4a9fe6c ("docs: Move tools documentation to tools manual") >> Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com> >> --- >> v1: was "MAINTAINERS: Fix the location of virtiofsd.rst" >> v2: Fixed the location of all files [philmd] >> >> MAINTAINERS | 10 +++++----- >> 1 file changed, 5 insertions(+), 5 deletions(-) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 00626941f1..174425a941 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -1829,7 +1829,7 @@ S: Odd Fixes >> F: hw/9pfs/ >> X: hw/9pfs/xen-9p* >> F: fsdev/ >> -F: docs/interop/virtfs-proxy-helper.rst >> +F: docs/tools/virtfs-proxy-helper.rst > Unrelated, but Paolo once said helpers are not tools. Unrelated too, but allow me to ask: Should we move the tools (qemu-img, qemu-io, qemu-nbd...etc) to the tools directory (virtiofsd seems to feel alone there)? - Wainer > > Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> > Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> > >
On Thu, 4 Feb 2021 at 14:23, Wainer dos Santos Moschetta <wainersm@redhat.com> wrote: > Unrelated too, but allow me to ask: > > Should we move the tools (qemu-img, qemu-io, qemu-nbd...etc) to the > tools directory (virtiofsd seems to feel alone there)? I think that would be a good thing, yes (things documented in docs/tools should have their source code in tools). -- PMM
Am 04.02.2021 um 15:31 hat Peter Maydell geschrieben: > On Thu, 4 Feb 2021 at 14:23, Wainer dos Santos Moschetta > <wainersm@redhat.com> wrote: > > Unrelated too, but allow me to ask: > > > > Should we move the tools (qemu-img, qemu-io, qemu-nbd...etc) to the > > tools directory (virtiofsd seems to feel alone there)? > > I think that would be a good thing, yes (things documented in docs/tools > should have their source code in tools). Maybe we should define then what a tool is. I think contrib/ has a few more things that could be considered tools. Also note that qemu-io-cmds.c is linked to the system emulator (for HMP), so you would have to keep that somewhere else and spread qemu-io over two otherwise unrelated directories. I'm not sure if that improves the situation. Kevin
On 04/02/21 15:22, Wainer dos Santos Moschetta wrote: >>> -F: docs/interop/virtfs-proxy-helper.rst >>> +F: docs/tools/virtfs-proxy-helper.rst >> >> Unrelated, but Paolo once said helpers are not tools. I think helpers is not a good word. However, if an executable: - can be started directly by QEMU, or is not useful without an emulator - is usually too complex for a user to run manually then it should be documented in docs/interop (not docs/tools). Their sources however can be in tools/, that's not a problem at all. Paolo > Unrelated too, but allow me to ask: > > Should we move the tools (qemu-img, qemu-io, qemu-nbd...etc) to the > tools directory (virtiofsd seems to feel alone there)?
On Thu, Feb 04, 2021 at 03:40:06PM +0100, Kevin Wolf wrote: > Am 04.02.2021 um 15:31 hat Peter Maydell geschrieben: > > On Thu, 4 Feb 2021 at 14:23, Wainer dos Santos Moschetta > > <wainersm@redhat.com> wrote: > > > Unrelated too, but allow me to ask: > > > > > > Should we move the tools (qemu-img, qemu-io, qemu-nbd...etc) to the > > > tools directory (virtiofsd seems to feel alone there)? > > > > I think that would be a good thing, yes (things documented in docs/tools > > should have their source code in tools). > > Maybe we should define then what a tool is. I think contrib/ has a few > more things that could be considered tools. The distinction of contrib/ vs tools/ is supposed to be more a reflection on the quality of the program. contrib/ should be considered demo-ware, no back compat guaranteed, may or may not work, no testing guaranteed, no man pages. tools/ should be for any program that we intend end users to actively use in real world, with an expectation of quality and stable CLI and man pages. Regards, Daniel
On Thu, 4 Feb 2021 at 14:40, Kevin Wolf <kwolf@redhat.com> wrote: > > Am 04.02.2021 um 15:31 hat Peter Maydell geschrieben: > > On Thu, 4 Feb 2021 at 14:23, Wainer dos Santos Moschetta > > <wainersm@redhat.com> wrote: > > > Unrelated too, but allow me to ask: > > > > > > Should we move the tools (qemu-img, qemu-io, qemu-nbd...etc) to the > > > tools directory (virtiofsd seems to feel alone there)? > > > > I think that would be a good thing, yes (things documented in docs/tools > > should have their source code in tools). > > Maybe we should define then what a tool is. I think contrib/ has a few > more things that could be considered tools. I think that's more that contrib/ is a weird mess and dumping ground (as directories named "contrib" usually are -- it often seems to mean "pile of random unmaintained stuff"). If there are things in it that have better homes elsewhere it would be good to move them too. thanks -- PMM
On Thu, 4 Feb 2021 at 14:47, Daniel P. Berrangé <berrange@redhat.com> wrote: > The distinction of contrib/ vs tools/ is supposed to be more a > reflection on the quality of the program. > > contrib/ should be considered demo-ware, no back compat guaranteed, > may or may not work, no testing guaranteed, no man pages. On this definition, why do we have any of it in our source tree? Interesting but unmaintained side things can live quite happily elsewhere (other peoples' git forks, blog posts, whatever). If we care about a bit of code enough to keep it in our source tree we ought to care about it enough to properly document and test it and give it a suitable place to live. thanks -- PMM
Am 04.02.2021 um 15:47 hat Daniel P. Berrangé geschrieben: > On Thu, Feb 04, 2021 at 03:40:06PM +0100, Kevin Wolf wrote: > > Am 04.02.2021 um 15:31 hat Peter Maydell geschrieben: > > > On Thu, 4 Feb 2021 at 14:23, Wainer dos Santos Moschetta > > > <wainersm@redhat.com> wrote: > > > > Unrelated too, but allow me to ask: > > > > > > > > Should we move the tools (qemu-img, qemu-io, qemu-nbd...etc) to the > > > > tools directory (virtiofsd seems to feel alone there)? > > > > > > I think that would be a good thing, yes (things documented in docs/tools > > > should have their source code in tools). > > > > Maybe we should define then what a tool is. I think contrib/ has a few > > more things that could be considered tools. > > The distinction of contrib/ vs tools/ is supposed to be more a > reflection on the quality of the program. > > contrib/ should be considered demo-ware, no back compat guaranteed, > may or may not work, no testing guaranteed, no man pages. > > tools/ should be for any program that we intend end users to actively > use in real world, with an expectation of quality and stable CLI and > man pages. Maybe the difference should be related to what we build by default then? Just checking what executables my build directory contains, I guess these are candidates for tools/: qemu-bridge-helper qemu-edid qemu-img qemu-io qemu-keymap qemu-nbd qemu-pr-helper Almost all of them are currently in the root directory today. Only qemu-pr-helper is in scsi/. And then there is qemu-storage-daemon which lives in storage-daemon/ today and whose executable ends up in a storage-daemon/ subdirectory of the build directory since the Meson conversion, which is inconsistent with all other tools. I haven't checked other subdirectories for more executables that might exist. Kevin
On 04/02/21 15:50, Peter Maydell wrote: > On Thu, 4 Feb 2021 at 14:47, Daniel P. Berrangé <berrange@redhat.com> wrote: >> The distinction of contrib/ vs tools/ is supposed to be more a >> reflection on the quality of the program. >> >> contrib/ should be considered demo-ware, no back compat guaranteed, >> may or may not work, no testing guaranteed, no man pages. > > On this definition, why do we have any of it in our source tree? > Interesting but unmaintained side things can live quite happily > elsewhere (other peoples' git forks, blog posts, whatever). > If we care about a bit of code enough to keep it in our source > tree we ought to care about it enough to properly document > and test it and give it a suitable place to live. That's indeed what happened with libvhost-user; it has graduated to a separate project since it is okay for use in other (production-ready) vhost-user backends. Most of the software in contrib/ is essentially a reference implementations. They are "perfect" for that task, but not meant to grow more features or to be used in production (compare vhost-user-blk with qemu-storage-daemon for example). The other four can be classified as follows: - elf2dmp and rdmacm-mux should be in tools/, probably it's in contrib/ because nobody uses it and there's no tests so it might bitrot. - systemd is just a couple files meant for distros to pick up, possibly with customizations. gitdm is just for people who want to get QEMU development stats, so I suppose these two are in the same group as well. Paolo
On Thu, Feb 04, 2021 at 02:50:08PM +0000, Peter Maydell wrote: > On Thu, 4 Feb 2021 at 14:47, Daniel P. Berrangé <berrange@redhat.com> wrote: > > The distinction of contrib/ vs tools/ is supposed to be more a > > reflection on the quality of the program. > > > > contrib/ should be considered demo-ware, no back compat guaranteed, > > may or may not work, no testing guaranteed, no man pages. > > On this definition, why do we have any of it in our source tree? > Interesting but unmaintained side things can live quite happily > elsewhere (other peoples' git forks, blog posts, whatever). Yes, broadly speaking I would actually agree with this. I think much of this could easily live outside of qemu.git, beit a separate repo uner QEMU project namespace, or a complete 3rd party. Especially the vhost-user stuff has no dependency on QEMU in general and could be used with other KVM userspaces. > If we care about a bit of code enough to keep it in our source > tree we ought to care about it enough to properly document > and test it and give it a suitable place to live. Regards, Daniel
On Thu, Feb 04, 2021 at 04:02:01PM +0100, Paolo Bonzini wrote: > On 04/02/21 15:50, Peter Maydell wrote: > > On Thu, 4 Feb 2021 at 14:47, Daniel P. Berrangé <berrange@redhat.com> wrote: > > > The distinction of contrib/ vs tools/ is supposed to be more a > > > reflection on the quality of the program. > > > > > > contrib/ should be considered demo-ware, no back compat guaranteed, > > > may or may not work, no testing guaranteed, no man pages. > > > > On this definition, why do we have any of it in our source tree? > > Interesting but unmaintained side things can live quite happily > > elsewhere (other peoples' git forks, blog posts, whatever). > > If we care about a bit of code enough to keep it in our source > > tree we ought to care about it enough to properly document > > and test it and give it a suitable place to live. > > That's indeed what happened with libvhost-user; it has graduated to a > separate project since it is okay for use in other (production-ready) > vhost-user backends. > > Most of the software in contrib/ is essentially a reference implementations. > They are "perfect" for that task, but not meant to grow more features or to > be used in production (compare vhost-user-blk with qemu-storage-daemon for > example). > > The other four can be classified as follows: > > - elf2dmp and rdmacm-mux should be in tools/, probably it's in contrib/ > because nobody uses it and there's no tests so it might bitrot. > > - systemd is just a couple files meant for distros to pick up, possibly with > customizations. gitdm is just for people who want to get QEMU development > stats, so I suppose these two are in the same group as well. gitdm ought to be in scripts/ really The systemd files ought to be in the same directory as the tool they are associated with. Regards, Daniel
On 2/4/21 4:06 PM, Daniel P. Berrangé wrote: > On Thu, Feb 04, 2021 at 04:02:01PM +0100, Paolo Bonzini wrote: >> On 04/02/21 15:50, Peter Maydell wrote: >>> On Thu, 4 Feb 2021 at 14:47, Daniel P. Berrangé <berrange@redhat.com> wrote: >>>> The distinction of contrib/ vs tools/ is supposed to be more a >>>> reflection on the quality of the program. >>>> >>>> contrib/ should be considered demo-ware, no back compat guaranteed, >>>> may or may not work, no testing guaranteed, no man pages. >>> >>> On this definition, why do we have any of it in our source tree? >>> Interesting but unmaintained side things can live quite happily >>> elsewhere (other peoples' git forks, blog posts, whatever). >>> If we care about a bit of code enough to keep it in our source >>> tree we ought to care about it enough to properly document >>> and test it and give it a suitable place to live. >> >> That's indeed what happened with libvhost-user; it has graduated to a >> separate project since it is okay for use in other (production-ready) >> vhost-user backends. >> >> Most of the software in contrib/ is essentially a reference implementations. >> They are "perfect" for that task, but not meant to grow more features or to >> be used in production (compare vhost-user-blk with qemu-storage-daemon for >> example). >> >> The other four can be classified as follows: >> >> - elf2dmp and rdmacm-mux should be in tools/, probably it's in contrib/ >> because nobody uses it and there's no tests so it might bitrot. Why keep something nobody uses?
On 04/02/21 18:37, Philippe Mathieu-Daudé wrote: >> - elf2dmp and rdmacm-mux should be in tools/, probably it's in contrib/ >> because nobody uses it and there's no tests so it might bitrot. > > Why keep something nobody uses? Well, not really nobody but no maintainer. Paolo
On 2/4/21 3:40 PM, Paolo Bonzini wrote: > On 04/02/21 15:22, Wainer dos Santos Moschetta wrote: >>>> -F: docs/interop/virtfs-proxy-helper.rst >>>> +F: docs/tools/virtfs-proxy-helper.rst >>> >>> Unrelated, but Paolo once said helpers are not tools. > > I think helpers is not a good word. However, if an executable: > > - can be started directly by QEMU, or is not useful without an emulator > > - is usually too complex for a user to run manually > > then it should be documented in docs/interop (not docs/tools). Their > sources however can be in tools/, that's not a problem at all. I understand tools can be built/used standalone (no dependence), while helpers are companion of another binary, thus dependent on it: - we can build tools without emulator - it is probably pointless to build an helper without its helpee - some binaries can't be use without helpers Maybe "companion" is a better candidate to describe?
On 04/02/21 18:42, Philippe Mathieu-Daudé wrote: > On 2/4/21 3:40 PM, Paolo Bonzini wrote: >> On 04/02/21 15:22, Wainer dos Santos Moschetta wrote: >>>>> -F: docs/interop/virtfs-proxy-helper.rst >>>>> +F: docs/tools/virtfs-proxy-helper.rst >>>> >>>> Unrelated, but Paolo once said helpers are not tools. >> >> I think helpers is not a good word. However, if an executable: >> >> - can be started directly by QEMU, or is not useful without an emulator >> >> - is usually too complex for a user to run manually >> >> then it should be documented in docs/interop (not docs/tools). Their >> sources however can be in tools/, that's not a problem at all. > > I understand tools can be built/used standalone (no dependence), > while helpers are companion of another binary, thus dependent on it: > > - we can build tools without emulator > - it is probably pointless to build an helper without its helpee > - some binaries can't be use without helpers > > Maybe "companion" is a better candidate to describe? I don't think we use the word helper anymore in the build system, so really the only thing left is whether the documentation goes in tools/ or interop/. The sources can be in tools/ unconditionally if people decide that's desirable, either with or without subdirectories. I didn't propose that because the Meson change was big enough and it can be the decision of individual maintainers. Moving the individual tools is easy enough, since most of them are just one source file, however moving the executables would require changes in the tests and son on. Paolo
On 2/4/21 8:22 AM, Wainer dos Santos Moschetta wrote: > Unrelated too, but allow me to ask: > > Should we move the tools (qemu-img, qemu-io, qemu-nbd...etc) to the > tools directory (virtiofsd seems to feel alone there)? No complaint by me for qemu-nbd (I had floated the idea before the meson conversion, but held off at the time because it would conflict)
On 2/4/21 9:22 AM, Wainer dos Santos Moschetta wrote: > > On 2/4/21 10:59 AM, Philippe Mathieu-Daudé wrote: >> On 2/4/21 2:54 PM, Wainer dos Santos Moschetta wrote: >>> The qemu-img.rst, qemu-nbd.rst, virtfs-proxy-helper.rst, >>> qemu-trace-stap.rst, >>> and virtiofsd.rst manuals were moved to docs/tools, so this update >>> MAINTAINERS >>> accordingly. >>> >>> Fixes: a08b4a9fe6c ("docs: Move tools documentation to tools manual") >>> Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com> >>> --- >>> v1: was "MAINTAINERS: Fix the location of virtiofsd.rst" >>> v2: Fixed the location of all files [philmd] >>> >>> MAINTAINERS | 10 +++++----- >>> 1 file changed, 5 insertions(+), 5 deletions(-) >>> >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index 00626941f1..174425a941 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -1829,7 +1829,7 @@ S: Odd Fixes >>> F: hw/9pfs/ >>> X: hw/9pfs/xen-9p* >>> F: fsdev/ >>> -F: docs/interop/virtfs-proxy-helper.rst >>> +F: docs/tools/virtfs-proxy-helper.rst >> Unrelated, but Paolo once said helpers are not tools. > > Unrelated too, but allow me to ask: > > Should we move the tools (qemu-img, qemu-io, qemu-nbd...etc) to the > tools directory (virtiofsd seems to feel alone there)? > Only smiles and cheers from me. I recommend a README.rst that can go in the tools/ directory that explains the purpose of the directory and standards for inclusion, etc. Very small blurbs explaining what, broadly, the tools are, could be nice for passers-by on gitlab while browsing the source structure. This would allow us to codify much of what happened later in this thread (what goes here, why? do we support it? etc.) --js
Hi, Any issue that prevent this of being queued? Thanks! Wainer On 2/4/21 10:59 AM, Philippe Mathieu-Daudé wrote: > On 2/4/21 2:54 PM, Wainer dos Santos Moschetta wrote: >> The qemu-img.rst, qemu-nbd.rst, virtfs-proxy-helper.rst, qemu-trace-stap.rst, >> and virtiofsd.rst manuals were moved to docs/tools, so this update MAINTAINERS >> accordingly. >> >> Fixes: a08b4a9fe6c ("docs: Move tools documentation to tools manual") >> Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com> >> --- >> v1: was "MAINTAINERS: Fix the location of virtiofsd.rst" >> v2: Fixed the location of all files [philmd] >> >> MAINTAINERS | 10 +++++----- >> 1 file changed, 5 insertions(+), 5 deletions(-) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 00626941f1..174425a941 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -1829,7 +1829,7 @@ S: Odd Fixes >> F: hw/9pfs/ >> X: hw/9pfs/xen-9p* >> F: fsdev/ >> -F: docs/interop/virtfs-proxy-helper.rst >> +F: docs/tools/virtfs-proxy-helper.rst > Unrelated, but Paolo once said helpers are not tools. > > Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> > Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> >
On 09/03/2021 18.41, Wainer dos Santos Moschetta wrote: > Hi, > > Any issue that prevent this of being queued? Maybe it's just not clear who should take the patch ... CC:-ing qemu-trivial and qemu-block now, since I think it could go through the trivial or block tree. > On 2/4/21 10:59 AM, Philippe Mathieu-Daudé wrote: >> On 2/4/21 2:54 PM, Wainer dos Santos Moschetta wrote: >>> The qemu-img.rst, qemu-nbd.rst, virtfs-proxy-helper.rst, >>> qemu-trace-stap.rst, >>> and virtiofsd.rst manuals were moved to docs/tools, so this update >>> MAINTAINERS >>> accordingly. >>> >>> Fixes: a08b4a9fe6c ("docs: Move tools documentation to tools manual") >>> Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com> >>> --- >>> v1: was "MAINTAINERS: Fix the location of virtiofsd.rst" >>> v2: Fixed the location of all files [philmd] >>> >>> MAINTAINERS | 10 +++++----- >>> 1 file changed, 5 insertions(+), 5 deletions(-) >>> >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index 00626941f1..174425a941 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -1829,7 +1829,7 @@ S: Odd Fixes >>> F: hw/9pfs/ >>> X: hw/9pfs/xen-9p* >>> F: fsdev/ >>> -F: docs/interop/virtfs-proxy-helper.rst >>> +F: docs/tools/virtfs-proxy-helper.rst FWIW: Reviewed-by: Thomas Huth <thuth@redhat.com>
Le 09/03/2021 à 20:48, Thomas Huth a écrit : > On 09/03/2021 18.41, Wainer dos Santos Moschetta wrote: >> Hi, >> >> Any issue that prevent this of being queued? > > Maybe it's just not clear who should take the patch ... CC:-ing qemu-trivial and qemu-block now, > since I think it could go through the trivial or block tree. > >> On 2/4/21 10:59 AM, Philippe Mathieu-Daudé wrote: >>> On 2/4/21 2:54 PM, Wainer dos Santos Moschetta wrote: >>>> The qemu-img.rst, qemu-nbd.rst, virtfs-proxy-helper.rst, qemu-trace-stap.rst, >>>> and virtiofsd.rst manuals were moved to docs/tools, so this update MAINTAINERS >>>> accordingly. >>>> >>>> Fixes: a08b4a9fe6c ("docs: Move tools documentation to tools manual") >>>> Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com> >>>> --- >>>> v1: was "MAINTAINERS: Fix the location of virtiofsd.rst" >>>> v2: Fixed the location of all files [philmd] >>>> >>>> MAINTAINERS | 10 +++++----- >>>> 1 file changed, 5 insertions(+), 5 deletions(-) >>>> >>>> diff --git a/MAINTAINERS b/MAINTAINERS >>>> index 00626941f1..174425a941 100644 >>>> --- a/MAINTAINERS >>>> +++ b/MAINTAINERS >>>> @@ -1829,7 +1829,7 @@ S: Odd Fixes >>>> F: hw/9pfs/ >>>> X: hw/9pfs/xen-9p* >>>> F: fsdev/ >>>> -F: docs/interop/virtfs-proxy-helper.rst >>>> +F: docs/tools/virtfs-proxy-helper.rst > > FWIW: > Reviewed-by: Thomas Huth <thuth@redhat.com> > > Applied to my trivial-patches branch. Thanks, Laurent
On Tue, 9 Mar 2021 20:48:40 +0100 Thomas Huth <thuth@redhat.com> wrote: > On 09/03/2021 18.41, Wainer dos Santos Moschetta wrote: > > Hi, > > > > Any issue that prevent this of being queued? > > Maybe it's just not clear who should take the patch ... CC:-ing qemu-trivial > and qemu-block now, since I think it could go through the trivial or block tree. > For the virtfs change: Acked-by: Greg Kurz <groug@kaod.org> > > On 2/4/21 10:59 AM, Philippe Mathieu-Daudé wrote: > >> On 2/4/21 2:54 PM, Wainer dos Santos Moschetta wrote: > >>> The qemu-img.rst, qemu-nbd.rst, virtfs-proxy-helper.rst, > >>> qemu-trace-stap.rst, > >>> and virtiofsd.rst manuals were moved to docs/tools, so this update > >>> MAINTAINERS > >>> accordingly. > >>> > >>> Fixes: a08b4a9fe6c ("docs: Move tools documentation to tools manual") > >>> Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com> > >>> --- > >>> v1: was "MAINTAINERS: Fix the location of virtiofsd.rst" > >>> v2: Fixed the location of all files [philmd] > >>> > >>> MAINTAINERS | 10 +++++----- > >>> 1 file changed, 5 insertions(+), 5 deletions(-) > >>> > >>> diff --git a/MAINTAINERS b/MAINTAINERS > >>> index 00626941f1..174425a941 100644 > >>> --- a/MAINTAINERS > >>> +++ b/MAINTAINERS > >>> @@ -1829,7 +1829,7 @@ S: Odd Fixes > >>> F: hw/9pfs/ > >>> X: hw/9pfs/xen-9p* > >>> F: fsdev/ > >>> -F: docs/interop/virtfs-proxy-helper.rst > >>> +F: docs/tools/virtfs-proxy-helper.rst > > FWIW: > Reviewed-by: Thomas Huth <thuth@redhat.com> >
diff --git a/MAINTAINERS b/MAINTAINERS index 00626941f1..174425a941 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1829,7 +1829,7 @@ S: Odd Fixes F: hw/9pfs/ X: hw/9pfs/xen-9p* F: fsdev/ -F: docs/interop/virtfs-proxy-helper.rst +F: docs/tools/virtfs-proxy-helper.rst F: tests/qtest/virtio-9p-test.c T: git https://gitlab.com/gkurz/qemu.git 9p-next @@ -1859,7 +1859,7 @@ S: Supported F: tools/virtiofsd/* F: hw/virtio/vhost-user-fs* F: include/hw/virtio/vhost-user-fs.h -F: docs/interop/virtiofsd.rst +F: docs/tools/virtiofsd.rst virtio-input M: Gerd Hoffmann <kraxel@redhat.com> @@ -2166,7 +2166,7 @@ F: block/ F: hw/block/ F: include/block/ F: qemu-img* -F: docs/interop/qemu-img.rst +F: docs/tools/qemu-img.rst F: qemu-io* F: tests/qemu-iotests/ F: util/qemu-progress.c @@ -2620,7 +2620,7 @@ F: qapi/trace.json F: scripts/tracetool.py F: scripts/tracetool/ F: scripts/qemu-trace-stap* -F: docs/interop/qemu-trace-stap.rst +F: docs/tools/qemu-trace-stap.rst F: docs/devel/tracing.txt T: git https://github.com/stefanha/qemu.git tracing @@ -2999,7 +2999,7 @@ F: include/block/nbd* F: qemu-nbd.* F: blockdev-nbd.c F: docs/interop/nbd.txt -F: docs/interop/qemu-nbd.rst +F: docs/tools/qemu-nbd.rst T: git https://repo.or.cz/qemu/ericb.git nbd NFS
The qemu-img.rst, qemu-nbd.rst, virtfs-proxy-helper.rst, qemu-trace-stap.rst, and virtiofsd.rst manuals were moved to docs/tools, so this update MAINTAINERS accordingly. Fixes: a08b4a9fe6c ("docs: Move tools documentation to tools manual") Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com> --- v1: was "MAINTAINERS: Fix the location of virtiofsd.rst" v2: Fixed the location of all files [philmd] MAINTAINERS | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)