All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Harvell <joe.harvell@tekcomms.com>
To: Stephen Hemminger <shemming@brocade.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Vadim Kochan <vadim4j@gmail.com>
Subject: Re: [PATCH]: iproute2: enhance enforcement of ifconfig compatible address labels and allow non-compatible ones with -force
Date: Tue, 24 Mar 2015 17:55:36 -0500	[thread overview]
Message-ID: <5511EB68.5070604@tekcomms.com> (raw)
In-Reply-To: <20150324151114.7168de0b@urahara>

Le 24/03/2015 17:11, Stephen Hemminger a écrit :
> On Sat, 21 Mar 2015 17:55:02 +0000
> Joe Harvell <joe.harvell@tekcomms.com> wrote:
>
>> The ip addr command today rejects address labels that would break
>> ifconfig.  However, it allows some labels which still break it. Enhance
>> enforcement to reject all known incompatible labels, and allow the
>> existing -force option to allow someone to use a label even if it is not
>> ifconfig compatible
>>
>> Make existing -force option of ip addr add skip enforcment of ifconfig
>> compatible address labels.
>> Change enforcement to properly reject labels that do begin with
>> <devname> but are followed by a string that does not begin with colon.
>>
>>
>> The following changes since commit 4612d04d6b8f07274bd5d0688f717ccc189499ad:
>>
>>     tc class: Show class names from file (2015-03-15 12:27:40 -0700)
>>
>> are available in the git repository at:
>>
>>     git@github.com:jharvell/iproute2.git addr-label-noncompat
>>
>> for you to fetch changes up to 6a1d09e93ae1fb4f7f1cd5981813af918e8efc88:
> Not really enthusiastic about this. It seems to introduce more issues
> and I don't consider it a big issue. If user is creating labels with
> ip and it breaks ifconfig, it is really a case of shooting themselves
> in the foot; or the fact that ifconfig needs to die (or get fixed).
Actually, I agree.  My real motivation for this change is to be able to
create labels that are currently being rejected.  I did this through
a -force option because I assumed no one would agree to remove the
enforcement altogether.  When I noticed during my testing that the
existing enforcement doesn't even catch all the lables that break ifconfig,
I decided to enhance it.  But I'm totally fine with just removing the 
existing
enforcement altogether.

  reply	other threads:[~2015-03-24 23:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4edec6f657e24e98b938c3ad76b54625@BRMWP-EXMB11.corp.brocade.com>
2015-03-24 22:11 ` [PATCH]: iproute2: enhance enforcement of ifconfig compatible address labels and allow non-compatible ones with -force Stephen Hemminger
2015-03-24 22:55   ` Joe Harvell [this message]
2015-03-21 17:55 Joe Harvell

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5511EB68.5070604@tekcomms.com \
    --to=joe.harvell@tekcomms.com \
    --cc=netdev@vger.kernel.org \
    --cc=shemming@brocade.com \
    --cc=vadim4j@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.