[OpenWrt-Devel] Proposal for managing the kernel patches.

Daniel Santos daniel.santos at pobox.com
Sun Nov 4 22:12:22 EST 2018

I had a discussion about this on irc a few weeks ago as well and I am in
favor.  There are just far too many reasons to list for the OpenWRT
kernel to exist as a set of branches in git.  Among them are the ability
to move patches around, cherry-pick and git-blame.  It is often very
important to understand the rationale of a particular change and this is
fairly easy to determine in gitk (presuming the patch was well documented).

Done properly, this should greatly reduce the burden of upgrading and
even backporting.  There are a vast array of git tools that this would
enable -- most of which kernel programmers are *used* to having and tend
to feel naked without.

However, there is one elephant in the living room here and it has pooped
on the carpet:  target/linux/*/files.  These are a particular
abomination because they aren't connected to any patches and have no
explanation for existing.  Each of these changes will need to be
associated with a documented change.

Which brings me to yet another reason for the OpenWRT kernel to be in
git: discipline. One does not simply walk into git with a tree of 65
files that are added/overwritten without explanation. :)

BTW, I have a few kernel debugging-related patches that still aren't
quite ready for submission, but I think we need a HOWTO somewhere for
this as I find myself trying to explain too much in the Kconfig help.


On 11/01/2018 01:20 PM, Ben Greear wrote:
> I just had a good discussion with jow about this on irc, thought I'd put
> my ideas in email form in case others are interested.
> In my opinion, it is difficult to develop against the current model of
> local
> kernel patches and backports patches.  So, I am thinking something
> like this
> might be a better approach.
> Fork the kernel that we want to use for a base (4.19, for instance). 
> Apply the
> existing patches one at a time to this tree.  Push this tree to
> github.  Auto-create
> tarballs as needed, put them somewhere openwrt can download them.
> Now, openwrt can select a kernel to use, which is one of these
> tarballs during
> compile time.
> It should be easy to select different kernels with a small makefile
> tweak (and no need
> to deal with local patches conflicting).  And, we can do 'stable'
> backport patches for
> older kernels like upstream does.
> In addition, the openwrt kernel can be easily compiled for and
> installed on a desktop OS which might
> make debugging easier.
> When it is time to start developing on a new kernel, clone a new one,
> use 'git am'
> to create the old patch-set, and then apply it on the new kernel. 
> Push that tree
> upstream as a new github repo  (so we can easily have a 4.19 kernel as
> well as 4.14, etc).
> I'd also like to somehow cram backports into this same tree, but not
> sure how reasonable
> that is...maybe not worth the effort.
> Thanks,
> Ben

openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list