From: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] Removing kmod-sched-cake package from openwrt
Date: Fri, 20 Jul 2018 09:45:13 +0000 [thread overview]
Message-ID: <72DA14F1-9E89-4615-BB3D-2DB30D9B15D0@darbyshire-bryant.me.uk> (raw)
In-Reply-To: <87fu0f2oop.fsf@toke.dk>
[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]
> 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
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2018-07-20 9:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-19 15:53 Kevin Darbyshire-Bryant
2018-07-19 16:06 ` Jonathan Morton
2018-07-19 16:08 ` Toke Høiland-Jørgensen
2018-07-20 9:45 ` Kevin Darbyshire-Bryant [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=72DA14F1-9E89-4615-BB3D-2DB30D9B15D0@darbyshire-bryant.me.uk \
--to=kevin@darbyshire-bryant.me.uk \
--cc=cake@lists.bufferbloat.net \
--cc=toke@toke.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox