It is pushed but in a 'squash' branch for review purposes before it gets
merged into master.

Let me ask things in a different way, and as I've had time to think
about the implications of these changes:  By changing how 'squash' is
enabled I've currently broken backwards compatibility between 'new
squash' cake and 'old squash' tc.  Now, bearing in mind that this isn't
upstream yet...how concerned are we/should I be for 'new cake' vs 'old
tc' compatibility?  Again having thought about it more, I'm pretty sure
I can make 'new cake' and 'old tc' work....is it worth the bother?

Kevin

On 16/11/15 18:47, Dave Taht wrote:
> push it then.
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi
>
>
> On Mon, Nov 16, 2015 at 7:43 PM, Kevin Darbyshire-Bryant
> <kevin@darbyshire-bryant.me.uk> wrote:
>>
>> On 16/11/15 18:35, Dave Taht wrote:
>>> switch (q->tin_mode) { case CAKE_MODE_SQUASH: case
>>> CAKE_MODE_BESTEFFORT: default: cake_config_besteffort(sch); break;
>>>
>>> ?
>>> Dave Täht
>>> Let's go make home routers and wifi faster! With better software!
>>> https://www.gofundme.com/savewifi
>>>
>> Are you sure you're looking at the 'squash' branch Dave?  The 'smarts'
>> of automatically selecting 'besteffort' in the presence of 'squash' has
>> been put into 'tc'.  Thus 'squash' on its own behaves as it always did
>> for backwards compatibility.  'squash' in combination with
>> 'diffserv4/precedence' etc also works as expected.
>>
>> There's also a 'nosquash' option to disable squashing on a 'tc change'
>> if required.  That code now looks like:
>>
>>         switch (q->tin_mode) {
>>         case CAKE_MODE_BESTEFFORT:
>>         default:
>>                 cake_config_besteffort(sch);
>>                 break;
>> ........
>>
>>
>>
>>
>>
>>