Re: Kernel specific branches question

[Johannes Berg <johannes@sipsolutions.net>]

Hi Dan,

> At Laird, we use backports for supporting our wireless modules,
> specifically using an unmodified brcmfmac, a fairly modified ath6kl,
> and an out of tree custom version of the non-upstreamed mwlwifi, and
> also using unmodified Bluetooth.  

:)

> At the moment, we are backporting our fork of the 4.9 kernel for
> those drivers.  I pulled a copy of the git repo a few months back and
> we have worked from that.  I’m wondering how we can help resurrect
> the process of having branches for specific kernel releases and the
> testing that was done for those as seen in this commit:
> https://git.kernel.org/pub/scm/linux/kernel/git/backports/backports.g
> it/commit/?h=linux-4.4.y&id=bec4037a54dd0e1a1aeefe7385faf82bac44d6a0

So the testing thing there is just the output from the "ckmake" script
that's there in the repository. It needs a bunch of disk space and lots
of CPU time, but otherwise shouldn't be that hard to do. We still have
the compat build box, and I still have a plan to put some kind of
automation in place, but haven't really had time for it yet.

However, this is pretty different from how most other people seem to
work?

Since kernel releases are sort of ephemeral, and drivers are
continually developed along with the kernel, we typically see usage
more of "latest backport + latest kernel" to get to "latest driver for
use on any kernel".

Additionally, backports for a fixed kernel version like 4.9 really
should be pretty stable, so once you have it, it shouldn't really need
to change? So it seems to me like a tag on master would be sufficient.

Now, we're not actually doing a good job of following any of upstream,
linux-next or wireless-testing with backports right now - we should
probably pick one of those, or multiple of those, and create branches
in the backports.git for each one of those, rather than having a
"master" branch.

To do that, I think we should actually set up a build bot to do a daily
tests of applying backports on those trees, and then compiling the
result on all (supported) kernels. This can then email the list, and
somebody can fix the issues.

Sounds like a plan?

Note that I'm going to go no sabbatical for July/August, so I won't be
working on this then either though.

johannes
--
To unsubscribe from this list: send the line "unsubscribe backports" in