Re: [Buildroot] [PATCH 3/3] configs: update defconfigs with custom versions to BR2_LINUX_KERNEL_LATEST_X_Y

[Baruch Siach via buildroot <buildroot@buildroot.org>]

Hi Titouan,

On Sun, Oct 11 2026, Titouan Christophe wrote:
> On 11/10/26 18:45, Baruch Siach wrote:
>> On Sat, Oct 10 2026, Titouan Christophe via buildroot wrote:
>>> Update all defconfigs that are using a custom Linux version based on a
>>> longterm supported Linux version so they use the newly introduced symbols.
>> This is a significant policy change for Buildroot. The configs/
>> directory is meant to carry configurations that are "known to work",
>> according to adding-board-support section in Buildroot manual
>> (docs/manual/adding-board-support.adoc).
>
> Thank you for raising that concern ! I am currently preparing a v2 of this
> patch (with many other fixups), and I will update the manual accordingly.
>> Automatic update of the kernel component without actual hardware test
>> risks introducing regressions that make the system unbootable.
>
> This is a tradeoff, really.
> On one hand (A), there is the risk of breaking the functionality of a board by
> bumping from one patch version to another.
> On the other (B), any new Linux patch version brings a handful of security
> fixes, and this happens on a weekly basis.

The basic question is what are these deconfigs meant to achieve? My
understanding is that defconfigs demonstrate hardware working with a Buildroot
generated image. For many users this is the first Buildroot step. Hardware
bring-up is non trivial, and defconfigs preserve a known working state for a
given target system. defconfig is only an enabler for new users.

> Now onto practical considerations and my opinions:
> - From my understanding, (A) is not very frequent when bumping from one patch
>   version to another. It can certainly happen on a specific board from time to
>   time, but this is definitely far from the general case. If you (or anyone
>   else) have some recent examples of such situations, I'd be glad to read
>   about them. On the contrary bugs in core components that would affect all
>   boards, such as the ext4 corruption introduced in linux 6.1.64, would be
>  more easily controllable tree-wise with such a mechanism.

I have seen cases where trivial changes broke essential functionality. In one
case I remember a removed print broke two different network PHYs on the same
board because of missing proper initialization delay.

The current suggestion does not even preserve the original user tested
kernel version. By the time a defconfig reaches master branch, the
kernel is different. If this commit is accepted, I think we should
provide a way to preserve somehow the information of user tested kernel
version.

> - We see that many boards in the Buildroot tree are updated very infrequently,
>   and are using old kernel versions, sometimes lagging more than 200 versions
>   behind (see for example configs/minnowboard_max_defconfig). This is not a
>  good sign for newcomers.

I agree we should remove unmaintained defconfigs after a given time of
inactivity. But I'm not sure blind kernel version updates make the state of
these platforms much better.

> - Each kernel version bump for a single board is a patch that has to be
>   reviewed and applied by a maintainer. I believe their time is better
>   invested into patches that need actual effort, especially given the current
>  patchwork backlog

This commit only saves stable kernel version updates. These patches are
trivial. We can think of a fast track mechanism that allows contributor to
assert some newer kernel version works on a given hardware, and automatically
generate a matching commit.

The point here is to preserve the vital information contributors provide
of tested software.

> - From my LTS steward perspective, it is practically unfeasible to apply linux
>   version bumps on the maintained branches, because their minor kernel
>   versions differ from master. On the other hand we try to deliver on the
>   premise of improved security, hence getting security updates in due time.
>
> With all that being said:
> - Linux kernel versions are still stated explicitly in Buildroot and are
>   bumped with patches that follow the usual review process. They would only be
>  declared in a central place.
> - It is still possible to pin a particular linux kernel version to a board
>  with BR2_LINUX_KERNEL_CUSTOM_VERSION if needed
>>
>> For this reason adding-board-support section also says:
>>
>>> Always use fixed versions or commit hashes for the different
>>> components, not the "latest" version.
>> If we intend to change this policy I think we should discuss the
>> motivation on the list. In case such discussion did take place, this
>> comment should reference that discussion. In any case, the manual should
>> also update to reflect the current policy.
>
> I indeed brought the discussion in person with the maintainers that were
> present at the Buildroot Developers meeting after ELC, but I should be more
> verbose in writing, I will pay more attention to that in v2. If you have
> anything else to bring to the discussion, please let me know as well.

Thanks,
baruch

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot