Re: [PATCH] tc: fix build failure with Linux >= 6.8 kernel headers (CBQ removal)

On Thu, 20 Aug 2026 20:04:17 +0200
Emmanuel Deloget via busybox <[email protected]> wrote:

> Hi,
> 
> Le mar. 18 août 2026 à 12:26, Guillermo Rodriguez Garcia via busybox
> <[email protected]> a écrit :
> >
> > El mar, 18 ago 2026 a las 11:55, Michael Tokarev via busybox
> > (<[email protected]>) escribió:
> > >
> > > On 8/17/26 00:55, tito via busybox wrote:
> > >
> > > > as far as I understand with the proposed fix the
> > > > tc applet will only work with the kernel it is compiled with,
> > > > if you use a busybox tc applet compiled with kernel 6.12.103
> > > > it will not work with 6.7.0 and cbq , this could be seen as a shortcoming.
> > > > Please take a look at my proposed patch which fixes building
> > > > busybox and allows use with all kernels at the expense
> > > > of a little size increase.
> > >
> > > If you build your busybox with recent kernel headers (it has nothing
> > > to do with the kernel, only kernel headers actually matters), - it is
> > > unlikely you'll run it on outdated kernels.  And even on kernel 6.7,
> > > this subsystem were deprecated already.  So personally, I see no reason
> > > to keep building something when it's clear it wont be used.
> >
> > In embedded systems, where busybox is widely used, it is actually
> > quite common for the toolchain, including the kernel headers it
> > provides, to be older than the kernel running on the target.
> > Toolchains tend to have a much longer lifetime and are not necessarily
> > updated together with the target kernel.
> 
> I don't think this should be encouraged. At the very minimum, the libc
> shall be built using the headers of your target kernel, and your
> toolchain might be otherwise up to date. I understand that this is not
> always possible but when it is, this should be the default settings
> (nobody wants to build a software as important as busybox against a
> tool chain with known vulnerabilities, especially when the goal is to
> push busybox on an embedded platform).

Hi,

This really is to fix busybox __NOT__  building against new headers.
There were  patches proposed on the list to fix this
and more on the internet. But in the end there are not 
so many solutions:

1) we don't care about older kernels and keeping existing functionality
     than we rip out the offending code (in iproute2 tc
     cbq_print_opt was removed in version 6.6) or hide it
     behind #if 0

2)  we preserve the offending code and make sure it is compiled 
      to prevent bitrot.

3)  we hide it behind a CONFIG_TC_CBQ

> > I think it makes sense for busybox built against older kernel headers
> > to remain usable with newer kernels, and vice-versa where possible.
> 
> Building busybox against the header of a newer kernel might produce
> binaries that cannot run on an older kernel -- new system calls, new
> flag values... might be removed or introduced and used in the possibly
> statically linked libc.  Linux (tries to) make sure that a binary you
> build on an old version of Linux will still run on a newer version,
> but it does not guarantee you the other way - and this is especially
> true if you add another layer of indirection such as a libc (extreme
> case in point: glibc's open(3) uses openat(2) that might not be
> present on an older system (kernel version < 2.6.16 ; yeah, I said
> "extreme" :D )).
> 
> In this case, a busybox binary compiled against older headers might
> work on a newer kernel - although I have a hard time following what
> parse_rtattr() would do in this case, so I would not assume that it
> indeed works, and maybe some more tests are required here (the fact
> that the constants were present and allowed programs to be compiled
> and work without the underlying CBQ code in the kernel would indicate
> that the busybox code might work in this case).
> 
> Do we really want to make the claim that a busybox binary compiled on
> a recent kernel will also work as expected when executed on an older
> kernel? 

We cannot make this claim because it does not compile
on a newer kernel unless you disable the tc applet.

In other parts of the busybox code we do conditional
things depending on the kernel version:

sysklogd/syslogd.c:     if (get_linux_version_code() < KERNEL_VERSION(3,5,0))
util-linux/mount.c:     kernel_version = get_linux_version_code();
modutils/rmmod.c:       n = ENABLE_FEATURE_2_4_MODULES && get_linux_version_code() < KERNEL_VERSION(2,6,0);
modutils/lsmod.c:        && get_linux_version_code() < KERNEL_VERSION(2,6,0)
modutils/modutils.c:    if (get_linux_version_code() < KERNEL_VERSION(2,6,0))

we even have devfsd which to my surprise still compiles.

So, no busybox does not make any claim, but as the busybox
codebase evolved through the years there was some
effort put in to keep things that did work (with previous
kernel versions) working later on if needed.
I don't think that busybox supported only the latest 
linux kernel version , never heard about that.

Just think about embedded device's kernels e.g. smartphones
(or other similar devices) where the vendor just released
a heavily modified kernel source once that is not portable to
newer kernels, it is not that you want to use a older
kernel, firmware, toolchain, you have to use it because there is 
no viable alternative if you want continue to use your device.

In the end any fix that makes busybox compile cleanly is good,
but please fix it.

Ciao
Tito

>In my opinion, this is not a good idea. If you agree with me
> then the form of the patch (not the patch itself, I did not try to
> judge it) might be good enough (with the caveat outlined in the
> previous paragraph) ; if it is expected that a binary compiled with
> the 6.8 kernel headers displays the CBQ information when executed on
> kernel <6.3 then the patch is not enough. But again, in my opinion,
> this is not a good idea.
> 
> > Best regards,
> >
> > Guillermo Rodriguez Garcia
> > [email protected]
> 
> Best regards,
> 
> -- Emmanuel Deloget
> _______________________________________________
> busybox mailing list
> [email protected]
> https://lists.busybox.net/mailman/listinfo/busybox

_______________________________________________
busybox mailing list
[email protected]
https://lists.busybox.net/mailman/listinfo/busybox