[PULL 0/2] Build system: add stubs per target

[PULL 0/2] Build system: add stubs per target

[Pierrick Bouvier]

The following changes since commit a85c588d07f8d3345ccad38b22026569a04571d1:

  Merge tag 'pull-monitor-2026-05-05' of https://repo.or.cz/qemu/armbru into staging (2026-05-05 10:11:49 -0400)

are available in the Git repository at:

  https://gitlab.com/p-b-o/qemu tags/pbouvier/pr/build_system-20260505

for you to fetch changes up to 2e44ff32fc758bf8c0df13b0287afb75bb00c38e:

  target/arm: define stub library (2026-05-05 16:06:00 -0700)

----------------------------------------------------------------
Changes:
- [PATCH 0/2] single-binary: add stubs for target/ (Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>)
  Link: https://lore.kernel.org/qemu-devel/20260424230103.1579600-1-pierrick.bouvier@oss.qualcomm.com

----------------------------------------------------------------
Pierrick Bouvier (2):
      meson.build: define stubs library per target base architecture
      target/arm: define stub library

 meson.build                | 22 +++++++++++++++++++---
 target/arm/meson.build     |  8 +++-----
 target/arm/tcg/meson.build |  2 +-
 3 files changed, 23 insertions(+), 9 deletions(-)

[PULL 1/2] meson.build: define stubs library per target base architecture

[Pierrick Bouvier]

QEMU stubs (from stubs folder) have a unique feature: they emulate weak
symbols. Weak symbols are not supported on Windows with gcc. This is
achieved by defining a static library, so the linker can pick a file
only when one of its symbol is needed.

The problem is that common stubs are embedded in qemuutil, which is
defined and created before any target code. Thus, to benefit from the
same feature for target code, we need to create stub static libraries
for each target architecture.

To keep things simple, we declare one library per target base
architecture. This implies that stubs are compiled only once, and we
choose them to be system common files. This is not a big issue, since
stubs definition have no specific behaviour, out of returning a default
value, or stopping execution, which makes this safe to link them in user
binaries also.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260424230103.1579600-2-pierrick.bouvier@oss.qualcomm.com
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
---
 meson.build | 22 +++++++++++++++++++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/meson.build b/meson.build
index 4176d020c21..4dfa73576dd 100644
--- a/meson.build
+++ b/meson.build
@@ -3738,6 +3738,7 @@ target_user_arch = {}
 hw_common_arch = {}
 target_common_arch = {}
 target_common_system_arch = {}
+target_stubs_arch = {}
 
 # NOTE: the trace/ subdirectory needs the qapi_trace_events variable
 # that is filled in by qapi/.
@@ -4143,6 +4144,7 @@ common_all = static_library('common',
 # construct common libraries per base architecture
 target_common_arch_libs = {}
 target_common_system_arch_libs = {}
+target_stubs_arch_libs = {}
 foreach target_base_arch, config_base_arch : config_base_arch_mak
   target_inc = [include_directories('target' / target_base_arch)]
   inc = [common_user_inc + target_inc]
@@ -4202,6 +4204,15 @@ foreach target_base_arch, config_base_arch : config_base_arch_mak
       dependencies: src.all_dependencies() + common_deps + system_deps)
     target_common_system_arch_libs += {target_base_arch: lib}
   endif
+
+  if target_base_arch in target_stubs_arch
+    src = target_stubs_arch[target_base_arch]
+    lib = static_library('stubs_' + target_base_arch,
+                         sources: src.all_sources() + genh,
+                         include_directories: inc,
+                         c_args: target_system_c_args)
+    target_stubs_arch_libs += {target_base_arch: lib}
+  endif
 endforeach
 
 if have_rust
@@ -4361,6 +4372,11 @@ foreach target : target_dirs
     objects += lib.extract_objects(src.sources())
     arch_deps += src.dependencies()
   endif
+  lib_target_stubs = []
+  if target_base_arch in target_stubs_arch_libs
+    lib_target_stubs = [target_stubs_arch_libs[target_base_arch]]
+  endif
+  target_stubs = declare_dependency(link_with: lib_target_stubs)
 
   target_specific = specific_ss.apply(config_target, strict: false)
   arch_srcs += target_specific.sources()
