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 Mon, Oct 12 2026, Titouan Christophe wrote:
> Good morning Baruch,
>
> Thank you very much for your detailed answer and taking the time to question
> crucial parts of this patch, I really appreciate !
>
> On 12/10/26 08:04, Baruch Siach wrote:
>> 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.
>
> Indeed, this discussion should address the intended role of in-tree
> defconfigs.
> My personal opinion on this role:
> - They provide (as you say) a first entry into Buildroot for many users.
> - However, I believe they should build a somewhat up-to-date system, and
>   demonstrate ways for users to keep their boards up to date.
> - There could be other packages that are key to the board functioning normally
>   (such as firmware blobs, host tools involved in the target image
>   finalization, ...), and these packages receive version bumps as well,
>   without being set in the  board's config. I would even expect them to break
>  less often with up-to-date kernels (but this is speculation)
>>
>>> 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
>
> How frequently have you seen such breakages ?

I remember many cases of regression debugging after kernel/U-Boot/TF-A
updates.

> I believe they shouldn't happen that often, they are very hardware
> specific, and should be easily fixed by temporarily pinning the kernel
> to a previous version, until the bug is resolved in linux.

Being hardware specific is indeed our problem. Also, we need to preserve
the identity of said "previous version" for version pinning to work. New
user will have hard time finding the known working kernel.

> We could even argue that this could help unveil such breakages to report them
> upstream, but this is another question :-)

Of course. But you need access to target hardware for bugs to come up,
and a skilled engineer to debug. New users are unlikely to do that.

>> 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.
>
> That is indeed a very valid point. Would you mean having an entry in the
> board's README, or a comment in the defconfig; basically a human-written note
> stating "this board was tested successfully on <date> with <kernel version>" ?
> Any other suggestion ?

That is possible. I find the current defconfig method easiest. But if
updated kernel version takes priority, then maybe keep the known working
defconfig somewhere else.

baruch

> As Arnout suggested in his reply, maybe we could only start with qemu boards
> for now, as they can easily be tested in the CI. Then add this feature for
> configs where a matching board is available for automated testing; although
> I've never heard of any board farm associated with the Buildroot project.
>
>>> - 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.
>
> As you said earlier, board bringup is not always trivial, so I would find it
> "sad" that we eliminate defconfigs solely because nobody is submitting
> frequent kernel updates to them; while they could still serve as a reference
> for similar platforms.
>
>>> - 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.
>
> Yes indeed, but even looking at the backlog to find trivial patches costs some
> maintainer time, and in any case increases the cognitive overhead for them.
>
>> The point here is to preserve the vital information contributors provide
>> of tested software.
>
> Agreed !
>
> Kind regards,
> Titouan

-- 
                                                     ~. .~   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