netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: "John W. Linville" <linville@tuxdriver.com>
Cc: hadi@cyberus.ca, netdev@vger.kernel.org,
	David Miller <davem@davemloft.net>,
	Christophe Devriese <Christophe.Devriese@eurid.eu>
Subject: Re: Linville's L2 rant... -- Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
Date: Tue, 01 Aug 2006 10:04:24 -0700	[thread overview]
Message-ID: <44CF8998.3000408@candelatech.com> (raw)
In-Reply-To: <20060801165218.GF29208@tuxdriver.com>

John W. Linville wrote:
> On Tue, Aug 01, 2006 at 09:10:06AM -0700, Ben Greear wrote:
> 
>>Jamal Hadi Salim wrote:
> 
> 
>>>Agreed. I have some very strong opinions on this subject that i could
>>>share with you if you want. For example, IMO, I think it would be a lot
>>>reasonable to assume that a VLAN or VLANS are attributes of a netdevice
>>>(just like IP addresses or MAC addresses are). 
>>
>>As might be expected, I feel that VLANs are much more
>>useful as full-featured net devices.  I do not believe it is worth
>>decreasing functionality to try to 'clean up' the code.
> 
> 
> In general, I agree that we shouldn't lose functionality.
> 
> I'm curious as to what particularly functionality you fear would be
> lost if VLANs were not implemented the way they are now?

Well, Jamal and I and others discussed this in depth in the 2.4.12 time frame
when VLANs where about to go into the kernel.  Basically, my point is that
if VLANs are true devices, they will just work with all of the user-space protocols
and they will easily handle abstractions such as bridges, (multiple) IP addresses, MAC addresses,
net-filter, and all the rest.

Sounds like Jamal still remembers his reasons for wanting it otherwise...so
will let him describe his reasons.

Nothing is set in stone in Linux, and I am certainly not the final arbiter of
what gets into the linux kernel, but in my opinion, the current VLAN architecture
is supperior to the ip-alias model, and I see no reason to make any significant
changes.

Ben

> 
> Thanks,
> 
> John


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


  reply	other threads:[~2006-08-01 17:05 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-28  9:44 PATCH Fix bonding active-backup behavior for VLAN interfaces Christophe Devriese
2006-07-28 16:01 ` Ben Greear
2006-07-28 21:50   ` Christophe Devriese
2006-07-28 21:55     ` Ben Greear
2006-07-28 22:15       ` Christophe Devriese
     [not found]       ` <20060728221455.GA25610@walrus.eth1.org>
     [not found]         ` <44CA8AF1.3020408@candelatech.com>
2006-07-28 22:58           ` Christophe Devriese
2006-07-28 22:55             ` David Miller
2006-07-28 23:14               ` Ben Greear
2006-07-31  3:50       ` David Miller
2006-07-31  8:15         ` Christophe Devriese
2006-07-31 12:30           ` Linville's L2 rant... -- " John W. Linville
2006-07-31 16:48             ` Christophe Devriese
2006-08-01  1:39             ` Jamal Hadi Salim
2006-08-01 12:08               ` John W. Linville
2006-08-01 12:33                 ` Jamal Hadi Salim
2006-08-01 16:10                   ` Ben Greear
2006-08-01 16:52                     ` John W. Linville
2006-08-01 17:04                       ` Ben Greear [this message]
2006-08-01 19:47                         ` Krzysztof Halasa
2006-08-01 16:48                   ` John W. Linville
2006-08-01 16:17                 ` Ben Greear
2006-08-01 17:03                   ` John W. Linville
2006-08-01 17:21                     ` Ben Greear
2006-08-02  9:02                       ` Christophe Devriese
2006-08-02 17:37                         ` Stackable devices Stephen Hemminger
2006-08-02 17:50                           ` Ben Greear
2006-08-08 12:03                             ` Christophe Devriese
2006-08-08 16:36                               ` Ben Greear
2006-08-09 13:57                                 ` Christophe Devriese
2006-08-12 18:43                                   ` Ben Greear
2006-08-12 19:29                                   ` Ben Greear
2006-08-02 20:58           ` PATCH Fix bonding active-backup behavior for VLAN interfaces David Miller
2006-08-03  9:18             ` Krzysztof Oledzki
2006-08-10 18:18               ` Krzysztof Oledzki
2006-08-11  6:45                 ` David Miller
2006-08-11  8:50                   ` Christophe Devriese
2006-08-11  8:53                     ` David Miller
2006-08-14  8:16                   ` Christophe Devriese
2006-08-14  8:47                     ` David Miller
2006-08-14  8:47                     ` David Miller
2006-08-03 13:34             ` Christophe Devriese
2006-08-04  1:01             ` Jay Vosburgh
2006-08-15  0:09               ` David Miller
2006-08-15 22:18                 ` Jay Vosburgh
2006-08-15 22:27                   ` David Miller
2006-08-16 19:30                 ` Krzysztof Oledzki
2006-08-20 19:41                 ` Christophe Devriese

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=44CF8998.3000408@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=Christophe.Devriese@eurid.eu \
    --cc=davem@davemloft.net \
    --cc=hadi@cyberus.ca \
    --cc=linville@tuxdriver.com \
    --cc=netdev@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).