|
|
|
|
|
|
| Author |
Message |
Sam Leffler
*nix forums addict
Joined: 20 Jun 2002
Posts: 75
|
 Posted: Sun Jul 09, 2006 7:12 pm Post subject:
vlans and cloning
|
|
|
I committed the revised netif cloning api so you can now specify
parameters when cloning. I also modified the vlan code to use this
mechanism so doing something like:
ifconfig vlan create vlan 1 vlandev em0
causes a single request to clone a vlan together with the tag+parent
device parameters (i.e. and no subsequent SIOCSETVLAN request).
Given the above do we still need to support setting vlan tag+device
separately or can we just require everything be specified when doing the
clone operation? This would change the user api but otherwise I can see
no reason for continuing to support the old mechanism where you do:
ifconfig vlan create
ifconfig vlan0 vlan 1 vlandev em0
Anyone _against_ nuking the above?
Sam
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
 |
Dmitry Pryanishnikov
*nix forums beginner
Joined: 01 Sep 2005
Posts: 13
|
| Posted: Mon Jul 10, 2006 7:44 am Post subject:
Re: vlans and cloning
|
|
|
Hello!
On Sun, 9 Jul 2006, Sam Leffler wrote:
| Quote: | clone operation? This would change the user api but otherwise I can see
no reason for continuing to support the old mechanism where you do:
ifconfig vlan create
ifconfig vlan0 vlan 1 vlandev em0
Anyone _against_ nuking the above?
|
Do you mean that you're going to nuke
ifconfig vlan create
but not
ifconfig vlan0 create
? As I understand the flow of /etc/rc processing, support of the
ifconfig vlan0 create
ifconfig vlan0 vlan 1 vlandev em0
sequence is required for now. Also, I thing it's perfectly correct to have
cloned_interfaces="vlan30"
while NOT having 'ifconfig_vlan30' assignment - system administrator could
just reserve a spare interface w/o assigning it's parameters. So I think
that possibility of the specific device cloning w/o arguments, e.g.,
ifconfig vlan30 create
should be preserved.
Sincerely, Dmitry
--
Atlantis ISP, System Administrator
e-mail: dmitry@atlantis.dp.ua
nic-hdl: LYNX-RIPE
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Andre Oppermann
*nix forums addict
Joined: 21 Mar 2002
Posts: 55
|
| Posted: Mon Jul 10, 2006 8:52 am Post subject:
Re: vlans and cloning
|
|
|
Sam Leffler wrote:
| Quote: | I committed the revised netif cloning api so you can now specify
parameters when cloning. I also modified the vlan code to use this
mechanism so doing something like:
ifconfig vlan create vlan 1 vlandev em0
causes a single request to clone a vlan together with the tag+parent
device parameters (i.e. and no subsequent SIOCSETVLAN request).
Given the above do we still need to support setting vlan tag+device
separately or can we just require everything be specified when doing the
clone operation? This would change the user api but otherwise I can see
no reason for continuing to support the old mechanism where you do:
ifconfig vlan create
ifconfig vlan0 vlan 1 vlandev em0
|
/me wants to do:
"ifconfig em0.1 inet 192.168.2.2/24"
Even simpler. And yes, this works already but only if if_vlan.ko
was loaded before or compiled into the kernel. It doesn't do auto-
load.
--
Andre
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Maxim Konovalov
*nix forums beginner
Joined: 23 Mar 2004
Posts: 15
|
| Posted: Mon Jul 10, 2006 9:02 am Post subject:
Re: vlans and cloning
|
|
|
[...]
| Quote: | This would change the user api but otherwise I can see no reason for
continuing to support the old mechanism where you do:
ifconfig vlan create
ifconfig vlan0 vlan 1 vlandev em0
Anyone _against_ nuking the above?
|
As you said it will break POLA and a number of scripts outside our
tree. If it doesn't cost much for us I wouldn't killed "ifconfig vlan
create".
--
Maxim Konovalov
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Sam Leffler
*nix forums addict
Joined: 20 Jun 2002
Posts: 75
|
| Posted: Mon Jul 10, 2006 3:24 pm Post subject:
Re: vlans and cloning
|
|
|
Dmitry Pryanishnikov wrote:
| Quote: |
Hello!
On Sun, 9 Jul 2006, Sam Leffler wrote:
clone operation? This would change the user api but otherwise I can see
no reason for continuing to support the old mechanism where you do:
ifconfig vlan create
ifconfig vlan0 vlan 1 vlandev em0
Anyone _against_ nuking the above?
Do you mean that you're going to nuke
ifconfig vlan create
but not
ifconfig vlan0 create
|
No, you can still specify the name of the cloned device.
| Quote: |
? As I understand the flow of /etc/rc processing, support of the
ifconfig vlan0 create
ifconfig vlan0 vlan 1 vlandev em0
sequence is required for now. Also, I thing it's perfectly correct to have
cloned_interfaces="vlan30"
while NOT having 'ifconfig_vlan30' assignment - system administrator
could just reserve a spare interface w/o assigning it's parameters. So I
think
that possibility of the specific device cloning w/o arguments, e.g.,
ifconfig vlan30 create
should be preserved.
|
Clearly one would need to fix rc scripts. The question is should the
old behaviour be preserved; it provides no functionality--i.e. a cloned
device is unusable until you set the tag+parent and you cannot set the
tag or parent on an existing cloned device (once setup). So the only
benefit to the ability to create a usable vlan device in 2 steps is to
preserve existing practice. Removing the 2 step procedure would allow
code to be removed and (IMO) clarify how a vlan is crafted. In the
future there will be cloned devices that cannot/will-not be specified
with a 2-step procedure so having vlans work this way will violate POLA.
Sam
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Sam Leffler
*nix forums addict
Joined: 20 Jun 2002
Posts: 75
|
| Posted: Mon Jul 10, 2006 3:25 pm Post subject:
Re: vlans and cloning
|
|
|
Andre Oppermann wrote:
| Quote: | Sam Leffler wrote:
I committed the revised netif cloning api so you can now specify
parameters when cloning. I also modified the vlan code to use this
mechanism so doing something like:
ifconfig vlan create vlan 1 vlandev em0
causes a single request to clone a vlan together with the tag+parent
device parameters (i.e. and no subsequent SIOCSETVLAN request).
Given the above do we still need to support setting vlan tag+device
separately or can we just require everything be specified when doing the
clone operation? This would change the user api but otherwise I can see
no reason for continuing to support the old mechanism where you do:
ifconfig vlan create
ifconfig vlan0 vlan 1 vlandev em0
/me wants to do:
"ifconfig em0.1 inet 192.168.2.2/24"
|
That can still be done and is just different syntax to ifconfig.
| Quote: |
Even simpler. And yes, this works already but only if if_vlan.ko
was loaded before or compiled into the kernel. It doesn't do auto-
load.
|
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Sam Leffler
*nix forums addict
Joined: 20 Jun 2002
Posts: 75
|
| Posted: Mon Jul 10, 2006 3:26 pm Post subject:
Re: vlans and cloning
|
|
|
Maxim Konovalov wrote:
| Quote: | [...]
This would change the user api but otherwise I can see no reason for
continuing to support the old mechanism where you do:
ifconfig vlan create
ifconfig vlan0 vlan 1 vlandev em0
Anyone _against_ nuking the above?
As you said it will break POLA and a number of scripts outside our
tree. If it doesn't cost much for us I wouldn't killed "ifconfig vlan
create".
|
As I said in separate mail having the 2-step procedure provides no
functionality and in the future (when I bring in virtual ap support for
the wireless system) it will not be possible to create cloned wlan
devices w/ a 2-step process.
Sam
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Brooks Davis
*nix forums addict
Joined: 14 Jun 2002
Posts: 97
|
| Posted: Mon Jul 10, 2006 4:04 pm Post subject:
Re: vlans and cloning
|
|
|
On Mon, Jul 10, 2006 at 10:52:33AM +0200, Andre Oppermann wrote:
| Quote: | Sam Leffler wrote:
I committed the revised netif cloning api so you can now specify
parameters when cloning. I also modified the vlan code to use this
mechanism so doing something like:
ifconfig vlan create vlan 1 vlandev em0
causes a single request to clone a vlan together with the tag+parent
device parameters (i.e. and no subsequent SIOCSETVLAN request).
Given the above do we still need to support setting vlan tag+device
separately or can we just require everything be specified when doing the
clone operation? This would change the user api but otherwise I can see
no reason for continuing to support the old mechanism where you do:
ifconfig vlan create
ifconfig vlan0 vlan 1 vlandev em0
/me wants to do:
"ifconfig em0.1 inet 192.168.2.2/24"
Even simpler. And yes, this works already but only if if_vlan.ko
was loaded before or compiled into the kernel. It doesn't do auto-
load.
|
Unless cause ifconfig to autoload all if_ modules when cloning fails,
it's impossiable to support this without having if_vlan loaded. That
said the current plan it to eliminate if_vlan and integrate vlan support
directly into if_ethersubr.c to allow use to correctly handle the
default vlan case among otherthings.
-- Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 |
|
| Back to top |
|
|
Dmitry Pryanishnikov
*nix forums beginner
Joined: 01 Sep 2005
Posts: 13
|
| Posted: Mon Jul 10, 2006 6:24 pm Post subject:
Re: vlans and cloning
|
|
|
Hello!
On Mon, 10 Jul 2006, Sam Leffler wrote:
| Quote: | ifconfig vlan0 create
ifconfig vlan0 vlan 1 vlandev em0
sequence is required for now. Also, I thing it's perfectly correct to have
cloned_interfaces="vlan30"
while NOT having 'ifconfig_vlan30' assignment - system administrator
could just reserve a spare interface w/o assigning it's parameters. So I
think
that possibility of the specific device cloning w/o arguments, e.g.,
ifconfig vlan30 create
should be preserved.
Clearly one would need to fix rc scripts. The question is should the
old behaviour be preserved; it provides no functionality--i.e. a cloned
device is unusable until you set the tag+parent and you cannot set the
tag or parent on an existing cloned device (once setup). So the only
|
I don't agree:
1) Cloned but unset device is perfectly legal for, e.g., mentioning
in ipfw rules (or any other context which requires interface name);
2) Sure, you _can_ change tag+parent afterwards:
root@homelynx# ifconfig vlan32 create
root@homelynx# ifconfig vlan32 vlan 32 vlandev rl0
root@homelynx# ifconfig vlan32 -vlandev
root@homelynx# ifconfig vlan32 vlan 33 vlandev rl0
root@homelynx#
| Quote: | preserve existing practice. Removing the 2 step procedure would allow
code to be removed and (IMO) clarify how a vlan is crafted. In the
future there will be cloned devices that cannot/will-not be specified
with a 2-step procedure so having vlans work this way will violate POLA.
|
Please don't break well-known and useful behaviour! Remember that it allows
to switch easily physical vlanXXX device assignment (e.g., migration to the
another trunk) w/o reloading firewall rules.
Sincerely, Dmitry
--
Atlantis ISP, System Administrator
e-mail: dmitry@atlantis.dp.ua
nic-hdl: LYNX-RIPE
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Sam Leffler
*nix forums addict
Joined: 20 Jun 2002
Posts: 75
|
| Posted: Mon Jul 10, 2006 6:53 pm Post subject:
Re: vlans and cloning
|
|
|
Dmitry Pryanishnikov wrote:
| Quote: |
Hello!
On Mon, 10 Jul 2006, Sam Leffler wrote:
ifconfig vlan0 create
ifconfig vlan0 vlan 1 vlandev em0
sequence is required for now. Also, I thing it's perfectly correct to
have
cloned_interfaces="vlan30"
while NOT having 'ifconfig_vlan30' assignment - system administrator
could just reserve a spare interface w/o assigning it's parameters. So I
think
that possibility of the specific device cloning w/o arguments, e.g.,
ifconfig vlan30 create
should be preserved.
Clearly one would need to fix rc scripts. The question is should the
old behaviour be preserved; it provides no functionality--i.e. a cloned
device is unusable until you set the tag+parent and you cannot set the
tag or parent on an existing cloned device (once setup). So the only
I don't agree:
1) Cloned but unset device is perfectly legal for, e.g., mentioning
in ipfw rules (or any other context which requires interface name);
2) Sure, you _can_ change tag+parent afterwards:
root@homelynx# ifconfig vlan32 create
root@homelynx# ifconfig vlan32 vlan 32 vlandev rl0
root@homelynx# ifconfig vlan32 -vlandev
root@homelynx# ifconfig vlan32 vlan 33 vlandev rl0
root@homelynx#
|
Hmm, that did not work yesterday in my testing. That's the answer I've
been looking for. Thank you. OTOH I can easily see that plumbing a
vlan into firewall rules and then changing it's configuration might
generate very hard to find bugs; but whatever.
| Quote: |
preserve existing practice. Removing the 2 step procedure would allow
code to be removed and (IMO) clarify how a vlan is crafted. In the
future there will be cloned devices that cannot/will-not be specified
with a 2-step procedure so having vlans work this way will violate POLA.
Please don't break well-known and useful behaviour! Remember that it
allows
to switch easily physical vlanXXX device assignment (e.g., migration to the
another trunk) w/o reloading firewall rules.
|
I've got no plans. You'll note I committed the new stuff as completely
separate. I only asked now because I saw an opportunity to remove
cruft. But given that it's used that cruft can just stay around.
Sam
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Dmitry Pryanishnikov
*nix forums beginner
Joined: 01 Sep 2005
Posts: 13
|
| Posted: Mon Jul 10, 2006 7:23 pm Post subject:
Re: vlans and cloning
|
|
|
On Mon, 10 Jul 2006, Sam Leffler wrote:
| Quote: | root@homelynx# ifconfig vlan32 create
root@homelynx# ifconfig vlan32 vlan 32 vlandev rl0
root@homelynx# ifconfig vlan32 -vlandev
root@homelynx# ifconfig vlan32 vlan 33 vlandev rl0
root@homelynx#
Hmm, that did not work yesterday in my testing. That's the answer I've
been looking for. Thank you. OTOH I can easily see that plumbing a
vlan into firewall rules and then changing it's configuration might
generate very hard to find bugs; but whatever.
|
This (changing vlan binding w/o device destruction) is very handy for
providing software-assisted failover in some hardware configurations.
Suppose you have 2 VLAN trunks (say fxp2 and fxp3) which (via different
physical media) are connected to the same remote switch (which demultiplexes
VLANs to the different clients). Changing 'vlandev' on-the-fly (actually
removing old parent with -vlandev, then assigning the new one), you
can just move all vlans from e.g. fxp2 to fxp3 (in the event of fxp2's
hardware link failure) w/o touching the firewall. I had this scheme in
production during several months, and didn't see any bugs (under RELENG_4,
but I doubt that such a simple yet efficient feature is broken
in newer branches).
| Quote: | Please don't break well-known and useful behaviour! Remember that it
allows
to switch easily physical vlanXXX device assignment (e.g., migration to the
another trunk) w/o reloading firewall rules.
I've got no plans. You'll note I committed the new stuff as completely
separate. I only asked now because I saw an opportunity to remove
cruft. But given that it's used that cruft can just stay around.
|
I hope I've managed to show that it isn't a cruft ;)
Sincerely, Dmitry
--
Atlantis ISP, System Administrator
e-mail: dmitry@atlantis.dp.ua
nic-hdl: LYNX-RIPE
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Andrew Thompson
*nix forums beginner
Joined: 24 May 2005
Posts: 11
|
| Posted: Mon Jul 10, 2006 8:27 pm Post subject:
Re: vlans and cloning
|
|
|
On Mon, Jul 10, 2006 at 09:04:41AM -0700, Brooks Davis wrote:
| Quote: | On Mon, Jul 10, 2006 at 10:52:33AM +0200, Andre Oppermann wrote:
Sam Leffler wrote:
I committed the revised netif cloning api so you can now specify
parameters when cloning. I also modified the vlan code to use this
mechanism so doing something like:
ifconfig vlan create vlan 1 vlandev em0
/me wants to do:
"ifconfig em0.1 inet 192.168.2.2/24"
Even simpler. And yes, this works already but only if if_vlan.ko
was loaded before or compiled into the kernel. It doesn't do auto-
load.
Unless cause ifconfig to autoload all if_ modules when cloning fails,
it's impossiable to support this without having if_vlan loaded. That
said the current plan it to eliminate if_vlan and integrate vlan support
directly into if_ethersubr.c to allow use to correctly handle the
default vlan case among otherthings.
|
Is anyone working on this? The bridge code needs access to the vlan tag
to properly hash the address as each vlan is a seperate broadcast
domain, this would be much easier with vlan merged to if_ethersubr.c.
Andrew
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Brooks Davis
*nix forums addict
Joined: 14 Jun 2002
Posts: 97
|
| Posted: Tue Jul 11, 2006 4:29 pm Post subject:
Re: vlans and cloning
|
|
|
On Tue, Jul 11, 2006 at 08:27:14AM +1200, Andrew Thompson wrote:
| Quote: | On Mon, Jul 10, 2006 at 09:04:41AM -0700, Brooks Davis wrote:
On Mon, Jul 10, 2006 at 10:52:33AM +0200, Andre Oppermann wrote:
Sam Leffler wrote:
I committed the revised netif cloning api so you can now specify
parameters when cloning. I also modified the vlan code to use this
mechanism so doing something like:
ifconfig vlan create vlan 1 vlandev em0
/me wants to do:
"ifconfig em0.1 inet 192.168.2.2/24"
Even simpler. And yes, this works already but only if if_vlan.ko
was loaded before or compiled into the kernel. It doesn't do auto-
load.
Unless cause ifconfig to autoload all if_ modules when cloning fails,
it's impossiable to support this without having if_vlan loaded. That
said the current plan it to eliminate if_vlan and integrate vlan support
directly into if_ethersubr.c to allow use to correctly handle the
default vlan case among otherthings.
Is anyone working on this? The bridge code needs access to the vlan tag
to properly hash the address as each vlan is a seperate broadcast
domain, this would be much easier with vlan merged to if_ethersubr.c.
|
I think it ended up with Robert's name on it at the last devsummit, but
he's got a lot of higher priority stuff on his plate. It doesn't look
like this change would be all that much work. The one thing that might
be worth investigating is seeing if there's a sane way to make vlan tag
parsing part of ether_input, but keep if_vlan.c around as a module for
actual support of trunks so we get most of the architectural benefits of
correctly treating vlan tags as part of the spec, but let embedded
users who don't need trunks avoid the overhead.
-- Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 |
|
| Back to top |
|
|
Robert Watson
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 218
|
| Posted: Tue Jul 11, 2006 10:51 pm Post subject:
Re: vlans and cloning
|
|
|
On Tue, 11 Jul 2006, Brooks Davis wrote:
| Quote: | Unless cause ifconfig to autoload all if_ modules when cloning fails, it's
impossiable to support this without having if_vlan loaded. That said the
current plan it to eliminate if_vlan and integrate vlan support directly
into if_ethersubr.c to allow use to correctly handle the default vlan case
among otherthings.
Is anyone working on this? The bridge code needs access to the vlan tag to
properly hash the address as each vlan is a seperate broadcast domain, this
would be much easier with vlan merged to if_ethersubr.c.
I think it ended up with Robert's name on it at the last devsummit, but he's
got a lot of higher priority stuff on his plate. It doesn't look like this
change would be all that much work. The one thing that might be worth
investigating is seeing if there's a sane way to make vlan tag parsing part
of ether_input, but keep if_vlan.c around as a module for actual support of
trunks so we get most of the architectural benefits of correctly treating
vlan tags as part of the spec, but let embedded users who don't need trunks
avoid the overhead.
|
Yes -- the specific proposal I have made is that we combine if_vlan.c into
if_ethersubr.c, as well as LLC encapsulation decapsulation. Vlans and LLC
bits are all considered standard ethernet features today, and integrating the
basic support (regardless of virtual interfaces) into if_ethersubr.c makes
sense. It would also make the book keeping and event handling go a bit more
naturally, I think. I've not had a chance to prototype this to explore what
the above words actually mean, so I think some experimental prototyping is
called for. It's on my todo list but something I'm likely not to get to for a
few months, so if someone else wants to look into this, I think that would be
great.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Andrew Thompson
*nix forums beginner
Joined: 24 May 2005
Posts: 11
|
| Posted: Tue Jul 11, 2006 11:29 pm Post subject:
Re: vlans and cloning
|
|
|
On Tue, Jul 11, 2006 at 11:51:49PM +0100, Robert Watson wrote:
| Quote: | On Tue, 11 Jul 2006, Brooks Davis wrote:
Unless cause ifconfig to autoload all if_ modules when cloning fails,
it's impossiable to support this without having if_vlan loaded. That
said the current plan it to eliminate if_vlan and integrate vlan support
directly into if_ethersubr.c to allow use to correctly handle the
default vlan case among otherthings.
Is anyone working on this? The bridge code needs access to the vlan tag
to properly hash the address as each vlan is a seperate broadcast domain,
this would be much easier with vlan merged to if_ethersubr.c.
I think it ended up with Robert's name on it at the last devsummit, but
he's got a lot of higher priority stuff on his plate. It doesn't look
like this change would be all that much work. The one thing that might be
worth investigating is seeing if there's a sane way to make vlan tag
parsing part of ether_input, but keep if_vlan.c around as a module for
actual support of trunks so we get most of the architectural benefits of
correctly treating vlan tags as part of the spec, but let embedded users
who don't need trunks avoid the overhead.
Yes -- the specific proposal I have made is that we combine if_vlan.c into
if_ethersubr.c, as well as LLC encapsulation decapsulation. Vlans and LLC
bits are all considered standard ethernet features today, and integrating
the basic support (regardless of virtual interfaces) into if_ethersubr.c
makes sense. It would also make the book keeping and event handling go a
bit more naturally, I think. I've not had a chance to prototype this to
explore what the above words actually mean, so I think some experimental
prototyping is called for. It's on my todo list but something I'm likely
not to get to for a few months, so if someone else wants to look into this,
I think that would be great.
|
This is something I can start working on, all keep the interested
parties informed.
Andrew
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Sun Nov 23, 2008 1:07 pm | All times are GMT
|
|
ModernForums | Myspace Backgrounds | Car Loan | Myspace Backgrounds | Myspace Comments
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