@@ -4406,14 +4422,14 @@ foreach target : target_dirs
       'name': 'qemu-system-' + target_name,
       'win_subsystem': 'console',
       'sources': [main_rs, files('system/main.c')],
-      'dependencies': [sdl]
+      'dependencies': [sdl, target_stubs],
     }]
     if host_os == 'windows' and (sdl.found() or gtk.found())
       execs += [{
         'name': 'qemu-system-' + target_name + 'w',
         'win_subsystem': 'windows',
         'sources': [main_rs, files('system/main.c')],
-        'dependencies': [sdl]
+        'dependencies': [sdl, target_stubs],
       }]
     endif
     if get_option('fuzzing')
@@ -4430,7 +4446,7 @@ foreach target : target_dirs
       'name': 'qemu-' + target_name,
       'win_subsystem': 'console',
       'sources': [],
-      'dependencies': []
+      'dependencies': [target_stubs]
     }]
   endif
   foreach exe: execs
-- 
2.43.0

[PULL 2/2] target/arm: define stub library

[Pierrick Bouvier]

We use the mechanic introduced in previous commit to define a arm stubs
library. With this, we are able to eliminate symbol conflicts when
linking arm and aarch64 targets, and get one step closer to having a
single-binary.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/qemu-devel/20260424230103.1579600-3-pierrick.bouvier@oss.qualcomm.com
Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
---
 target/arm/meson.build     | 8 +++-----
 target/arm/tcg/meson.build | 2 +-
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/target/arm/meson.build b/target/arm/meson.build
index 192ac7c31ee..4723f9f170a 100644
--- a/target/arm/meson.build
+++ b/target/arm/meson.build
@@ -2,6 +2,7 @@ arm_ss = ss.source_set()
 arm_common_ss = ss.source_set()
 arm_common_system_ss = ss.source_set()
 arm_system_ss = ss.source_set()
+arm_stubs_ss = ss.source_set()
 arm_user_ss = ss.source_set()
 
 arm_common_system_ss.add(files('gdbstub.c'))
@@ -23,9 +24,7 @@ arm_system_ss.add(when: 'CONFIG_KVM', if_true: files('hyp_gdbstub.c', 'kvm.c'))
 arm_system_ss.add(when: 'CONFIG_HVF', if_true: files('hyp_gdbstub.c'))
 
 arm_user_ss.add(files('cpu.c'))
