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