> On 19 Jul 2018, at 17:08, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> Yeah, considered doing a backport patch to the kernel in openwrt. But I
> concluded it was not worth the trouble, since we already have a working
> module from the main repo.

I’m coming to a similar conclusion.  The motivation came from the recent experience of trying to bump cake on openwrt 17.01.5 where I forgot about and fell into the trap that kernel/kmod packages stay at the tagged released version…even if the kmod package is bumped, but the userspace utilities assume backwards compatibility even if bumped and get rebuilt on a frequent basis.  Of course our recent upstreaming cake efforts led to a number of ABI ‘tweaks’, which now should I hope basically stop…. or change in backward compatible way.

> 
> If you do want to go the kernel patch route, it's a matter of figuring
> out which patches you'll need to add to the backport series. Basically,
> figure out which parts of the patch doesn't work, run git blame on the
> file it is being applied to, and find the previous patch that changes
> the context. Add that to you stack of backported patches, and rinse and
> repeat until your series applies.

It looks to me that there are quite a few large changes in this area so have run away for the moment :-)
Curiously the openwrt kernel is built without builtin conntrack support, it being added as a module.. I think.

> 
> Your call whether that is less work that keeping your name on the
> maintainer list until Openwrt naturally progresses past kernel 4.19 :)

It’s not really an issue per se, but ‘one less package’ has an attraction.  As you say, the problem is self limiting given time.

> 
> -Toke


Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A