Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
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 --]

      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