* [Buildroot] [PATCH] package/systemd: remove several Kernel config options
@ 2025-11-19 15:48 Norbert Lange
2025-11-19 16:16 ` James Hilliard
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Norbert Lange @ 2025-11-19 15:48 UTC (permalink / raw)
To: buildroot; +Cc: Norbert Lange, Sen Hastings
All those features are optional and prevent customization of the kernel.
Forcing IPv6 is particularly nasty.
This reverts parts of "package/systemd: bump to version 256.4"
Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
package/systemd/systemd.mk | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
index 126ce7716f..0ee680e55e 100644
--- a/package/systemd/systemd.mk
+++ b/package/systemd/systemd.mk
@@ -863,35 +863,16 @@ define SYSTEMD_LINUX_CONFIG_FIXUPS
$(call KCONFIG_ENABLE_OPT,CONFIG_DMIID)
- $(call KCONFIG_ENABLE_OPT,CONFIG_BLK_DEV_BSG)
-
$(call KCONFIG_ENABLE_OPT,CONFIG_NET_NS)
$(call KCONFIG_ENABLE_OPT,CONFIG_USER_NS)
$(call KCONFIG_DISABLE_OPT,CONFIG_SYSFS_DEPRECATED)
- $(call KCONFIG_ENABLE_OPT,CONFIG_IPV6)
$(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS_FS)
$(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS4_FS)
$(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_POSIX_ACL)
$(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_XATTR)
- $(call KCONFIG_ENABLE_OPT,CONFIG_SECCOMP)
- $(call KCONFIG_ENABLE_OPT,CONFIG_SECCOMP_FILTER)
- $(call KCONFIG_ENABLE_OPT,CONFIG_KCMP)
- $(call KCONFIG_ENABLE_OPT,CONFIG_NET_SCHED)
- $(call KCONFIG_ENABLE_OPT,CONFIG_NET_SCH_FQ_CODEL)
-
- $(call KCONFIG_ENABLE_OPT,CONFIG_CGROUP_SCHED)
- $(call KCONFIG_ENABLE_OPT,CONFIG_FAIR_GROUP_SCHED)
-
- $(call KCONFIG_ENABLE_OPT,CONFIG_CFS_BANDWIDTH)
-
- $(call KCONFIG_ENABLE_OPT,CONFIG_EFIVAR_FS)
- $(call KCONFIG_ENABLE_OPT,CONFIG_EFI_PARTITION)
-
- $(call KCONFIG_ENABLE_OPT,CONFIG_DMI)
- $(call KCONFIG_ENABLE_OPT,CONFIG_DMI_SYSFS)
$(call KCONFIG_DISABLE_OPT,CONFIG_RT_GROUP_SCHED)
--
2.47.3
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH] package/systemd: remove several Kernel config options
2025-11-19 15:48 [Buildroot] [PATCH] package/systemd: remove several Kernel config options Norbert Lange
@ 2025-11-19 16:16 ` James Hilliard
2025-11-19 16:32 ` Norbert Lange
2025-11-19 16:47 ` Marcus Hoffmann via buildroot
2026-01-01 22:09 ` Thomas Petazzoni via buildroot
2 siblings, 1 reply; 15+ messages in thread
From: James Hilliard @ 2025-11-19 16:16 UTC (permalink / raw)
To: Norbert Lange; +Cc: buildroot, Sen Hastings
On Wed, Nov 19, 2025 at 8:57 AM Norbert Lange <nolange79@gmail.com> wrote:
>
> All those features are optional and prevent customization of the kernel.
> Forcing IPv6 is particularly nasty.
What issue are you seeing from forcing IPV6?
>
> This reverts parts of "package/systemd: bump to version 256.4"
>
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
> ---
> package/systemd/systemd.mk | 19 -------------------
> 1 file changed, 19 deletions(-)
>
> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> index 126ce7716f..0ee680e55e 100644
> --- a/package/systemd/systemd.mk
> +++ b/package/systemd/systemd.mk
> @@ -863,35 +863,16 @@ define SYSTEMD_LINUX_CONFIG_FIXUPS
>
> $(call KCONFIG_ENABLE_OPT,CONFIG_DMIID)
>
> - $(call KCONFIG_ENABLE_OPT,CONFIG_BLK_DEV_BSG)
> -
This is listed as required for "Support for some SCSI devices serial
number retrieval":
https://github.com/systemd/systemd/blob/v258.2/README#L106-L108
> $(call KCONFIG_ENABLE_OPT,CONFIG_NET_NS)
>
> $(call KCONFIG_ENABLE_OPT,CONFIG_USER_NS)
>
> $(call KCONFIG_DISABLE_OPT,CONFIG_SYSFS_DEPRECATED)
>
> - $(call KCONFIG_ENABLE_OPT,CONFIG_IPV6)
> $(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS_FS)
> $(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS4_FS)
> $(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_POSIX_ACL)
> $(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_XATTR)
> - $(call KCONFIG_ENABLE_OPT,CONFIG_SECCOMP)
> - $(call KCONFIG_ENABLE_OPT,CONFIG_SECCOMP_FILTER)
> - $(call KCONFIG_ENABLE_OPT,CONFIG_KCMP)
> - $(call KCONFIG_ENABLE_OPT,CONFIG_NET_SCHED)
> - $(call KCONFIG_ENABLE_OPT,CONFIG_NET_SCH_FQ_CODEL)
These options are "Optional but strongly recommended":
https://github.com/systemd/systemd/blob/v258.2/README#L118-L128
> - $(call KCONFIG_ENABLE_OPT,CONFIG_CGROUP_SCHED)
> - $(call KCONFIG_ENABLE_OPT,CONFIG_FAIR_GROUP_SCHED)
These are "Required for CPUShares= in resource control unit settings":
https://github.com/systemd/systemd/blob/v258.2/README#L130-L132
> - $(call KCONFIG_ENABLE_OPT,CONFIG_CFS_BANDWIDTH)
This is "Required for CPUQuota= in resource control unit settings":
https://github.com/systemd/systemd/blob/v258.2/README#L134-L135
> -
> - $(call KCONFIG_ENABLE_OPT,CONFIG_EFIVAR_FS)
> - $(call KCONFIG_ENABLE_OPT,CONFIG_EFI_PARTITION)
These are required "For UEFI systems" :
https://github.com/systemd/systemd/blob/v258.2/README#L153-L155
> -
> - $(call KCONFIG_ENABLE_OPT,CONFIG_DMI)
> - $(call KCONFIG_ENABLE_OPT,CONFIG_DMI_SYSFS)
These are "Required for reading credentials from SMBIOS":
https://github.com/systemd/systemd/blob/v258.2/README#L166C9-L168
>
> $(call KCONFIG_DISABLE_OPT,CONFIG_RT_GROUP_SCHED)
>
> --
> 2.47.3
>
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH] package/systemd: remove several Kernel config options
2025-11-19 16:16 ` James Hilliard
@ 2025-11-19 16:32 ` Norbert Lange
2025-11-19 16:54 ` James Hilliard
0 siblings, 1 reply; 15+ messages in thread
From: Norbert Lange @ 2025-11-19 16:32 UTC (permalink / raw)
To: James Hilliard; +Cc: buildroot, Sen Hastings
Am Mi., 19. Nov. 2025 um 17:16 Uhr schrieb James Hilliard
<james.hilliard1@gmail.com>:
>
> On Wed, Nov 19, 2025 at 8:57 AM Norbert Lange <nolange79@gmail.com> wrote:
> >
> > All those features are optional and prevent customization of the kernel.
> > Forcing IPv6 is particularly nasty.
>
> What issue are you seeing from forcing IPV6?
Additional interfaces and functionality I don't want to see in an
embedded device
if I disable IPV6 in the kernel config.
>
> >
> > This reverts parts of "package/systemd: bump to version 256.4"
> >
> > Signed-off-by: Norbert Lange <nolange79@gmail.com>
> > ---
> > package/systemd/systemd.mk | 19 -------------------
> > 1 file changed, 19 deletions(-)
> >
> > diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> > index 126ce7716f..0ee680e55e 100644
> > --- a/package/systemd/systemd.mk
> > +++ b/package/systemd/systemd.mk
> > @@ -863,35 +863,16 @@ define SYSTEMD_LINUX_CONFIG_FIXUPS
> >
> > $(call KCONFIG_ENABLE_OPT,CONFIG_DMIID)
> >
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_BLK_DEV_BSG)
> > -
>
> This is listed as required for "Support for some SCSI devices serial
> number retrieval":
> https://github.com/systemd/systemd/blob/v258.2/README#L106-L108
I dont have SCSI
>
> > $(call KCONFIG_ENABLE_OPT,CONFIG_NET_NS)
> >
> > $(call KCONFIG_ENABLE_OPT,CONFIG_USER_NS)
> >
> > $(call KCONFIG_DISABLE_OPT,CONFIG_SYSFS_DEPRECATED)
> >
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_IPV6)
> > $(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS_FS)
> > $(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS4_FS)
> > $(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_POSIX_ACL)
> > $(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_XATTR)
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_SECCOMP)
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_SECCOMP_FILTER)
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_KCMP)
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_NET_SCHED)
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_NET_SCH_FQ_CODEL)
>
> These options are "Optional but strongly recommended":
> https://github.com/systemd/systemd/blob/v258.2/README#L118-L128
Yes, so let the user enable them if they need it. Buildroot is not the common
desktop system.
>
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_CGROUP_SCHED)
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_FAIR_GROUP_SCHED)
>
> These are "Required for CPUShares= in resource control unit settings":
> https://github.com/systemd/systemd/blob/v258.2/README#L130-L132
Yes, if you use them?
>
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_CFS_BANDWIDTH)
>
> This is "Required for CPUQuota= in resource control unit settings":
> https://github.com/systemd/systemd/blob/v258.2/README#L134-L135
Yes, if you use them?
>
> > -
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_EFIVAR_FS)
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_EFI_PARTITION)
>
> These are required "For UEFI systems" :
> https://github.com/systemd/systemd/blob/v258.2/README#L153-L155
Only if you want to manage the bootloader with systemd and from within
the system. Not really interesting for a setup that barely will be turned off.
> > -
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_DMI)
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_DMI_SYSFS)
>
> These are "Required for reading credentials from SMBIOS":
> https://github.com/systemd/systemd/blob/v258.2/README#L166C9-L168
What should I do with those?
I can read the Readme btw.
I used BR 2024.02 before, the system does what it should, its not a
user facing desktop system,
and I would want the kernel compiled as I specify it. Several of those
options complicate
setup or can impede realtime characteristics.
Now BR 2025.02 silently modifies the audited kernel config with stuff that's
- not needed to start
- not used by the service files shipping with systemd
- cant be prevented to be enabled
Its a valid scheme for Desktop systems to enable everything,
in automation its a liability.
regards, Norbert
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH] package/systemd: remove several Kernel config options
2025-11-19 15:48 [Buildroot] [PATCH] package/systemd: remove several Kernel config options Norbert Lange
2025-11-19 16:16 ` James Hilliard
@ 2025-11-19 16:47 ` Marcus Hoffmann via buildroot
2025-11-19 17:02 ` James Hilliard
2026-01-01 22:09 ` Thomas Petazzoni via buildroot
2 siblings, 1 reply; 15+ messages in thread
From: Marcus Hoffmann via buildroot @ 2025-11-19 16:47 UTC (permalink / raw)
To: Norbert Lange, buildroot; +Cc: Sen Hastings
Hi Norbert,
On 11/19/25 16:48, Norbert Lange wrote:
> All those features are optional and prevent customization of the kernel.
For the record, the list of kernel options required and recommended for
the currently packaged systemd version is here:
https://github.com/systemd/systemd/blob/v257.10/README
And I agree that we shouldn't force these optional (even if strongly
recommended) features. A link to this readme file should probably be
added to the Config.in help text instead of trying to replicate the
content there as well.
This still doesn't remove all options that the above document classifies
as optional though. Any particular reason to keep these?
CONFIG_DMIID
CONFIG_NET_NS
CONFIG_USER_NS [1]
CONFIG_AUTOFS_FS
CONFIG_AUTOFS4_FS
CONFIG_TMPFS_POSIX_ACL
CONFIG_TMPFS_XATTR
[1] There's a note here: "systemd-localed.service and other systemd
units use PrivateNetwork so this is effectively required." Not exactly
sure what that means for a buildroot system.
> Forcing IPv6 is particularly nasty.
>
> This reverts parts of "package/systemd: bump to version 256.4"
>
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
> ---
> package/systemd/systemd.mk | 19 -------------------
> 1 file changed, 19 deletions(-)
>
> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> index 126ce7716f..0ee680e55e 100644
> --- a/package/systemd/systemd.mk
> +++ b/package/systemd/systemd.mk
> @@ -863,35 +863,16 @@ define SYSTEMD_LINUX_CONFIG_FIXUPS
>
> $(call KCONFIG_ENABLE_OPT,CONFIG_DMIID)
>
> - $(call KCONFIG_ENABLE_OPT,CONFIG_BLK_DEV_BSG)
> -
> $(call KCONFIG_ENABLE_OPT,CONFIG_NET_NS)
>
> $(call KCONFIG_ENABLE_OPT,CONFIG_USER_NS)
>
> $(call KCONFIG_DISABLE_OPT,CONFIG_SYSFS_DEPRECATED)
>
> - $(call KCONFIG_ENABLE_OPT,CONFIG_IPV6)
> $(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS_FS)
> $(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS4_FS)
> $(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_POSIX_ACL)
> $(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_XATTR)
> - $(call KCONFIG_ENABLE_OPT,CONFIG_SECCOMP)
> - $(call KCONFIG_ENABLE_OPT,CONFIG_SECCOMP_FILTER)
> - $(call KCONFIG_ENABLE_OPT,CONFIG_KCMP)
> - $(call KCONFIG_ENABLE_OPT,CONFIG_NET_SCHED)
> - $(call KCONFIG_ENABLE_OPT,CONFIG_NET_SCH_FQ_CODEL)
> -
> - $(call KCONFIG_ENABLE_OPT,CONFIG_CGROUP_SCHED)
> - $(call KCONFIG_ENABLE_OPT,CONFIG_FAIR_GROUP_SCHED)
> -
> - $(call KCONFIG_ENABLE_OPT,CONFIG_CFS_BANDWIDTH)
> -
> - $(call KCONFIG_ENABLE_OPT,CONFIG_EFIVAR_FS)
> - $(call KCONFIG_ENABLE_OPT,CONFIG_EFI_PARTITION)
> -
> - $(call KCONFIG_ENABLE_OPT,CONFIG_DMI)
> - $(call KCONFIG_ENABLE_OPT,CONFIG_DMI_SYSFS)
>
> $(call KCONFIG_DISABLE_OPT,CONFIG_RT_GROUP_SCHED)
>
Marcus
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH] package/systemd: remove several Kernel config options
2025-11-19 16:32 ` Norbert Lange
@ 2025-11-19 16:54 ` James Hilliard
2025-11-19 17:39 ` Norbert Lange
0 siblings, 1 reply; 15+ messages in thread
From: James Hilliard @ 2025-11-19 16:54 UTC (permalink / raw)
To: Norbert Lange; +Cc: buildroot, Sen Hastings
On Wed, Nov 19, 2025 at 9:32 AM Norbert Lange <nolange79@gmail.com> wrote:
>
> Am Mi., 19. Nov. 2025 um 17:16 Uhr schrieb James Hilliard
> <james.hilliard1@gmail.com>:
> >
> > On Wed, Nov 19, 2025 at 8:57 AM Norbert Lange <nolange79@gmail.com> wrote:
> > >
> > > All those features are optional and prevent customization of the kernel.
> > > Forcing IPv6 is particularly nasty.
> >
> > What issue are you seeing from forcing IPV6?
>
> Additional interfaces and functionality I don't want to see in an
> embedded device
> if I disable IPV6 in the kernel config.
>
> >
> > >
> > > This reverts parts of "package/systemd: bump to version 256.4"
> > >
> > > Signed-off-by: Norbert Lange <nolange79@gmail.com>
> > > ---
> > > package/systemd/systemd.mk | 19 -------------------
> > > 1 file changed, 19 deletions(-)
> > >
> > > diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> > > index 126ce7716f..0ee680e55e 100644
> > > --- a/package/systemd/systemd.mk
> > > +++ b/package/systemd/systemd.mk
> > > @@ -863,35 +863,16 @@ define SYSTEMD_LINUX_CONFIG_FIXUPS
> > >
> > > $(call KCONFIG_ENABLE_OPT,CONFIG_DMIID)
> > >
> > > - $(call KCONFIG_ENABLE_OPT,CONFIG_BLK_DEV_BSG)
> > > -
> >
> > This is listed as required for "Support for some SCSI devices serial
> > number retrieval":
> > https://github.com/systemd/systemd/blob/v258.2/README#L106-L108
>
> I dont have SCSI
Then from my understanding this option will not actually get enabled
in the actual build since there is a dependency on SCSI here:
https://github.com/torvalds/linux/blob/v6.17/drivers/scsi/Kconfig#L158
>
> >
> > > $(call KCONFIG_ENABLE_OPT,CONFIG_NET_NS)
> > >
> > > $(call KCONFIG_ENABLE_OPT,CONFIG_USER_NS)
> > >
> > > $(call KCONFIG_DISABLE_OPT,CONFIG_SYSFS_DEPRECATED)
> > >
> > > - $(call KCONFIG_ENABLE_OPT,CONFIG_IPV6)
> > > $(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS_FS)
> > > $(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS4_FS)
> > > $(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_POSIX_ACL)
> > > $(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_XATTR)
> > > - $(call KCONFIG_ENABLE_OPT,CONFIG_SECCOMP)
> > > - $(call KCONFIG_ENABLE_OPT,CONFIG_SECCOMP_FILTER)
> > > - $(call KCONFIG_ENABLE_OPT,CONFIG_KCMP)
> > > - $(call KCONFIG_ENABLE_OPT,CONFIG_NET_SCHED)
> > > - $(call KCONFIG_ENABLE_OPT,CONFIG_NET_SCH_FQ_CODEL)
> >
> > These options are "Optional but strongly recommended":
> > https://github.com/systemd/systemd/blob/v258.2/README#L118-L128
>
> Yes, so let the user enable them if they need it. Buildroot is not the common
> desktop system.
I think in general we want to enable recommended systemd config options
by default, we could add a buildroot kconfig option to allow disabling them
however.
>
> >
> > > - $(call KCONFIG_ENABLE_OPT,CONFIG_CGROUP_SCHED)
> > > - $(call KCONFIG_ENABLE_OPT,CONFIG_FAIR_GROUP_SCHED)
> >
> > These are "Required for CPUShares= in resource control unit settings":
> > https://github.com/systemd/systemd/blob/v258.2/README#L130-L132
>
> Yes, if you use them?
Some package unit files presumably may use them?
> >
> > > - $(call KCONFIG_ENABLE_OPT,CONFIG_CFS_BANDWIDTH)
> >
> > This is "Required for CPUQuota= in resource control unit settings":
> > https://github.com/systemd/systemd/blob/v258.2/README#L134-L135
>
> Yes, if you use them?
Some package unit files presumably may use them as well?
>
> >
> > > -
> > > - $(call KCONFIG_ENABLE_OPT,CONFIG_EFIVAR_FS)
> > > - $(call KCONFIG_ENABLE_OPT,CONFIG_EFI_PARTITION)
> >
> > These are required "For UEFI systems" :
> > https://github.com/systemd/systemd/blob/v258.2/README#L153-L155
>
> Only if you want to manage the bootloader with systemd and from within
> the system. Not really interesting for a setup that barely will be turned off.
That's not entirely clear, EFIVAR_FS is only enabled on EFI systems:
https://github.com/torvalds/linux/blob/v6.17/fs/efivarfs/Kconfig#L4
I think EFI_PARTITION is needed for partition discovery features:
https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html
> > > -
> > > - $(call KCONFIG_ENABLE_OPT,CONFIG_DMI)
> > > - $(call KCONFIG_ENABLE_OPT,CONFIG_DMI_SYSFS)
> >
> > These are "Required for reading credentials from SMBIOS":
> > https://github.com/systemd/systemd/blob/v258.2/README#L166C9-L168
>
> What should I do with those?
There seems to be a decent bit of systemd functionality using dmi
sysfs in general.
>
> I can read the Readme btw.
>
> I used BR 2024.02 before, the system does what it should, its not a
> user facing desktop system,
> and I would want the kernel compiled as I specify it. Several of those
> options complicate
> setup or can impede realtime characteristics.
>
> Now BR 2025.02 silently modifies the audited kernel config with stuff that's
>
> - not needed to start
> - not used by the service files shipping with systemd
> - cant be prevented to be enabled
>
> Its a valid scheme for Desktop systems to enable everything,
> in automation its a liability.
Maybe these options should be split out into being kconfig controlled
by buildroot, with default enabled as presumably most people will
expect systemd to not have random broken functionality.
I don't think they should be removed entirely as having random
systemd features broken is a bit unexpected and difficult to debug.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH] package/systemd: remove several Kernel config options
2025-11-19 16:47 ` Marcus Hoffmann via buildroot
@ 2025-11-19 17:02 ` James Hilliard
0 siblings, 0 replies; 15+ messages in thread
From: James Hilliard @ 2025-11-19 17:02 UTC (permalink / raw)
To: Marcus Hoffmann; +Cc: Norbert Lange, buildroot, Sen Hastings
On Wed, Nov 19, 2025 at 9:47 AM Marcus Hoffmann via buildroot
<buildroot@buildroot.org> wrote:
>
> Hi Norbert,
>
> On 11/19/25 16:48, Norbert Lange wrote:
> > All those features are optional and prevent customization of the kernel.
>
> For the record, the list of kernel options required and recommended for
> the currently packaged systemd version is here:
> https://github.com/systemd/systemd/blob/v257.10/README
>
> And I agree that we shouldn't force these optional (even if strongly
> recommended) features. A link to this readme file should probably be
> added to the Config.in help text instead of trying to replicate the
> content there as well.
I think in general buildroot should enable at a minimum all recommended
systemd options by default, we can just do "default y" for buildroot kconfig
options.
Maybe have something like this in the systemd kconfig to gate
the recommended but not required options:
config SYSTEMD_RECOMMENDED_KERNEL_FEATURES
default y
I had enabled all recommended options just since I didn't see much of
a good reason to disable them in general as they should largely be
harmless if enabled while unused.
I don't think disabling them by default is a good idea since there's a high
probability of random breakage otherwise.
>
> This still doesn't remove all options that the above document classifies
> as optional though. Any particular reason to keep these?
>
> CONFIG_DMIID
> CONFIG_NET_NS
> CONFIG_USER_NS [1]
> CONFIG_AUTOFS_FS
> CONFIG_AUTOFS4_FS
> CONFIG_TMPFS_POSIX_ACL
> CONFIG_TMPFS_XATTR
>
> [1] There's a note here: "systemd-localed.service and other systemd
> units use PrivateNetwork so this is effectively required." Not exactly
> sure what that means for a buildroot system.
>
> > Forcing IPv6 is particularly nasty.
> >
> > This reverts parts of "package/systemd: bump to version 256.4"
> >
> > Signed-off-by: Norbert Lange <nolange79@gmail.com>
> > ---
> > package/systemd/systemd.mk | 19 -------------------
> > 1 file changed, 19 deletions(-)
> >
> > diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> > index 126ce7716f..0ee680e55e 100644
> > --- a/package/systemd/systemd.mk
> > +++ b/package/systemd/systemd.mk
> > @@ -863,35 +863,16 @@ define SYSTEMD_LINUX_CONFIG_FIXUPS
> >
> > $(call KCONFIG_ENABLE_OPT,CONFIG_DMIID)
> >
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_BLK_DEV_BSG)
> > -
> > $(call KCONFIG_ENABLE_OPT,CONFIG_NET_NS)
> >
> > $(call KCONFIG_ENABLE_OPT,CONFIG_USER_NS)
> >
> > $(call KCONFIG_DISABLE_OPT,CONFIG_SYSFS_DEPRECATED)
> >
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_IPV6)
> > $(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS_FS)
>
> > $(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS4_FS)
> > $(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_POSIX_ACL)
> > $(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_XATTR)
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_SECCOMP)
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_SECCOMP_FILTER)
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_KCMP)
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_NET_SCHED)
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_NET_SCH_FQ_CODEL)
> > -
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_CGROUP_SCHED)
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_FAIR_GROUP_SCHED)
> > -
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_CFS_BANDWIDTH)
> > -
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_EFIVAR_FS)
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_EFI_PARTITION)
> > -
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_DMI)
> > - $(call KCONFIG_ENABLE_OPT,CONFIG_DMI_SYSFS)
> >
> > $(call KCONFIG_DISABLE_OPT,CONFIG_RT_GROUP_SCHED)
> >
>
> Marcus
>
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH] package/systemd: remove several Kernel config options
2025-11-19 16:54 ` James Hilliard
@ 2025-11-19 17:39 ` Norbert Lange
2025-11-19 17:44 ` Norbert Lange
2025-11-19 18:18 ` James Hilliard
0 siblings, 2 replies; 15+ messages in thread
From: Norbert Lange @ 2025-11-19 17:39 UTC (permalink / raw)
To: James Hilliard; +Cc: buildroot, Sen Hastings
Am Mi., 19. Nov. 2025 um 17:54 Uhr schrieb James Hilliard
<james.hilliard1@gmail.com>:
>
> On Wed, Nov 19, 2025 at 9:32 AM Norbert Lange <nolange79@gmail.com> wrote:
> >
> > Am Mi., 19. Nov. 2025 um 17:16 Uhr schrieb James Hilliard
> > <james.hilliard1@gmail.com>:
> > >
> > > On Wed, Nov 19, 2025 at 8:57 AM Norbert Lange <nolange79@gmail.com> wrote:
> > > >
> > > > All those features are optional and prevent customization of the kernel.
> > > > Forcing IPv6 is particularly nasty.
> > >
> > > What issue are you seeing from forcing IPV6?
> >
> > Additional interfaces and functionality I don't want to see in an
> > embedded device
> > if I disable IPV6 in the kernel config.
> >
> > >
> > > >
> > > > This reverts parts of "package/systemd: bump to version 256.4"
> > > >
> > > > Signed-off-by: Norbert Lange <nolange79@gmail.com>
> > > > ---
> > > > package/systemd/systemd.mk | 19 -------------------
> > > > 1 file changed, 19 deletions(-)
> > > >
> > > > diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> > > > index 126ce7716f..0ee680e55e 100644
> > > > --- a/package/systemd/systemd.mk
> > > > +++ b/package/systemd/systemd.mk
> > > > @@ -863,35 +863,16 @@ define SYSTEMD_LINUX_CONFIG_FIXUPS
> > > >
> > > > $(call KCONFIG_ENABLE_OPT,CONFIG_DMIID)
> > > >
> > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_BLK_DEV_BSG)
> > > > -
> > >
> > > This is listed as required for "Support for some SCSI devices serial
> > > number retrieval":
> > > https://github.com/systemd/systemd/blob/v258.2/README#L106-L108
> >
> > I dont have SCSI
>
> Then from my understanding this option will not actually get enabled
> in the actual build since there is a dependency on SCSI here:
> https://github.com/torvalds/linux/blob/v6.17/drivers/scsi/Kconfig#L158
>
> >
> > >
> > > > $(call KCONFIG_ENABLE_OPT,CONFIG_NET_NS)
> > > >
> > > > $(call KCONFIG_ENABLE_OPT,CONFIG_USER_NS)
> > > >
> > > > $(call KCONFIG_DISABLE_OPT,CONFIG_SYSFS_DEPRECATED)
> > > >
> > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_IPV6)
> > > > $(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS_FS)
> > > > $(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS4_FS)
> > > > $(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_POSIX_ACL)
> > > > $(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_XATTR)
> > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_SECCOMP)
> > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_SECCOMP_FILTER)
> > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_KCMP)
> > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_NET_SCHED)
> > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_NET_SCH_FQ_CODEL)
> > >
> > > These options are "Optional but strongly recommended":
> > > https://github.com/systemd/systemd/blob/v258.2/README#L118-L128
> >
> > Yes, so let the user enable them if they need it. Buildroot is not the common
> > desktop system.
>
> I think in general we want to enable recommended systemd config options
> by default, we could add a buildroot kconfig option to allow disabling them
> however.
>
> >
> > >
> > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_CGROUP_SCHED)
> > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_FAIR_GROUP_SCHED)
> > >
> > > These are "Required for CPUShares= in resource control unit settings":
> > > https://github.com/systemd/systemd/blob/v258.2/README#L130-L132
> >
> > Yes, if you use them?
>
> Some package unit files presumably may use them?
>
> > >
> > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_CFS_BANDWIDTH)
> > >
> > > This is "Required for CPUQuota= in resource control unit settings":
> > > https://github.com/systemd/systemd/blob/v258.2/README#L134-L135
> >
> > Yes, if you use them?
>
> Some package unit files presumably may use them as well?
Not in systemd itself. perhaps the packages should enable the kernel option
if they depend on them.
> >
> > >
> > > > -
> > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_EFIVAR_FS)
> > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_EFI_PARTITION)
> > >
> > > These are required "For UEFI systems" :
> > > https://github.com/systemd/systemd/blob/v258.2/README#L153-L155
> >
> > Only if you want to manage the bootloader with systemd and from within
> > the system. Not really interesting for a setup that barely will be turned off.
>
> That's not entirely clear, EFIVAR_FS is only enabled on EFI systems:
> https://github.com/torvalds/linux/blob/v6.17/fs/efivarfs/Kconfig#L4
>
> I think EFI_PARTITION is needed for partition discovery features:
> https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html
Whats needed is efi=runtime, which is nowadays disabled when using PREEMPT_RT.
Accessing the EFI firmware directory can lock up the all CPU cores for hundreds
of microseconds (the joy of x86 SMM interrupts...).
There are some priorities if that could cost you larger sums of money,
I prefer having it not available at all.
>
> > > > -
> > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_DMI)
> > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_DMI_SYSFS)
> > >
> > > These are "Required for reading credentials from SMBIOS":
> > > https://github.com/systemd/systemd/blob/v258.2/README#L166C9-L168
> >
> > What should I do with those?
>
> There seems to be a decent bit of systemd functionality using dmi
> sysfs in general.
>
> >
> > I can read the Readme btw.
> >
> > I used BR 2024.02 before, the system does what it should, its not a
> > user facing desktop system,
> > and I would want the kernel compiled as I specify it. Several of those
> > options complicate
> > setup or can impede realtime characteristics.
> >
> > Now BR 2025.02 silently modifies the audited kernel config with stuff that's
> >
> > - not needed to start
> > - not used by the service files shipping with systemd
> > - cant be prevented to be enabled
> >
> > Its a valid scheme for Desktop systems to enable everything,
> > in automation its a liability.
>
> Maybe these options should be split out into being kconfig controlled
> by buildroot, with default enabled as presumably most people will
> expect systemd to not have random broken functionality.
>
> I don't think they should be removed entirely as having random
> systemd features broken is a bit unexpected and difficult to debug.
Systemd is a growing collection of tools, buildroot should aim to be minimal,
and atleast for my usecase it should be very cautious modifying kernel params.
That is unexpected to *me* and difficult to debug.
Systemd is rather chatty about missing kernel features BTW.
For easy start, default kernel configs could enable those features?
Otherwise the init system should merely be able to start the system,
a systemd rootfs can be pretty much as simple as an sysv rootfs.
I did not revert *every* change with this commit, so I am not an absolutist.
Options can be rather safe and widely useful.Others, particularly
those involving Bios
can have pretty bad sideffects.
regards, Norbert
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH] package/systemd: remove several Kernel config options
2025-11-19 17:39 ` Norbert Lange
@ 2025-11-19 17:44 ` Norbert Lange
2025-11-19 18:27 ` James Hilliard
2025-11-19 18:18 ` James Hilliard
1 sibling, 1 reply; 15+ messages in thread
From: Norbert Lange @ 2025-11-19 17:44 UTC (permalink / raw)
To: James Hilliard; +Cc: buildroot, Sen Hastings
PS. could KCONFIG_ENABLE_OPT do nothing if it finds "# CONFIG_$(OPT)
is not set"?
The biggest issue is that you cant opt-out of the automatic opt-in.
Norbert
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH] package/systemd: remove several Kernel config options
2025-11-19 17:39 ` Norbert Lange
2025-11-19 17:44 ` Norbert Lange
@ 2025-11-19 18:18 ` James Hilliard
1 sibling, 0 replies; 15+ messages in thread
From: James Hilliard @ 2025-11-19 18:18 UTC (permalink / raw)
To: Norbert Lange; +Cc: buildroot, Sen Hastings
On Wed, Nov 19, 2025 at 10:39 AM Norbert Lange <nolange79@gmail.com> wrote:
>
> Am Mi., 19. Nov. 2025 um 17:54 Uhr schrieb James Hilliard
> <james.hilliard1@gmail.com>:
> >
> > On Wed, Nov 19, 2025 at 9:32 AM Norbert Lange <nolange79@gmail.com> wrote:
> > >
> > > Am Mi., 19. Nov. 2025 um 17:16 Uhr schrieb James Hilliard
> > > <james.hilliard1@gmail.com>:
> > > >
> > > > On Wed, Nov 19, 2025 at 8:57 AM Norbert Lange <nolange79@gmail.com> wrote:
> > > > >
> > > > > All those features are optional and prevent customization of the kernel.
> > > > > Forcing IPv6 is particularly nasty.
> > > >
> > > > What issue are you seeing from forcing IPV6?
> > >
> > > Additional interfaces and functionality I don't want to see in an
> > > embedded device
> > > if I disable IPV6 in the kernel config.
> > >
> > > >
> > > > >
> > > > > This reverts parts of "package/systemd: bump to version 256.4"
> > > > >
> > > > > Signed-off-by: Norbert Lange <nolange79@gmail.com>
> > > > > ---
> > > > > package/systemd/systemd.mk | 19 -------------------
> > > > > 1 file changed, 19 deletions(-)
> > > > >
> > > > > diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> > > > > index 126ce7716f..0ee680e55e 100644
> > > > > --- a/package/systemd/systemd.mk
> > > > > +++ b/package/systemd/systemd.mk
> > > > > @@ -863,35 +863,16 @@ define SYSTEMD_LINUX_CONFIG_FIXUPS
> > > > >
> > > > > $(call KCONFIG_ENABLE_OPT,CONFIG_DMIID)
> > > > >
> > > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_BLK_DEV_BSG)
> > > > > -
> > > >
> > > > This is listed as required for "Support for some SCSI devices serial
> > > > number retrieval":
> > > > https://github.com/systemd/systemd/blob/v258.2/README#L106-L108
> > >
> > > I dont have SCSI
> >
> > Then from my understanding this option will not actually get enabled
> > in the actual build since there is a dependency on SCSI here:
> > https://github.com/torvalds/linux/blob/v6.17/drivers/scsi/Kconfig#L158
> >
> > >
> > > >
> > > > > $(call KCONFIG_ENABLE_OPT,CONFIG_NET_NS)
> > > > >
> > > > > $(call KCONFIG_ENABLE_OPT,CONFIG_USER_NS)
> > > > >
> > > > > $(call KCONFIG_DISABLE_OPT,CONFIG_SYSFS_DEPRECATED)
> > > > >
> > > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_IPV6)
> > > > > $(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS_FS)
> > > > > $(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS4_FS)
> > > > > $(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_POSIX_ACL)
> > > > > $(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_XATTR)
> > > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_SECCOMP)
> > > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_SECCOMP_FILTER)
> > > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_KCMP)
> > > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_NET_SCHED)
> > > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_NET_SCH_FQ_CODEL)
> > > >
> > > > These options are "Optional but strongly recommended":
> > > > https://github.com/systemd/systemd/blob/v258.2/README#L118-L128
> > >
> > > Yes, so let the user enable them if they need it. Buildroot is not the common
> > > desktop system.
> >
> > I think in general we want to enable recommended systemd config options
> > by default, we could add a buildroot kconfig option to allow disabling them
> > however.
> >
> > >
> > > >
> > > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_CGROUP_SCHED)
> > > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_FAIR_GROUP_SCHED)
> > > >
> > > > These are "Required for CPUShares= in resource control unit settings":
> > > > https://github.com/systemd/systemd/blob/v258.2/README#L130-L132
> > >
> > > Yes, if you use them?
> >
> > Some package unit files presumably may use them?
> >
> > > >
> > > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_CFS_BANDWIDTH)
> > > >
> > > > This is "Required for CPUQuota= in resource control unit settings":
> > > > https://github.com/systemd/systemd/blob/v258.2/README#L134-L135
> > >
> > > Yes, if you use them?
> >
> > Some package unit files presumably may use them as well?
>
> Not in systemd itself. perhaps the packages should enable the kernel option
> if they depend on them.
I guess one issue is that there may just be unit files in an overlay
using these options for various reasons, I'm not opposed to making
them optional but I think we probably want to enable recommended
systemd options by default.
>
> > >
> > > >
> > > > > -
> > > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_EFIVAR_FS)
> > > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_EFI_PARTITION)
> > > >
> > > > These are required "For UEFI systems" :
> > > > https://github.com/systemd/systemd/blob/v258.2/README#L153-L155
> > >
> > > Only if you want to manage the bootloader with systemd and from within
> > > the system. Not really interesting for a setup that barely will be turned off.
> >
> > That's not entirely clear, EFIVAR_FS is only enabled on EFI systems:
> > https://github.com/torvalds/linux/blob/v6.17/fs/efivarfs/Kconfig#L4
> >
> > I think EFI_PARTITION is needed for partition discovery features:
> > https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html
>
> Whats needed is efi=runtime, which is nowadays disabled when using PREEMPT_RT.
> Accessing the EFI firmware directory can lock up the all CPU cores for hundreds
> of microseconds (the joy of x86 SMM interrupts...).
>
> There are some priorities if that could cost you larger sums of money,
> I prefer having it not available at all.
Do services usually access the EFI firmware directory randomly after
the system is booted up? Hard to tell how likely this would be to cause
issues.
In any case I think allowing one to disable the setting of recommended
but not required systemd kconfig options in the buildroot systemd
package would be the best approach here.
>
> >
> > > > > -
> > > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_DMI)
> > > > > - $(call KCONFIG_ENABLE_OPT,CONFIG_DMI_SYSFS)
> > > >
> > > > These are "Required for reading credentials from SMBIOS":
> > > > https://github.com/systemd/systemd/blob/v258.2/README#L166C9-L168
> > >
> > > What should I do with those?
> >
> > There seems to be a decent bit of systemd functionality using dmi
> > sysfs in general.
> >
> > >
> > > I can read the Readme btw.
> > >
> > > I used BR 2024.02 before, the system does what it should, its not a
> > > user facing desktop system,
> > > and I would want the kernel compiled as I specify it. Several of those
> > > options complicate
> > > setup or can impede realtime characteristics.
> > >
> > > Now BR 2025.02 silently modifies the audited kernel config with stuff that's
> > >
> > > - not needed to start
> > > - not used by the service files shipping with systemd
> > > - cant be prevented to be enabled
> > >
> > > Its a valid scheme for Desktop systems to enable everything,
> > > in automation its a liability.
> >
> > Maybe these options should be split out into being kconfig controlled
> > by buildroot, with default enabled as presumably most people will
> > expect systemd to not have random broken functionality.
> >
> > I don't think they should be removed entirely as having random
> > systemd features broken is a bit unexpected and difficult to debug.
>
> Systemd is a growing collection of tools, buildroot should aim to be minimal,
> and atleast for my usecase it should be very cautious modifying kernel params.
> That is unexpected to *me* and difficult to debug.
> Systemd is rather chatty about missing kernel features BTW.
I think it varies quite a bit, some are chatty but it's also often not
very obvious which features are actually missing. There can also
be quite a lot of these warnings in some cases which creates a
lot of excess noise.
> For easy start, default kernel configs could enable those features?
> Otherwise the init system should merely be able to start the system,
> a systemd rootfs can be pretty much as simple as an sysv rootfs.
I think it's better to have a kconfig option in the systemd package to
control default the recommended systemd options. I don't think
we want to set these in default kernel configs arbitrarily either as
they probably should only be defaults when systemd is actually being
used.
> I did not revert *every* change with this commit, so I am not an absolutist.
> Options can be rather safe and widely useful.Others, particularly
> those involving Bios
> can have pretty bad sideffects.
These are all somewhat subjective, better to just leave an escape
hatch for users that need more control while still setting the
recommended config options. We've been setting them for quite
a while so any actual issues in practice from setting the
recommended config options are likely quite rare.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH] package/systemd: remove several Kernel config options
2025-11-19 17:44 ` Norbert Lange
@ 2025-11-19 18:27 ` James Hilliard
0 siblings, 0 replies; 15+ messages in thread
From: James Hilliard @ 2025-11-19 18:27 UTC (permalink / raw)
To: Norbert Lange; +Cc: buildroot, Sen Hastings
On Wed, Nov 19, 2025 at 10:44 AM Norbert Lange <nolange79@gmail.com> wrote:
>
> PS. could KCONFIG_ENABLE_OPT do nothing if it finds "# CONFIG_$(OPT)
> is not set"?
I'm guessing this might be a bit tricky, especially since kconfigs
can be somewhat layered, for example I use an in kernel default
kconfig then use a linux-extras.config to add a few more options,
I think KCONFIG_ENABLE_OPT functions similar to kconfig extras.
I think KCONFIG_ENABLE_OPT operates typically on the kernel
config after extras are applied and all the defaults are generated
so gating KCONFIG_ENABLE_OPT to do nothing like you suggest
would likely result in it just never doing anything at all.
>
> The biggest issue is that you cant opt-out of the automatic opt-in.
>
> Norbert
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH] package/systemd: remove several Kernel config options
2025-11-19 15:48 [Buildroot] [PATCH] package/systemd: remove several Kernel config options Norbert Lange
2025-11-19 16:16 ` James Hilliard
2025-11-19 16:47 ` Marcus Hoffmann via buildroot
@ 2026-01-01 22:09 ` Thomas Petazzoni via buildroot
2026-01-01 22:30 ` James Hilliard
2 siblings, 1 reply; 15+ messages in thread
From: Thomas Petazzoni via buildroot @ 2026-01-01 22:09 UTC (permalink / raw)
To: Norbert Lange; +Cc: buildroot, Sen Hastings, James Hilliard, Marcus Hoffmann
Hello Norbert, James, Marcus,
On Wed, 19 Nov 2025 16:48:18 +0100
Norbert Lange <nolange79@gmail.com> wrote:
> All those features are optional and prevent customization of the kernel.
> Forcing IPv6 is particularly nasty.
>
> This reverts parts of "package/systemd: bump to version 256.4"
>
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
Thanks for the patch, and thanks everyone for participating to the
discussion.
Buildroot's "philosophy" has always been to be reasonably minimal. So I
would tend to agree with both Norbert and Marcus that we should not
enable all possible options that may be needed for all possible
use-cases. We want to enable what's needed to get our systemd package
to "work" as-is, but not necessarily every possible feature that the
user may use through systemd unit files or specific features.
However, it would be good to draw a clear line, and rather than
applying Norbert's patch as-is, I'd prefer to see a commit that cleans
up those options, with a comment on top of SYSTEMD_LINUX_CONFIG_FIXUPS
that documents our "policy" on this, like "Following what's documented
at https://github.com/systemd/systemd/blob/v257.10/README, by enabling
all mandatory options, leaving disabled only 'recommended' options,
with the exception of A, B, C because blabla".
Norbert, or Marcus, do you think you could propose something like this?
Thanks a lot!
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH] package/systemd: remove several Kernel config options
2026-01-01 22:09 ` Thomas Petazzoni via buildroot
@ 2026-01-01 22:30 ` James Hilliard
2026-01-05 22:01 ` Norbert Lange
2026-01-06 9:39 ` Thomas Petazzoni via buildroot
0 siblings, 2 replies; 15+ messages in thread
From: James Hilliard @ 2026-01-01 22:30 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Norbert Lange, buildroot, Sen Hastings, Marcus Hoffmann
On Thu, Jan 1, 2026 at 3:09 PM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello Norbert, James, Marcus,
>
> On Wed, 19 Nov 2025 16:48:18 +0100
> Norbert Lange <nolange79@gmail.com> wrote:
>
> > All those features are optional and prevent customization of the kernel.
> > Forcing IPv6 is particularly nasty.
> >
> > This reverts parts of "package/systemd: bump to version 256.4"
> >
> > Signed-off-by: Norbert Lange <nolange79@gmail.com>
>
> Thanks for the patch, and thanks everyone for participating to the
> discussion.
>
> Buildroot's "philosophy" has always been to be reasonably minimal. So I
> would tend to agree with both Norbert and Marcus that we should not
> enable all possible options that may be needed for all possible
> use-cases. We want to enable what's needed to get our systemd package
> to "work" as-is, but not necessarily every possible feature that the
> user may use through systemd unit files or specific features.
IMO we should generally default to enabling the recommended options
as there are often good reasons for having those enabled.
In general I think we tend to default to enabling recommended options
from packages unless there is a good reason not to in most cases
already.
Also many packages include systemd unit files and it would often
be difficult to track which kernel features those unit files depend
on as most packages are likely to assume the system has any
recommended kernel options enabled.
> However, it would be good to draw a clear line, and rather than
> applying Norbert's patch as-is, I'd prefer to see a commit that cleans
> up those options, with a comment on top of SYSTEMD_LINUX_CONFIG_FIXUPS
> that documents our "policy" on this, like "Following what's documented
> at https://github.com/systemd/systemd/blob/v257.10/README, by enabling
> all mandatory options, leaving disabled only 'recommended' options,
> with the exception of A, B, C because blabla".
I think relying on users to manually configure recommended options
is probably going to cause a lot more issues.
IMO the better option is to have a default enabled kconfig option
that controls the recommended but not required fixups.
Or maybe a default disabled kconfig option that when selected
disables the recommended kernel option fixups?
Part of the issue is that most users probably aren't going to be
manually tracking all the systemd recommended kconfig options
so having them maintained as part of the package simplifies things
a lot in practice.
There may also be security implications if certain recommended
but not required kconfig fixups are disabled.
> Norbert, or Marcus, do you think you could propose something like this?
>
> Thanks a lot!
>
> Thomas
> --
> Thomas Petazzoni, co-owner and CEO, Bootlin
> Embedded Linux and Kernel engineering and training
> https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH] package/systemd: remove several Kernel config options
2026-01-01 22:30 ` James Hilliard
@ 2026-01-05 22:01 ` Norbert Lange
2026-01-06 9:39 ` Thomas Petazzoni via buildroot
1 sibling, 0 replies; 15+ messages in thread
From: Norbert Lange @ 2026-01-05 22:01 UTC (permalink / raw)
To: James Hilliard; +Cc: Thomas Petazzoni, buildroot, Sen Hastings, Marcus Hoffmann
[-- Attachment #1.1: Type: text/plain, Size: 4425 bytes --]
Am Do., 1. Jan. 2026 um 23:30 Uhr schrieb James Hilliard <
james.hilliard1@gmail.com>:
> On Thu, Jan 1, 2026 at 3:09 PM Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
> >
> > Hello Norbert, James, Marcus,
> >
> > On Wed, 19 Nov 2025 16:48:18 +0100
> > Norbert Lange <nolange79@gmail.com> wrote:
> >
> > > All those features are optional and prevent customization of the
> kernel.
> > > Forcing IPv6 is particularly nasty.
> > >
> > > This reverts parts of "package/systemd: bump to version 256.4"
> > >
> > > Signed-off-by: Norbert Lange <nolange79@gmail.com>
> >
> > Thanks for the patch, and thanks everyone for participating to the
> > discussion.
> >
> > Buildroot's "philosophy" has always been to be reasonably minimal. So I
> > would tend to agree with both Norbert and Marcus that we should not
> > enable all possible options that may be needed for all possible
> > use-cases. We want to enable what's needed to get our systemd package
> > to "work" as-is, but not necessarily every possible feature that the
> > user may use through systemd unit files or specific features.
>
> IMO we should generally default to enabling the recommended options
> as there are often good reasons for having those enabled.
>
systemd's recommendations are for everything + the kitchensink,
not the normal functionality.
> In general I think we tend to default to enabling recommended options
> from packages unless there is a good reason not to in most cases
> already.
>
generally thats a big generalization. systemd is more of a whole suite,
and the defaults/recommendations arent that of an embedded system.
(I upstreamed several patches to adopt systemd for this environment)
> Also many packages include systemd unit files and it would often
> be difficult to track which kernel features those unit files depend
> on as most packages are likely to assume the system has any
> recommended kernel options enabled.
>
Depending on the feature, systemd will mostly do as-good-as-possible
and output warnings to the log.
Rarely things will just not work, and easy to diagnose.
> > However, it would be good to draw a clear line, and rather than
> > applying Norbert's patch as-is, I'd prefer to see a commit that cleans
> > up those options, with a comment on top of SYSTEMD_LINUX_CONFIG_FIXUPS
> > that documents our "policy" on this, like "Following what's documented
> > at https://github.com/systemd/systemd/blob/v257.10/README, by enabling
> > all mandatory options, leaving disabled only 'recommended' options,
> > with the exception of A, B, C because blabla".
>
> I think relying on users to manually configure recommended options
> is probably going to cause a lot more issues.
>
> IMO the better option is to have a default enabled kconfig option
> that controls the recommended but not required fixups.
>
> Or maybe a default disabled kconfig option that when selected
> disables the recommended kernel option fixups?
>
> Part of the issue is that most users probably aren't going to be
> manually tracking all the systemd recommended kconfig options
> so having them maintained as part of the package simplifies things
> a lot in practice
I explicitely configure the kernel to have as little attack surface
as possible. Those things are competely opposed to that.
Maybe there should be a set of options to switch between one (or a few)
"managed" modes and a "custom" mode which will only add the kconfig
options that are absolutely needed.
Just thinking loud:
Splitting KCONFIG options for packages into a few variables:
REQUIRED, BASE, RECOMMEND and potentially DIS_* equivalents.
Dependend on the picked MODE different KCONFIGS are applied,
For diagnostics buildroot could output the BASE/RECOMMEND KCONFIGS
that werent applied (based on the MODE).
> There may also be security implications if certain recommended
> but not required kconfig fixups are disabled.
>
You think silently enabling kernel options like IPv6 between Buildroot
versions does not cause security implications?
IP4 is a magnitude easier to lock down via a NAT, IPv6 automatically poked
holes into our system. Hence my angry post.
> Norbert, or Marcus, do you think you could propose something like this?
>
I think some more discussion is necessary. Particalularly if we want some
global
options.
Norbert
[-- Attachment #1.2: Type: text/html, Size: 6307 bytes --]
[-- Attachment #2: Type: text/plain, Size: 150 bytes --]
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH] package/systemd: remove several Kernel config options
2026-01-01 22:30 ` James Hilliard
2026-01-05 22:01 ` Norbert Lange
@ 2026-01-06 9:39 ` Thomas Petazzoni via buildroot
2026-01-06 17:47 ` James Hilliard
1 sibling, 1 reply; 15+ messages in thread
From: Thomas Petazzoni via buildroot @ 2026-01-06 9:39 UTC (permalink / raw)
To: James Hilliard; +Cc: Norbert Lange, buildroot, Sen Hastings, Marcus Hoffmann
Hello James,
On Thu, 1 Jan 2026 15:30:01 -0700
James Hilliard <james.hilliard1@gmail.com> wrote:
> IMO we should generally default to enabling the recommended options
> as there are often good reasons for having those enabled.
I'm afraid this is not Buildroot's policy. Buildroot's policy is more
about minimalism. We want to enable the reasonably minimum set of
things needed for things to work, but not enable everything for every
possible use-case. This is why all packages are built with all optional
features disabled by default.
> In general I think we tend to default to enabling recommended options
> from packages unless there is a good reason not to in most cases
> already.
Nope, this is not what we should tend to. This statement goes
completely backwards with the 20+ years of Buildroot's history and
"philosophy".
> Also many packages include systemd unit files and it would often
> be difficult to track which kernel features those unit files depend
> on as most packages are likely to assume the system has any
> recommended kernel options enabled.
But with that reasoning, you could also be "but Qt applications can use
every possible feature in Qt, so when we build Qt, we should build
every single Qt module that exists on earth".
So no, we're not going to go down this route. Our users like Buildroot
minimalism, and we want to keep it that way. Of course, there's a
balance to find, as we want find to reasonably work fine out out the
box, but the right balance is not "enabling everything that might
potentially be needed".
Norbert: as I've stated in a previous e-mail, I'm fine with merging a
patch reducing the number of kernel options forcefully enabled by
systemd.mk. However, I'd like:
1. Our systemd unit tests to still work with this more minimal set of
options
2. This more minimal set of options to be based on good reasoning, and
that reasoning should be documented in systemd.mk.
Could you cook a patch in that direction? Please make sure to Cc me on
the patch.
Thanks a lot!
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH] package/systemd: remove several Kernel config options
2026-01-06 9:39 ` Thomas Petazzoni via buildroot
@ 2026-01-06 17:47 ` James Hilliard
0 siblings, 0 replies; 15+ messages in thread
From: James Hilliard @ 2026-01-06 17:47 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Norbert Lange, buildroot, Sen Hastings, Marcus Hoffmann
On Tue, Jan 6, 2026 at 2:40 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
>
> Hello James,
>
> On Thu, 1 Jan 2026 15:30:01 -0700
> James Hilliard <james.hilliard1@gmail.com> wrote:
>
> > IMO we should generally default to enabling the recommended options
> > as there are often good reasons for having those enabled.
>
> I'm afraid this is not Buildroot's policy. Buildroot's policy is more
> about minimalism. We want to enable the reasonably minimum set of
> things needed for things to work, but not enable everything for every
> possible use-case. This is why all packages are built with all optional
> features disabled by default.
In practice that isn't always the case as we often build packages with
all features enabled by default to reduce the amount of supported
feature combinations/kconfig options. We also enable a lot of features
automatically based on dependency availability as well for similar
reasons.
> > In general I think we tend to default to enabling recommended options
> > from packages unless there is a good reason not to in most cases
> > already.
>
> Nope, this is not what we should tend to. This statement goes
> completely backwards with the 20+ years of Buildroot's history and
> "philosophy".
I mean, we have a huge amount of packages that arguably don't
actually follow this philosophy all that strictly.
My understanding was that buildroot also tries to follow upstream
project default packaging/configuration recommendations in general
unless there is a good reason to diverge.
> > Also many packages include systemd unit files and it would often
> > be difficult to track which kernel features those unit files depend
> > on as most packages are likely to assume the system has any
> > recommended kernel options enabled.
>
> But with that reasoning, you could also be "but Qt applications can use
> every possible feature in Qt, so when we build Qt, we should build
> every single Qt module that exists on earth".
This is more of a practicality argument, a QT application missing a
feature presumably would fail at build time so missing features would
be much more obvious, while systemd service files missing features
will likely be much trickier to identify and could lead to tricky to identify
runtime issues. There's also likely a huge difference in disk space used
by QT application features compared with kernel features.
> So no, we're not going to go down this route. Our users like Buildroot
> minimalism, and we want to keep it that way. Of course, there's a
> balance to find, as we want find to reasonably work fine out out the
> box, but the right balance is not "enabling everything that might
> potentially be needed".
I'm not disagreeing that we should have a way to disable the
enabling of recommended but not required kernel features, I'm
just saying we should split these recommended kconfig options
under a buildroot kconfig option that will enable them when selected.
Something like a "enable recommended kernel features" inside the
systemd Config.in that would enable options in the same way as
we conditionally enable kernel features for
SYSTEMD_OOMD_LINUX_CONFIG_FIXUPS already:
https://github.com/buildroot/buildroot/blob/2025.11/package/systemd/systemd.mk#L537-L540
https://github.com/buildroot/buildroot/blob/2025.11/package/systemd/systemd.mk#L901
I would think it would make sense to enable the recommended
kernel features using "default y" in a buildroot Config.in as well
like we do already for many other systemd features.
I should note that there are already many recommended but not
required systemd features we enable by default already for
similar reasons, I would think following this same pattern makes
sense here as well for the recommended kernel features:
https://github.com/buildroot/buildroot/blob/2025.11/package/systemd/Config.in#L218
https://github.com/buildroot/buildroot/blob/2025.11/package/systemd/Config.in#L268
https://github.com/buildroot/buildroot/blob/2025.11/package/systemd/Config.in#L277
https://github.com/buildroot/buildroot/blob/2025.11/package/systemd/Config.in#L350
https://github.com/buildroot/buildroot/blob/2025.11/package/systemd/Config.in#L361
https://github.com/buildroot/buildroot/blob/2025.11/package/systemd/Config.in#L458
https://github.com/buildroot/buildroot/blob/2025.11/package/systemd/Config.in#L542
https://github.com/buildroot/buildroot/blob/2025.11/package/systemd/Config.in#L552
https://github.com/buildroot/buildroot/blob/2025.11/package/systemd/Config.in#L597
> Norbert: as I've stated in a previous e-mail, I'm fine with merging a
> patch reducing the number of kernel options forcefully enabled by
> systemd.mk. However, I'd like:
>
> 1. Our systemd unit tests to still work with this more minimal set of
> options
>
> 2. This more minimal set of options to be based on good reasoning, and
> that reasoning should be documented in systemd.mk.
>
> Could you cook a patch in that direction? Please make sure to Cc me on
> the patch.
>
> Thanks a lot!
>
> Thomas
> --
> Thomas Petazzoni, co-owner and CEO, Bootlin
> Embedded Linux and Kernel engineering and training
> https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2026-01-06 17:47 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-11-19 15:48 [Buildroot] [PATCH] package/systemd: remove several Kernel config options Norbert Lange
2025-11-19 16:16 ` James Hilliard
2025-11-19 16:32 ` Norbert Lange
2025-11-19 16:54 ` James Hilliard
2025-11-19 17:39 ` Norbert Lange
2025-11-19 17:44 ` Norbert Lange
2025-11-19 18:27 ` James Hilliard
2025-11-19 18:18 ` James Hilliard
2025-11-19 16:47 ` Marcus Hoffmann via buildroot
2025-11-19 17:02 ` James Hilliard
2026-01-01 22:09 ` Thomas Petazzoni via buildroot
2026-01-01 22:30 ` James Hilliard
2026-01-05 22:01 ` Norbert Lange
2026-01-06 9:39 ` Thomas Petazzoni via buildroot
2026-01-06 17:47 ` James Hilliard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox