[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20140611.153225.671693159592497903.davem@davemloft.net>
Date: Wed, 11 Jun 2014 15:32:25 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: milos.vyletel@...il.com
Cc: stephen@...workplumber.org, amwang@...hat.com,
netdev@...r.kernel.org, oliver@...kum.org, kuznet@....inr.ac.ru,
jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net,
pshelar@...ira.com, nicolas.dichtel@...nd.com,
mike.rapoport@...ellosystems.com, dborkman@...hat.com,
ogerlitz@...lanox.com, therbert@...gle.com,
hannes@...essinduktion.org, florent.fourcot@...t-bretagne.fr,
edumazet@...gle.com, Paul.Durrant@...rix.com,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch net-next 3/5] ipv6: consider net.ipv6.conf.all sysctls
when making decisions
From: Milos Vyletel <milos.vyletel@...il.com>
Date: Tue, 10 Jun 2014 13:49:35 -0400
> On Tue, Jun 10, 2014 at 1:13 PM, Stephen Hemminger
> <stephen@...workplumber.org> wrote:
>> On Tue, 10 Jun 2014 12:19:11 -0400
>> Milos Vyletel <milos.vyletel@...il.com> wrote:
>>
>>> As it is right now net.ipv6.conf.all.* are mostly ignored and instead
>>> we're only making decisions based on interface specific settings. These
>>> settings are coppied from net.ipv6.conf.default and changing either all
>>> or default settings have no effect.
>>
>> Although this is the right idea conceptually, it risks creating unhappy
>> users because it changes the semantics of the API. This will probably break
>> somebody's configuration.
>
> You're right but in this case I feel we are moving in the right
> direction. While the
> behavior will change in some cases this change is only adding well known ipv4
> behavior for ipv6 sysctls. In fact documentation briefly mentioned that
> net.ipv6.conf.all.* should change all the interface-specific settings
> but that was
> not the case until now.
You can't just break things on people, no matter how much you think the
current behavior is "poorly designed", "inconsistent with other areas of
the networking", etc. None of those things matter if you have to break
things on people to "fix" it.
I'm not applying this series, sorry.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists