> On 19 Jul 2018, at 17:08, Toke Høiland-Jørgensen <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
