qapi/accelerator.json | 18 ++++++---------- qapi/acpi-hest.json | 4 ++-- qapi/authz.json | 21 +++++++------------ qapi/compat.json | 9 +++----- qapi/cryptodev.json | 18 ++++++---------- qapi/ebpf.json | 14 ++++++------- qapi/error.json | 3 +-- qapi/machine-common.json | 19 +++++++---------- qapi/misc-arm.json | 24 +++++++++------------ qapi/replay.json | 45 ++++++++++++++++++---------------------- qapi/trace.json | 12 ++++------- qapi/uefi.json | 5 ++--- qapi/vfio.json | 19 ++++++++--------- qapi/yank.json | 28 ++++++++++--------------- 14 files changed, 94 insertions(+), 145 deletions(-)
GitLab CI: https://gitlab.com/jsnow/qemu/-/pipelines/2638342206 Hi, this patchset converts some of the most trivial modules to use the new explicit intro syntax. This particular patchset does not differentiate between "trivial" conversions and those that take slightly more liberty in refactoring, but there are (debatably?) no such cases in this patchset. John Snow (14): qapi: convert intro sections for error.json qapi: convert intro sections for acpi-hest.json qapi: convert intro sections for ebpf.json qapi: convert intro sections for uefi.json qapi: convert intro sections for compat.json qapi: convert intro sections for vfio.json qapi: convert intro sections for trace.json qapi: convert intro sections for misc-arm.json qapi: convert intro sections for cryptodev.json qapi: convert intro sections for machine-common.json qapi: convert intro sections for accelerator.json qapi: convert intro sections for authz.json qapi: convert intro sections for yank.json qapi: convert intro sections for replay.json qapi/accelerator.json | 18 ++++++---------- qapi/acpi-hest.json | 4 ++-- qapi/authz.json | 21 +++++++------------ qapi/compat.json | 9 +++----- qapi/cryptodev.json | 18 ++++++---------- qapi/ebpf.json | 14 ++++++------- qapi/error.json | 3 +-- qapi/machine-common.json | 19 +++++++---------- qapi/misc-arm.json | 24 +++++++++------------ qapi/replay.json | 45 ++++++++++++++++++---------------------- qapi/trace.json | 12 ++++------- qapi/uefi.json | 5 ++--- qapi/vfio.json | 19 ++++++++--------- qapi/yank.json | 28 ++++++++++--------------- 14 files changed, 94 insertions(+), 145 deletions(-) -- 2.54.0
John Snow <jsnow@redhat.com> writes: > GitLab CI: https://gitlab.com/jsnow/qemu/-/pipelines/2638342206 > > Hi, this patchset converts some of the most trivial modules to use the > new explicit intro syntax. This particular patchset does not > differentiate between "trivial" conversions and those that take > slightly more liberty in refactoring, but there are (debatably?) no > such cases in this patchset. Looks entirely mechanical to me. Am I missing anything?
On Mon, Jul 13, 2026 at 9:00 AM Markus Armbruster <armbru@redhat.com> wrote: > > John Snow <jsnow@redhat.com> writes: > > > GitLab CI: https://gitlab.com/jsnow/qemu/-/pipelines/2638342206 > > > > Hi, this patchset converts some of the most trivial modules to use the > > new explicit intro syntax. This particular patchset does not > > differentiate between "trivial" conversions and those that take > > slightly more liberty in refactoring, but there are (debatably?) no > > such cases in this patchset. > > Looks entirely mechanical to me. Am I missing anything? Honest answer: I am not sure; I have edited so many QAPI files that I cannot remember what is and what is not mechanical anymore. If there are instances of "non-mechanical" changes, it would be for cases where I decide to indent some paragraphs, but not others, effectively introducing a new split as to what appears before and what appears after the tabular data. I genuinely do not recall if there are any such cases in this mini-series.
John Snow <jsnow@redhat.com> writes:
> On Mon, Jul 13, 2026 at 9:00 AM Markus Armbruster <armbru@redhat.com> wrote:
>>
>> John Snow <jsnow@redhat.com> writes:
>>
>> > GitLab CI: https://gitlab.com/jsnow/qemu/-/pipelines/2638342206
>> >
>> > Hi, this patchset converts some of the most trivial modules to use the
>> > new explicit intro syntax. This particular patchset does not
>> > differentiate between "trivial" conversions and those that take
>> > slightly more liberty in refactoring, but there are (debatably?) no
>> > such cases in this patchset.
>>
>> Looks entirely mechanical to me. Am I missing anything?
>
> Honest answer: I am not sure; I have edited so many QAPI files that I
> cannot remember what is and what is not mechanical anymore. If there
> are instances of "non-mechanical" changes, it would be for cases where
> I decide to indent some paragraphs, but not others, effectively
> introducing a new split as to what appears before and what appears
> after the tabular data.
>
> I genuinely do not recall if there are any such cases in this mini-series.
It's only mostly mechanical.
Almost always, the patches change
##
# @name:
#
# Single plain paragraph: Lorem ipsum dolor sit amet ut enim ad minim
# veniam duis aute irure dolor.
#
# Something other than a plain paragraph
to
##
# @name:
# Single plain paragraph: Lorem ipsum dolor sit amet ut enim ad
# minim veniam duis aute irure dolor.
#
# Something other than a plain paragraph
No decisions, thus mechanical.
I found two exceptions:
1. In qapi/compat.json
@@ -39,8 +37,7 @@
##
# @CompatPolicy:
-#
-# Policy for handling deprecated management interfaces.
+# Policy for handling deprecated management interfaces.
#
# This is intended for testing users of the management interfaces.
#
# Limitation: covers only syntactic aspects of QMP, i.e. stuff tagged
# with feature 'deprecated' or 'unstable'. We may want to extend it
# to cover semantic aspects and CLI.
#
# Limitation: deprecated-output policy @hide is not implemented for
# enumeration values. They behave the same as with policy @accept.
#
# @deprecated-input: how to handle deprecated input (default 'accept')
#
# @deprecated-output: how to handle deprecated output (default
# 'accept')
#
# @unstable-input: how to handle unstable input (default 'accept')
# (since 6.2)
#
# @unstable-output: how to handle unstable output (default 'accept')
# (since 6.2)
#
# Since: 6.0
##
Here, we have multiple paragraphs, and only the first one becomes
"intro".
2. In qapi/misc-arm.json
@@ -29,9 +28,8 @@
##
# @query-gic-capabilities:
-#
-# It will return a list of `GICCapability` objects that describe its
-# capability bits.
+# It will return a list of `GICCapability` objects that describe
+# its capability bits.
#
# On non-ARM targets this command will report an error as the GIC
# technology is not applicable.
#
# Since: 2.6
#
# .. qmp-example::
#
# -> { "execute": "query-gic-capabilities" }
# <- { "return": [{ "version": 2, "emulated": true, "kernel": false },
# { "version": 3, "emulated": false, "kernel": true } ] }
##
Here, we have two paragraphs, and both become "intro".
On Mon, Jun 29, 2026 at 05:36:10PM -0400, John Snow wrote:
> GitLab CI: https://gitlab.com/jsnow/qemu/-/pipelines/2638342206
>
> Hi, this patchset converts some of the most trivial modules to use the
> new explicit intro syntax. This particular patchset does not
> differentiate between "trivial" conversions and those that take
> slightly more liberty in refactoring, but there are (debatably?) no
> such cases in this patchset.
>
> John Snow (14):
> qapi: convert intro sections for error.json
> qapi: convert intro sections for acpi-hest.json
> qapi: convert intro sections for ebpf.json
> qapi: convert intro sections for uefi.json
> qapi: convert intro sections for compat.json
> qapi: convert intro sections for vfio.json
> qapi: convert intro sections for trace.json
> qapi: convert intro sections for misc-arm.json
> qapi: convert intro sections for cryptodev.json
> qapi: convert intro sections for machine-common.json
> qapi: convert intro sections for accelerator.json
> qapi: convert intro sections for authz.json
> qapi: convert intro sections for yank.json
> qapi: convert intro sections for replay.json
>
> qapi/accelerator.json | 18 ++++++----------
> qapi/acpi-hest.json | 4 ++--
> qapi/authz.json | 21 +++++++------------
> qapi/compat.json | 9 +++-----
> qapi/cryptodev.json | 18 ++++++----------
> qapi/ebpf.json | 14 ++++++-------
> qapi/error.json | 3 +--
> qapi/machine-common.json | 19 +++++++----------
> qapi/misc-arm.json | 24 +++++++++------------
> qapi/replay.json | 45 ++++++++++++++++++----------------------
> qapi/trace.json | 12 ++++-------
> qapi/uefi.json | 5 ++---
> qapi/vfio.json | 19 ++++++++---------
> qapi/yank.json | 28 ++++++++++---------------
> 14 files changed, 94 insertions(+), 145 deletions(-)
Why is this thread CCing linux-edac?
I don't see any relation here...
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Mon, Jun 29, 2026 at 04:07:56PM -0700, Borislav Petkov wrote: > On Mon, Jun 29, 2026 at 05:36:10PM -0400, John Snow wrote: > > GitLab CI: https://gitlab.com/jsnow/qemu/-/pipelines/2638342206 > > > > Hi, this patchset converts some of the most trivial modules to use the > > new explicit intro syntax. This particular patchset does not > > differentiate between "trivial" conversions and those that take > > slightly more liberty in refactoring, but there are (debatably?) no > > such cases in this patchset. > > > > John Snow (14): > > qapi: convert intro sections for error.json > > qapi: convert intro sections for acpi-hest.json > > qapi: convert intro sections for ebpf.json > > qapi: convert intro sections for uefi.json > > qapi: convert intro sections for compat.json > > qapi: convert intro sections for vfio.json > > qapi: convert intro sections for trace.json > > qapi: convert intro sections for misc-arm.json > > qapi: convert intro sections for cryptodev.json > > qapi: convert intro sections for machine-common.json > > qapi: convert intro sections for accelerator.json > > qapi: convert intro sections for authz.json > > qapi: convert intro sections for yank.json > > qapi: convert intro sections for replay.json > > > > qapi/accelerator.json | 18 ++++++---------- > > qapi/acpi-hest.json | 4 ++-- > > qapi/authz.json | 21 +++++++------------ > > qapi/compat.json | 9 +++----- > > qapi/cryptodev.json | 18 ++++++---------- > > qapi/ebpf.json | 14 ++++++------- > > qapi/error.json | 3 +-- > > qapi/machine-common.json | 19 +++++++---------- > > qapi/misc-arm.json | 24 +++++++++------------ > > qapi/replay.json | 45 ++++++++++++++++++---------------------- > > qapi/trace.json | 12 ++++------- > > qapi/uefi.json | 5 ++--- > > qapi/vfio.json | 19 ++++++++--------- > > qapi/yank.json | 28 ++++++++++--------------- > > 14 files changed, 94 insertions(+), 145 deletions(-) > > Why is this thread CCing linux-edac? > > I don't see any relation here... The linux-edac list was recently added to the QEMU MAINTAINERS file: https://gitlab.com/qemu-project/qemu/-/commit/4c5e70b9a42744401fc10b17cc61820586ba4a13 and the entry matches the qapi/acpi-hest.json file that John has modified, so gets auto-CC'd. Admittedly the content in this series is not especially relevant to the liunux-edac list in this case, but the patch submission tools are just following the declared MAINTAINERS file entry. 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 Tue, Jun 30, 2026 at 09:27:32AM +0100, Daniel P. Berrangé wrote:
> > Why is this thread CCing linux-edac?
> >
> > I don't see any relation here...
>
> The linux-edac list was recently added to the QEMU MAINTAINERS
> file:
>
> https://gitlab.com/qemu-project/qemu/-/commit/4c5e70b9a42744401fc10b17cc61820586ba4a13
>
> and the entry matches the qapi/acpi-hest.json file that John has
> modified, so gets auto-CC'd.
>
> Admittedly the content in this series is not especially relevant
> to the liunux-edac list in this case, but the patch submission
> tools are just following the declared MAINTAINERS file entry.
Thanks for letting me know.
@Mauro, please remove a linux-kernel mailing list from being CCed with qemu
patches. This is only going to cause a huuuge confusion as it is already
showing.
Please do a separate list only for qemu RAS stuff.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Tue, Jun 30, 2026 at 12:21:54PM -0700, Borislav Petkov wrote:
> On Tue, Jun 30, 2026 at 09:27:32AM +0100, Daniel P. Berrangé wrote:
> > > Why is this thread CCing linux-edac?
> > >
> > > I don't see any relation here...
> >
> > The linux-edac list was recently added to the QEMU MAINTAINERS
> > file:
> >
> > https://gitlab.com/qemu-project/qemu/-/commit/4c5e70b9a42744401fc10b17cc61820586ba4a13
> >
> > and the entry matches the qapi/acpi-hest.json file that John has
> > modified, so gets auto-CC'd.
> >
> > Admittedly the content in this series is not especially relevant
> > to the liunux-edac list in this case, but the patch submission
> > tools are just following the declared MAINTAINERS file entry.
>
> Thanks for letting me know.
>
> @Mauro, please remove a linux-kernel mailing list from being CCed with qemu
> patches. This is only going to cause a huuuge confusion as it is already
> showing.
>
> Please do a separate list only for qemu RAS stuff.
---
From: "Borislav Petkov (AMD)" <bp@alien8.de>
Date: Fri, 3 Jul 2026 08:19:53 -0700
Subject: [PATCH] MAINTAINERS: Remove linux-edac
The commit
4c5e70b9a427 ("MAINTAINERS: update HEST maintainership entries")
added a linux kernel mailing list (linux-edac) which gets CCed
automatically with qemu patches. This is absolutely confusing and it
should not happen. Qemu should have its own ras mailing list where stuff
like that goes.
Drop that list.
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 97dcc78ded61..3664c0d67677 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2274,7 +2274,6 @@ F: docs/devel/testing/acpi-bits.rst
ACPI/HEST/GHES
M: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-L: linux-edac@vger.kernel.org
L: qemu-arm@nongnu.org
S: Maintained
F: hw/acpi/ghes.c
--
2.53.0
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquetteHi Boris,
On Fri, 3 Jul 2026 08:25:29 -0700
Borislav Petkov <bp@alien8.de> wrote:
> On Tue, Jun 30, 2026 at 12:21:54PM -0700, Borislav Petkov wrote:
> > On Tue, Jun 30, 2026 at 09:27:32AM +0100, Daniel P. Berrangé wrote:
> > > > Why is this thread CCing linux-edac?
> > > >
> > > > I don't see any relation here...
> > >
> > > The linux-edac list was recently added to the QEMU MAINTAINERS
> > > file:
> > >
> > > https://gitlab.com/qemu-project/qemu/-/commit/4c5e70b9a42744401fc10b17cc61820586ba4a13
> > >
> > > and the entry matches the qapi/acpi-hest.json file that John has
> > > modified, so gets auto-CC'd.
> > >
> > > Admittedly the content in this series is not especially relevant
> > > to the liunux-edac list in this case, but the patch submission
> > > tools are just following the declared MAINTAINERS file entry.
> >
> > Thanks for letting me know.
> >
> > @Mauro, please remove a linux-kernel mailing list from being CCed with qemu
> > patches. This is only going to cause a huuuge confusion as it is already
> > showing.
I was in vacations, so I only noticed this patch today.
We use linux-edac for userspace at least since Rasdaemon beginning,
so it was never a kernel-only ML. What happened in practice on the
recent times is that rasdaemon patches are usually pushed as PR
requests at github. Yet, still today, it is recommended to also
submit them to linux-edac ML:
https://github.com/mchehab/rasdaemon#submitting-patches
Yet, I agree that having a separate ML for userspace RAS tools
makes sense. I'll check on a separate thread if we can create
one such list at vger.
> >
> > Please do a separate list only for qemu RAS stuff.
Instead of adding a patch removing it, better to wait for the ML
creation and then apply a QEMU patch changing it, and another one
to rasdaemon.
Regards,
Mauro
>
> ---
>
> From: "Borislav Petkov (AMD)" <bp@alien8.de>
> Date: Fri, 3 Jul 2026 08:19:53 -0700
> Subject: [PATCH] MAINTAINERS: Remove linux-edac
>
> The commit
>
> 4c5e70b9a427 ("MAINTAINERS: update HEST maintainership entries")
>
> added a linux kernel mailing list (linux-edac) which gets CCed
> automatically with qemu patches. This is absolutely confusing and it
> should not happen. Qemu should have its own ras mailing list where stuff
> like that goes.
>
> Drop that list.
>
> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> Cc: Markus Armbruster <armbru@redhat.com>
> Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
> ---
> MAINTAINERS | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 97dcc78ded61..3664c0d67677 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2274,7 +2274,6 @@ F: docs/devel/testing/acpi-bits.rst
>
> ACPI/HEST/GHES
> M: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> -L: linux-edac@vger.kernel.org
> L: qemu-arm@nongnu.org
> S: Maintained
> F: hw/acpi/ghes.c
Thanks,
Mauro
© 2016 - 2026 Red Hat, Inc.