-arm_user_ss.add(when: 'TARGET_AARCH64', if_false: files(
-  'cpu32-stubs.c',
-))
+arm_stubs_ss.add(files('cpu32-stubs.c'))
 arm_user_ss.add(files(
   'cpregs-gcs.c',
   'cpregs-pmu.c',
@@ -39,8 +38,6 @@ arm_user_ss.add(when: 'CONFIG_ARM_COMPATIBLE_SEMIHOSTING',
 		        if_true: files('common-semi-target.c'))
 
 arm_common_system_ss.add(files('cpu.c'))
-arm_common_system_ss.add(when: 'TARGET_AARCH64', if_false: files(
-  'cpu32-stubs.c'))
 arm_common_system_ss.add(when: 'CONFIG_KVM', if_false: files('kvm-stub.c'))
 arm_common_system_ss.add(when: 'CONFIG_ARM_COMPATIBLE_SEMIHOSTING',
 		                 if_true: files('common-semi-target.c'))
@@ -73,3 +70,4 @@ target_system_arch += {'arm': arm_system_ss}
 target_user_arch += {'arm': arm_user_ss}
 target_common_arch += {'arm': arm_common_ss}
 target_common_system_arch += {'arm': arm_common_system_ss}
+target_stubs_arch += {'arm': arm_stubs_ss}
diff --git a/target/arm/tcg/meson.build b/target/arm/tcg/meson.build
index 02774409e56..d2364aa39c4 100644
--- a/target/arm/tcg/meson.build
+++ b/target/arm/tcg/meson.build
@@ -28,7 +28,7 @@ translate32_d = [
 ]
 
 arm_ss.add(when: 'TARGET_AARCH64', if_true: gen_a64)
-arm_ss.add(when: 'TARGET_AARCH64', if_false: files('stubs32.c'))
+arm_stubs_ss.add(files('stubs32.c'))
 
 arm_ss.add(files(
   'cpu32.c',
-- 
2.43.0

Re: [PULL 0/2] Build system: add stubs per target

[Stefan Hajnoczi]

On Tue, May 5, 2026 at 7:07 PM Pierrick Bouvier
<pierrick.bouvier@oss.qualcomm.com> wrote:
>
> The following changes since commit a85c588d07f8d3345ccad38b22026569a04571d1:
>
>   Merge tag 'pull-monitor-2026-05-05' of https://repo.or.cz/qemu/armbru into staging (2026-05-05 10:11:49 -0400)
>
> are available in the Git repository at:
>
>   https://gitlab.com/p-b-o/qemu tags/pbouvier/pr/build_system-20260505
>
> for you to fetch changes up to 2e44ff32fc758bf8c0df13b0287afb75bb00c38e:
>
>   target/arm: define stub library (2026-05-05 16:06:00 -0700)
>
> ----------------------------------------------------------------
> Changes:
> - [PATCH 0/2] single-binary: add stubs for target/ (Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>)
>   Link: https://lore.kernel.org/qemu-devel/20260424230103.1579600-1-pierrick.bouvier@oss.qualcomm.com
>
> ----------------------------------------------------------------
> Pierrick Bouvier (2):
>       meson.build: define stubs library per target base architecture
>       target/arm: define stub library
>
>  meson.build                | 22 +++++++++++++++++++---
>  target/arm/meson.build     |  8 +++-----
>  target/arm/tcg/meson.build |  2 +-
>  3 files changed, 23 insertions(+), 9 deletions(-)

Is this a pull request for Paolo's build system tree?

I'm not merging this directly because I prefer to follow MAINTAINERS
so it's clear who sends pull requests for each subsystem. That way
maintainers won't be surprised by me merging a pull request from
another contributor who is not officially the maintainer and it's also
better for security.

Thanks,
Stefan

Re: [PULL 0/2] Build system: add stubs per target

[Philippe Mathieu-Daudé]

Hi Stefan, Pierrick,

On Wed, 6 May 2026 at 16:42, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> On Tue, May 5, 2026 at 7:07 PM Pierrick Bouvier
> <pierrick.bouvier@oss.qualcomm.com> wrote:
> >
> > The following changes since commit a85c588d07f8d3345ccad38b22026569a04571d1:
> >
> >   Merge tag 'pull-monitor-2026-05-05' of https://repo.or.cz/qemu/armbru into staging (2026-05-05 10:11:49 -0400)
> >
> > are available in the Git repository at:
> >
> >   https://gitlab.com/p-b-o/qemu tags/pbouvier/pr/build_system-20260505
> >
> > for you to fetch changes up to 2e44ff32fc758bf8c0df13b0287afb75bb00c38e:
> >
> >   target/arm: define stub library (2026-05-05 16:06:00 -0700)
> >
> > ----------------------------------------------------------------
> > Changes:
> > - [PATCH 0/2] single-binary: add stubs for target/ (Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>)
> >   Link: https://lore.kernel.org/qemu-devel/20260424230103.1579600-1-pierrick.bouvier@oss.qualcomm.com
> >
> > ----------------------------------------------------------------
> > Pierrick Bouvier (2):
> >       meson.build: define stubs library per target base architecture
> >       target/arm: define stub library
> >
> >  meson.build                | 22 +++++++++++++++++++---
> >  target/arm/meson.build     |  8 +++-----
> >  target/arm/tcg/meson.build |  2 +-
> >  3 files changed, 23 insertions(+), 9 deletions(-)
>
> Is this a pull request for Paolo's build system tree?
>
> I'm not merging this directly because I prefer to follow MAINTAINERS
> so it's clear who sends pull requests for each subsystem. That way
> maintainers won't be surprised by me merging a pull request from
> another contributor who is not officially the maintainer and it's also
> better for security.

I did not notice Pierrick's PR and actually included these 2
commits in my latest "single-binary" pull request:
https://lore.kernel.org/qemu-devel/20260506135524.20617-1-philmd@linaro.org/

Pierrick and I are simply reviewers on the "Build System" topic,
but it happens that I send patches there where they are related to
the overall single binary objective, and I see Pierrick as a co-maintainer
in this area. However there is no clearly defined MAINTAINERS
section, we happen to touch build system related files all over
the tree.

Regards,

Phil.

Re: [PULL 0/2] Build system: add stubs per target

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 3535 bytes --]

On Wed, May 06, 2026 at 05:16:21PM +0200, Philippe Mathieu-Daudé wrote:
> Hi Stefan, Pierrick,
> 
> On Wed, 6 May 2026 at 16:42, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >
> > On Tue, May 5, 2026 at 7:07 PM Pierrick Bouvier
> > <pierrick.bouvier@oss.qualcomm.com> wrote:
> > >
> > > The following changes since commit a85c588d07f8d3345ccad38b22026569a04571d1:
> > >
> > >   Merge tag 'pull-monitor-2026-05-05' of https://repo.or.cz/qemu/armbru into staging (2026-05-05 10:11:49 -0400)
> > >
> > > are available in the Git repository at:
> > >
> > >   https://gitlab.com/p-b-o/qemu tags/pbouvier/pr/build_system-20260505
> > >
> > > for you to fetch changes up to 2e44ff32fc758bf8c0df13b0287afb75bb00c38e:
> > >
> > >   target/arm: define stub library (2026-05-05 16:06:00 -0700)
> > >
> > > ----------------------------------------------------------------
> > > Changes:
> > > - [PATCH 0/2] single-binary: add stubs for target/ (Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>)
> > >   Link: https://lore.kernel.org/qemu-devel/20260424230103.1579600-1-pierrick.bouvier@oss.qualcomm.com
> > >
> > > ----------------------------------------------------------------
> > > Pierrick Bouvier (2):
> > >       meson.build: define stubs library per target base architecture
> > >       target/arm: define stub library
> > >
> > >  meson.build                | 22 +++++++++++++++++++---
> > >  target/arm/meson.build     |  8 +++-----
> > >  target/arm/tcg/meson.build |  2 +-
> > >  3 files changed, 23 insertions(+), 9 deletions(-)
> >
> > Is this a pull request for Paolo's build system tree?
> >
> > I'm not merging this directly because I prefer to follow MAINTAINERS
> > so it's clear who sends pull requests for each subsystem. That way
> > maintainers won't be surprised by me merging a pull request from
> > another contributor who is not officially the maintainer and it's also
> > better for security.
> 
> I did not notice Pierrick's PR and actually included these 2
> commits in my latest "single-binary" pull request:
> https://lore.kernel.org/qemu-devel/20260506135524.20617-1-philmd@linaro.org/

That can be fine, sometimes changes are cross-cutting or part of another
sub-system (e.g. ARM target) even though they touch files a different
subsystem.

My concern is only about the pull request process. Please don't send
pull requests with a new tag/branch name that is not in MAINTAINERS. No
PR has ever been merged from Pierrick with a build_system-* tag and he
is not listed in MAINTAINERS for Build System.

This could be a sign that something in MAINTAINERS needs to be changed
or it could be a sign that these patches should go through another tree
(Paolo's or yours).

> Pierrick and I are simply reviewers on the "Build System" topic,
> but it happens that I send patches there where they are related to
> the overall single binary objective, and I see Pierrick as a co-maintainer
> in this area. However there is no clearly defined MAINTAINERS
> section, we happen to touch build system related files all over
> the tree.

I can't accept random pull requests, even from regular contributors.
Patches should go through subsystem maintainers listed in the
MAINTAINERS file. This way we can be sure that only commits reviewed by
a subsystem maintainers are merged and reduce the risk that malicious
pull requests are merged (while I trust Pierrick, it lowers my guard if
I'm accepting random pull requests from anyone at all).

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PULL 0/2] Build system: add stubs per target

[Pierrick Bouvier]

On 5/6/2026 10:08 AM, Stefan Hajnoczi wrote:
> On Wed, May 06, 2026 at 05:16:21PM +0200, Philippe Mathieu-Daudé wrote:
>> Hi Stefan, Pierrick,
>>
>> On Wed, 6 May 2026 at 16:42, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>>>
>>> On Tue, May 5, 2026 at 7:07 PM Pierrick Bouvier
>>> <pierrick.bouvier@oss.qualcomm.com> wrote:
>>>>
>>>> The following changes since commit a85c588d07f8d3345ccad38b22026569a04571d1:
>>>>
>>>>   Merge tag 'pull-monitor-2026-05-05' of https://repo.or.cz/qemu/armbru into staging (2026-05-05 10:11:49 -0400)
>>>>
>>>> are available in the Git repository at:
>>>>
>>>>   https://gitlab.com/p-b-o/qemu tags/pbouvier/pr/build_system-20260505
>>>>
>>>> for you to fetch changes up to 2e44ff32fc758bf8c0df13b0287afb75bb00c38e:
>>>>
>>>>   target/arm: define stub library (2026-05-05 16:06:00 -0700)
>>>>
>>>> ----------------------------------------------------------------
>>>> Changes:
>>>> - [PATCH 0/2] single-binary: add stubs for target/ (Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>)
>>>>   Link: https://lore.kernel.org/qemu-devel/20260424230103.1579600-1-pierrick.bouvier@oss.qualcomm.com
>>>>
>>>> ----------------------------------------------------------------
>>>> Pierrick Bouvier (2):
>>>>       meson.build: define stubs library per target base architecture
>>>>       target/arm: define stub library
>>>>
>>>>  meson.build                | 22 +++++++++++++++++++---
>>>>  target/arm/meson.build     |  8 +++-----
>>>>  target/arm/tcg/meson.build |  2 +-
>>>>  3 files changed, 23 insertions(+), 9 deletions(-)
>>>
>>> Is this a pull request for Paolo's build system tree?
>>>
>>> I'm not merging this directly because I prefer to follow MAINTAINERS
>>> so it's clear who sends pull requests for each subsystem. That way
>>> maintainers won't be surprised by me merging a pull request from
>>> another contributor who is not officially the maintainer and it's also
>>> better for security.
>>
>> I did not notice Pierrick's PR and actually included these 2
>> commits in my latest "single-binary" pull request:
>> https://lore.kernel.org/qemu-devel/20260506135524.20617-1-philmd@linaro.org/
> 
> That can be fine, sometimes changes are cross-cutting or part of another
> sub-system (e.g. ARM target) even though they touch files a different
> subsystem.
> 
> My concern is only about the pull request process. Please don't send
> pull requests with a new tag/branch name that is not in MAINTAINERS. No
> PR has ever been merged from Pierrick with a build_system-* tag and he
> is not listed in MAINTAINERS for Build System.
> 
> This could be a sign that something in MAINTAINERS needs to be changed
> or it could be a sign that these patches should go through another tree
> (Paolo's or yours).
> 
>> Pierrick and I are simply reviewers on the "Build System" topic,
>> but it happens that I send patches there where they are related to
>> the overall single binary objective, and I see Pierrick as a co-maintainer
>> in this area. However there is no clearly defined MAINTAINERS
>> section, we happen to touch build system related files all over
>> the tree.
> 
> I can't accept random pull requests, even from regular contributors.
> Patches should go through subsystem maintainers listed in the
> MAINTAINERS file. This way we can be sure that only commits reviewed by
> a subsystem maintainers are merged and reduce the risk that malicious
> pull requests are merged (while I trust Pierrick, it lowers my guard if
> I'm accepting random pull requests from anyone at all).
>

That's totally my fault here, sorry.

I have been assuming that "Build and test automation, general continuous
integration" was by extension integrating build system, but it seems
like it doesn't. I would not dare sending PR for an area I don't
maintain officially.

As well, in the past, Richard integrated some of those patches on build
system for single-binary, but I appreciate that he's definitely more
legitimate than me for pulling these kind of patches.

Philippe and I will remove those patches, and I'll ping Paolo to let him
pull this instead.

> Stefan

Regards,
Pierrick

Re: [PULL 0/2] Build system: add stubs per target

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 4901 bytes --]

On Wed, May 06, 2026 at 10:45:07AM -0700, Pierrick Bouvier wrote:
> On 5/6/2026 10:08 AM, Stefan Hajnoczi wrote:
> > On Wed, May 06, 2026 at 05:16:21PM +0200, Philippe Mathieu-Daudé wrote:
> >> Hi Stefan, Pierrick,
> >>
> >> On Wed, 6 May 2026 at 16:42, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> >>>
> >>> On Tue, May 5, 2026 at 7:07 PM Pierrick Bouvier
> >>> <pierrick.bouvier@oss.qualcomm.com> wrote:
> >>>>
> >>>> The following changes since commit a85c588d07f8d3345ccad38b22026569a04571d1:
> >>>>
> >>>>   Merge tag 'pull-monitor-2026-05-05' of https://repo.or.cz/qemu/armbru into staging (2026-05-05 10:11:49 -0400)
> >>>>
> >>>> are available in the Git repository at:
> >>>>
> >>>>   https://gitlab.com/p-b-o/qemu tags/pbouvier/pr/build_system-20260505
> >>>>
> >>>> for you to fetch changes up to 2e44ff32fc758bf8c0df13b0287afb75bb00c38e:
> >>>>
> >>>>   target/arm: define stub library (2026-05-05 16:06:00 -0700)
> >>>>
> >>>> ----------------------------------------------------------------
> >>>> Changes:
> >>>> - [PATCH 0/2] single-binary: add stubs for target/ (Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>)
> >>>>   Link: https://lore.kernel.org/qemu-devel/20260424230103.1579600-1-pierrick.bouvier@oss.qualcomm.com
> >>>>
> >>>> ----------------------------------------------------------------
> >>>> Pierrick Bouvier (2):
> >>>>       meson.build: define stubs library per target base architecture
> >>>>       target/arm: define stub library
> >>>>
> >>>>  meson.build                | 22 +++++++++++++++++++---
> >>>>  target/arm/meson.build     |  8 +++-----
> >>>>  target/arm/tcg/meson.build |  2 +-
> >>>>  3 files changed, 23 insertions(+), 9 deletions(-)
> >>>
> >>> Is this a pull request for Paolo's build system tree?
> >>>
> >>> I'm not merging this directly because I prefer to follow MAINTAINERS
> >>> so it's clear who sends pull requests for each subsystem. That way
> >>> maintainers won't be surprised by me merging a pull request from
> >>> another contributor who is not officially the maintainer and it's also
> >>> better for security.
> >>
> >> I did not notice Pierrick's PR and actually included these 2
> >> commits in my latest "single-binary" pull request:
> >> https://lore.kernel.org/qemu-devel/20260506135524.20617-1-philmd@linaro.org/
> > 
> > That can be fine, sometimes changes are cross-cutting or part of another
> > sub-system (e.g. ARM target) even though they touch files a different
> > subsystem.
> > 
> > My concern is only about the pull request process. Please don't send
> > pull requests with a new tag/branch name that is not in MAINTAINERS. No
> > PR has ever been merged from Pierrick with a build_system-* tag and he
> > is not listed in MAINTAINERS for Build System.
> > 
> > This could be a sign that something in MAINTAINERS needs to be changed
> > or it could be a sign that these patches should go through another tree
> > (Paolo's or yours).
> > 
> >> Pierrick and I are simply reviewers on the "Build System" topic,
> >> but it happens that I send patches there where they are related to
> >> the overall single binary objective, and I see Pierrick as a co-maintainer
> >> in this area. However there is no clearly defined MAINTAINERS
> >> section, we happen to touch build system related files all over
> >> the tree.
> > 
> > I can't accept random pull requests, even from regular contributors.
> > Patches should go through subsystem maintainers listed in the
> > MAINTAINERS file. This way we can be sure that only commits reviewed by
> > a subsystem maintainers are merged and reduce the risk that malicious
> > pull requests are merged (while I trust Pierrick, it lowers my guard if
> > I'm accepting random pull requests from anyone at all).
> >
> 
> That's totally my fault here, sorry.
> 
> I have been assuming that "Build and test automation, general continuous
> integration" was by extension integrating build system, but it seems
> like it doesn't. I would not dare sending PR for an area I don't
> maintain officially.
> 
> As well, in the past, Richard integrated some of those patches on build
> system for single-binary, but I appreciate that he's definitely more
> legitimate than me for pulling these kind of patches.
> 
> Philippe and I will remove those patches, and I'll ping Paolo to let him
> pull this instead.

Including the patches in Philippe's pull request is probably fine as
long as they are not something that Paolo needs to review. Sometimes
files outside the subsystem are touched in a pull request and that's
okay.

My concern is only that each pull request email series should come from
someone listed as maintainer for that area. For example, if I send a
migration pull request and then Peter or Richard would probably be
confused because I'm not the maintainer.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]