* [PATCH 05/15] dec netdev: relocate DIGITAL based drivers to legacy
From: Paul Gortmaker @ 2010-10-29 1:19 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1288315159-1350-1-git-send-email-paul.gortmaker@windriver.com>
DEC as a name brand has been gone for over 10 years, and these
drivers represent technology from the 1990's like the venerable
ISA bus. Hence relocate them to the legacy dir.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/Kconfig | 63 -----------------------------------
drivers/net/Makefile | 4 --
drivers/net/legacy/Kconfig | 63 +++++++++++++++++++++++++++++++++++
drivers/net/legacy/Makefile | 5 +++
drivers/net/{ => legacy}/declance.c | 0
drivers/net/{ => legacy}/defxx.c | 0
drivers/net/{ => legacy}/defxx.h | 0
drivers/net/{ => legacy}/depca.c | 0
drivers/net/{ => legacy}/depca.h | 0
drivers/net/{ => legacy}/ewrk3.c | 0
drivers/net/{ => legacy}/ewrk3.h | 0
11 files changed, 68 insertions(+), 67 deletions(-)
rename drivers/net/{ => legacy}/declance.c (100%)
rename drivers/net/{ => legacy}/defxx.c (100%)
rename drivers/net/{ => legacy}/defxx.h (100%)
rename drivers/net/{ => legacy}/depca.c (100%)
rename drivers/net/{ => legacy}/depca.h (100%)
rename drivers/net/{ => legacy}/ewrk3.c (100%)
rename drivers/net/{ => legacy}/ewrk3.h (100%)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 511745d..fb58ea7 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1104,19 +1104,6 @@ config AT1700
To compile this driver as a module, choose M here. The module
will be called at1700.
-config DEPCA
- tristate "DEPCA, DE10x, DE200, DE201, DE202, DE422 support"
- depends on ISA || EISA || MCA
- select CRC32
- ---help---
- If you have a network (Ethernet) card of this type, say Y and read
- the Ethernet-HOWTO, available from
- <http://www.tldp.org/docs.html#howto> as well as
- <file:drivers/net/depca.c>.
-
- To compile this driver as a module, choose M here. The module
- will be called depca.
-
config HP100
tristate "HP 10/100VG PCLAN (ISA, EISA, PCI) support"
depends on ISA || EISA || PCI
@@ -1157,20 +1144,6 @@ config E2100
To compile this driver as a module, choose M here. The module
will be called e2100.
-config EWRK3
- tristate "EtherWORKS 3 (DE203, DE204, DE205) support"
- depends on NET_ISA
- select CRC32
- ---help---
- This driver supports the DE203, DE204 and DE205 network (Ethernet)
- cards. If this is for you, say Y and read
- <file:Documentation/networking/ewrk3.txt> in the kernel source as
- well as the Ethernet-HOWTO, available from
- <http://www.tldp.org/docs.html#howto>.
-
- To compile this driver as a module, choose M here. The module
- will be called ewrk3.
-
config EEXPRESS
tristate "EtherExpress 16 support"
depends on NET_ISA
@@ -1852,15 +1825,6 @@ config SGISEEQ
Say Y here if you have an Seeq based Ethernet network card. This is
used in many Silicon Graphics machines.
-config DECLANCE
- tristate "DEC LANCE ethernet controller support"
- depends on MACH_DECSTATION
- select CRC32
- help
- This driver is for the series of Ethernet controllers produced by
- DEC (now Compaq) based on the AMD Lance chipset, including the
- DEPCA series. (This chipset is better known via the NE2100 cards.)
-
config 68360_ENET
bool "Motorola 68360 ethernet controller"
depends on M68360
@@ -2913,33 +2877,6 @@ config FDDI
then also Y to the driver for your FDDI card, below). Most people
will say N.
-config DEFXX
- tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
- depends on FDDI && (PCI || EISA || TC)
- ---help---
- This is support for the DIGITAL series of TURBOchannel (DEFTA),
- EISA (DEFEA) and PCI (DEFPA) controllers which can connect you
- to a local FDDI network.
-
- To compile this driver as a module, choose M here: the module
- will be called defxx. If unsure, say N.
-
-config DEFXX_MMIO
- bool
- prompt "Use MMIO instead of PIO" if PCI || EISA
- depends on DEFXX
- default n if PCI || EISA
- default y
- ---help---
- This instructs the driver to use EISA or PCI memory-mapped I/O
- (MMIO) as appropriate instead of programmed I/O ports (PIO).
- Enabling this gives an improvement in processing time in parts
- of the driver, but it may cause problems with EISA (DEFEA)
- adapters. TURBOchannel does not have the concept of I/O ports,
- so MMIO is always used for these (DEFTA) adapters.
-
- If unsure, say N.
-
config SKFP
tristate "SysKonnect FDDI PCI support"
depends on FDDI && PCI
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 152f8b5..f6536fe 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -175,7 +175,6 @@ obj-$(CONFIG_IFB) += ifb.o
obj-$(CONFIG_MACVLAN) += macvlan.o
obj-$(CONFIG_MACVTAP) += macvtap.o
obj-$(CONFIG_LANCE) += lance.o
-obj-$(CONFIG_DEFXX) += defxx.o
obj-$(CONFIG_SGISEEQ) += sgiseeq.o
obj-$(CONFIG_SGI_O2MACE_ETH) += meth.o
obj-$(CONFIG_AT1700) += at1700.o
@@ -191,8 +190,6 @@ obj-$(CONFIG_8139CP) += 8139cp.o
obj-$(CONFIG_8139TOO) += 8139too.o
obj-$(CONFIG_ZNET) += znet.o
obj-$(CONFIG_CPMAC) += cpmac.o
-obj-$(CONFIG_DEPCA) += depca.o
-obj-$(CONFIG_EWRK3) += ewrk3.o
obj-$(CONFIG_ATP) += atp.o
obj-$(CONFIG_NI5010) += ni5010.o
obj-$(CONFIG_NI52) += ni52.o
@@ -219,7 +216,6 @@ obj-$(CONFIG_MIPS_JAZZ_SONIC) += jazzsonic.o
obj-$(CONFIG_MIPS_AU1X00_ENET) += au1000_eth.o
obj-$(CONFIG_MIPS_SIM_NET) += mipsnet.o
obj-$(CONFIG_SGI_IOC3_ETH) += ioc3-eth.o
-obj-$(CONFIG_DECLANCE) += declance.o
obj-$(CONFIG_ATARILANCE) += atarilance.o
obj-$(CONFIG_A2065) += a2065.o
obj-$(CONFIG_HYDRA) += hydra.o 8390.o
diff --git a/drivers/net/legacy/Kconfig b/drivers/net/legacy/Kconfig
index 1af0740..ac163cc 100644
--- a/drivers/net/legacy/Kconfig
+++ b/drivers/net/legacy/Kconfig
@@ -66,3 +66,66 @@ config SUN3_82586
Ethernet adapter found on Sun 3/1xx and 3/2xx motherboards. Note
that this driver does not support 82586-based adapters on additional
VME boards.
+
+config DEPCA
+ tristate "DEPCA, DE10x, DE200, DE201, DE202, DE422 support"
+ depends on ISA || EISA || MCA
+ select CRC32
+ ---help---
+ If you have a network (Ethernet) card of this type, say Y and read
+ the Ethernet-HOWTO, available from
+ <http://www.tldp.org/docs.html#howto> as well as
+ <file:drivers/net/depca.c>.
+
+ To compile this driver as a module, choose M here. The module
+ will be called depca.
+
+config EWRK3
+ tristate "EtherWORKS 3 (DE203, DE204, DE205) support"
+ depends on NET_ISA
+ select CRC32
+ ---help---
+ This driver supports the DE203, DE204 and DE205 network (Ethernet)
+ cards. If this is for you, say Y and read
+ <file:Documentation/networking/ewrk3.txt> in the kernel source as
+ well as the Ethernet-HOWTO, available from
+ <http://www.tldp.org/docs.html#howto>.
+
+ To compile this driver as a module, choose M here. The module
+ will be called ewrk3.
+
+config DECLANCE
+ tristate "DEC LANCE ethernet controller support"
+ depends on MACH_DECSTATION
+ select CRC32
+ help
+ This driver is for the series of Ethernet controllers produced by
+ DEC (now Compaq) based on the AMD Lance chipset, including the
+ DEPCA series. (This chipset is better known via the NE2100 cards.)
+
+config DEFXX
+ tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
+ depends on FDDI && (PCI || EISA || TC)
+ ---help---
+ This is support for the DIGITAL series of TURBOchannel (DEFTA),
+ EISA (DEFEA) and PCI (DEFPA) controllers which can connect you
+ to a local FDDI network.
+
+ To compile this driver as a module, choose M here: the module
+ will be called defxx. If unsure, say N.
+
+config DEFXX_MMIO
+ bool
+ prompt "Use MMIO instead of PIO" if PCI || EISA
+ depends on DEFXX
+ default n if PCI || EISA
+ default y
+ ---help---
+ This instructs the driver to use EISA or PCI memory-mapped I/O
+ (MMIO) as appropriate instead of programmed I/O ports (PIO).
+ Enabling this gives an improvement in processing time in parts
+ of the driver, but it may cause problems with EISA (DEFEA)
+ adapters. TURBOchannel does not have the concept of I/O ports,
+ so MMIO is always used for these (DEFTA) adapters.
+
+ If unsure, say N.
diff --git a/drivers/net/legacy/Makefile b/drivers/net/legacy/Makefile
index f552c77..7ab3669 100644
--- a/drivers/net/legacy/Makefile
+++ b/drivers/net/legacy/Makefile
@@ -8,3 +8,8 @@ obj-$(CONFIG_DE620) += de620.o
obj-$(CONFIG_SUN3_82586) += sun3_82586.o
obj-$(CONFIG_SUN3LANCE) += sun3lance.o
+
+obj-$(CONFIG_DEFXX) += defxx.o
+obj-$(CONFIG_DEPCA) += depca.o
+obj-$(CONFIG_EWRK3) += ewrk3.o
+obj-$(CONFIG_DECLANCE) += declance.o
diff --git a/drivers/net/declance.c b/drivers/net/legacy/declance.c
similarity index 100%
rename from drivers/net/declance.c
rename to drivers/net/legacy/declance.c
diff --git a/drivers/net/defxx.c b/drivers/net/legacy/defxx.c
similarity index 100%
rename from drivers/net/defxx.c
rename to drivers/net/legacy/defxx.c
diff --git a/drivers/net/defxx.h b/drivers/net/legacy/defxx.h
similarity index 100%
rename from drivers/net/defxx.h
rename to drivers/net/legacy/defxx.h
diff --git a/drivers/net/depca.c b/drivers/net/legacy/depca.c
similarity index 100%
rename from drivers/net/depca.c
rename to drivers/net/legacy/depca.c
diff --git a/drivers/net/depca.h b/drivers/net/legacy/depca.h
similarity index 100%
rename from drivers/net/depca.h
rename to drivers/net/legacy/depca.h
diff --git a/drivers/net/ewrk3.c b/drivers/net/legacy/ewrk3.c
similarity index 100%
rename from drivers/net/ewrk3.c
rename to drivers/net/legacy/ewrk3.c
diff --git a/drivers/net/ewrk3.h b/drivers/net/legacy/ewrk3.h
similarity index 100%
rename from drivers/net/ewrk3.h
rename to drivers/net/legacy/ewrk3.h
--
1.7.3.2.146.g2d444
^ permalink raw reply related
* [PATCH 04/15] sun3: Relocate the sun3 specific lance/83596 drivers to legacy
From: Paul Gortmaker @ 2010-10-29 1:19 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1288315159-1350-1-git-send-email-paul.gortmaker@windriver.com>
Relocate these old drivers for really old Sun3 hardware to the
legacy dir.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/Kconfig | 22 ----------------------
drivers/net/Makefile | 2 --
drivers/net/legacy/Kconfig | 22 ++++++++++++++++++++++
drivers/net/legacy/Makefile | 3 +++
drivers/net/{ => legacy}/sun3_82586.c | 0
drivers/net/{ => legacy}/sun3_82586.h | 0
drivers/net/{ => legacy}/sun3lance.c | 0
7 files changed, 25 insertions(+), 24 deletions(-)
rename drivers/net/{ => legacy}/sun3_82586.c (100%)
rename drivers/net/{ => legacy}/sun3_82586.h (100%)
rename drivers/net/{ => legacy}/sun3lance.c (100%)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index eb65a3a..511745d 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -435,28 +435,6 @@ config ATARILANCE
on the AMD Lance chipset: RieblCard (with or without battery), or
PAMCard VME (also the version by Rhotron, with different addresses).
-config SUN3LANCE
- tristate "Sun3/Sun3x on-board LANCE support"
- depends on SUN3 || SUN3X
- help
- Most Sun3 and Sun3x motherboards (including the 3/50, 3/60 and 3/80)
- featured an AMD Lance 10Mbit Ethernet controller on board; say Y
- here to compile in the Linux driver for this and enable Ethernet.
- General Linux information on the Sun 3 and 3x series (now
- discontinued) is at
- <http://www.angelfire.com/ca2/tech68k/sun3.html>.
-
- If you're not building a kernel for a Sun 3, say N.
-
-config SUN3_82586
- bool "Sun3 on-board Intel 82586 support"
- depends on SUN3
- help
- This driver enables support for the on-board Intel 82586 based
- Ethernet adapter found on Sun 3/1xx and 3/2xx motherboards. Note
- that this driver does not support 82586-based adapters on additional
- VME boards.
-
config HPLANCE
bool "HP on-board LANCE support"
depends on DIO
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 41594da..152f8b5 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -175,8 +175,6 @@ obj-$(CONFIG_IFB) += ifb.o
obj-$(CONFIG_MACVLAN) += macvlan.o
obj-$(CONFIG_MACVTAP) += macvtap.o
obj-$(CONFIG_LANCE) += lance.o
-obj-$(CONFIG_SUN3_82586) += sun3_82586.o
-obj-$(CONFIG_SUN3LANCE) += sun3lance.o
obj-$(CONFIG_DEFXX) += defxx.o
obj-$(CONFIG_SGISEEQ) += sgiseeq.o
obj-$(CONFIG_SGI_O2MACE_ETH) += meth.o
diff --git a/drivers/net/legacy/Kconfig b/drivers/net/legacy/Kconfig
index ef6fa1f..1af0740 100644
--- a/drivers/net/legacy/Kconfig
+++ b/drivers/net/legacy/Kconfig
@@ -44,3 +44,25 @@ config DE620
To compile this driver as a module, choose M here: the module
will be called de620.
+
+config SUN3LANCE
+ tristate "Sun3/Sun3x on-board LANCE support"
+ depends on SUN3 || SUN3X
+ help
+ Most Sun3 and Sun3x motherboards (including the 3/50, 3/60 and 3/80)
+ featured an AMD Lance 10Mbit Ethernet controller on board; say Y
+ here to compile in the Linux driver for this and enable Ethernet.
+ General Linux information on the Sun 3 and 3x series (now
+ discontinued) is at
+ <http://www.angelfire.com/ca2/tech68k/sun3.html>.
+
+ If you're not building a kernel for a Sun 3, say N.
+
+config SUN3_82586
+ bool "Sun3 on-board Intel 82586 support"
+ depends on SUN3
+ help
+ This driver enables support for the on-board Intel 82586 based
+ Ethernet adapter found on Sun 3/1xx and 3/2xx motherboards. Note
+ that this driver does not support 82586-based adapters on additional
+ VME boards.
diff --git a/drivers/net/legacy/Makefile b/drivers/net/legacy/Makefile
index e82ca16..f552c77 100644
--- a/drivers/net/legacy/Makefile
+++ b/drivers/net/legacy/Makefile
@@ -5,3 +5,6 @@
obj-$(CONFIG_EL1) += 3c501.o
obj-$(CONFIG_DE600) += de600.o
obj-$(CONFIG_DE620) += de620.o
+
+obj-$(CONFIG_SUN3_82586) += sun3_82586.o
+obj-$(CONFIG_SUN3LANCE) += sun3lance.o
diff --git a/drivers/net/sun3_82586.c b/drivers/net/legacy/sun3_82586.c
similarity index 100%
rename from drivers/net/sun3_82586.c
rename to drivers/net/legacy/sun3_82586.c
diff --git a/drivers/net/sun3_82586.h b/drivers/net/legacy/sun3_82586.h
similarity index 100%
rename from drivers/net/sun3_82586.h
rename to drivers/net/legacy/sun3_82586.h
diff --git a/drivers/net/sun3lance.c b/drivers/net/legacy/sun3lance.c
similarity index 100%
rename from drivers/net/sun3lance.c
rename to drivers/net/legacy/sun3lance.c
--
1.7.3.2.146.g2d444
^ permalink raw reply related
* [PATCH 03/15] de6xx: relocate ancient parallel port eth drivers to legacy
From: Paul Gortmaker @ 2010-10-29 1:19 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1288315159-1350-1-git-send-email-paul.gortmaker@windriver.com>
These old drivers pre-date USB, coming from the early 1990's
and with the legacy parallel port also now largely gone from
any current hardware, these need to be relocated to the legacy
directory, since they won't have been in active use for years.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/Kconfig | 30 ------------------------------
drivers/net/Makefile | 2 --
drivers/net/legacy/Kconfig | 30 ++++++++++++++++++++++++++++++
drivers/net/legacy/Makefile | 2 ++
drivers/net/{ => legacy}/de600.c | 0
drivers/net/{ => legacy}/de600.h | 0
drivers/net/{ => legacy}/de620.c | 0
drivers/net/{ => legacy}/de620.h | 0
8 files changed, 32 insertions(+), 32 deletions(-)
rename drivers/net/{ => legacy}/de600.c (100%)
rename drivers/net/{ => legacy}/de600.h (100%)
rename drivers/net/{ => legacy}/de620.c (100%)
rename drivers/net/{ => legacy}/de620.h (100%)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index cb7f3f4..eb65a3a 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1867,36 +1867,6 @@ config ATP
To compile this driver as a module, choose M here: the module
will be called atp.
-config DE600
- tristate "D-Link DE600 pocket adapter support"
- depends on NET_POCKET && PARPORT
- ---help---
- This is a network (Ethernet) device which attaches to your parallel
- port. Read <file:Documentation/networking/DLINK.txt> as well as the
- Ethernet-HOWTO, available from
- <http://www.tldp.org/docs.html#howto>, if you want to use
- this. It is possible to have several devices share a single parallel
- port and it is safe to compile the corresponding drivers into the
- kernel.
-
- To compile this driver as a module, choose M here: the module
- will be called de600.
-
-config DE620
- tristate "D-Link DE620 pocket adapter support"
- depends on NET_POCKET && PARPORT
- ---help---
- This is a network (Ethernet) device which attaches to your parallel
- port. Read <file:Documentation/networking/DLINK.txt> as well as the
- Ethernet-HOWTO, available from
- <http://www.tldp.org/docs.html#howto>, if you want to use
- this. It is possible to have several devices share a single parallel
- port and it is safe to compile the corresponding drivers into the
- kernel.
-
- To compile this driver as a module, choose M here: the module
- will be called de620.
-
config SGISEEQ
tristate "SGI Seeq ethernet controller support"
depends on SGI_HAS_SEEQ
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index eb99117..41594da 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -174,8 +174,6 @@ obj-$(CONFIG_DUMMY) += dummy.o
obj-$(CONFIG_IFB) += ifb.o
obj-$(CONFIG_MACVLAN) += macvlan.o
obj-$(CONFIG_MACVTAP) += macvtap.o
-obj-$(CONFIG_DE600) += de600.o
-obj-$(CONFIG_DE620) += de620.o
obj-$(CONFIG_LANCE) += lance.o
obj-$(CONFIG_SUN3_82586) += sun3_82586.o
obj-$(CONFIG_SUN3LANCE) += sun3lance.o
diff --git a/drivers/net/legacy/Kconfig b/drivers/net/legacy/Kconfig
index fa2d6f8..ef6fa1f 100644
--- a/drivers/net/legacy/Kconfig
+++ b/drivers/net/legacy/Kconfig
@@ -14,3 +14,33 @@ config EL1
To compile this driver as a module, choose M here. The module
will be called 3c501.
+
+config DE600
+ tristate "D-Link DE600 pocket adapter support"
+ depends on NET_POCKET && PARPORT
+ ---help---
+ This is a network (Ethernet) device which attaches to your parallel
+ port. Read <file:Documentation/networking/DLINK.txt> as well as the
+ Ethernet-HOWTO, available from
+ <http://www.tldp.org/docs.html#howto>, if you want to use
+ this. It is possible to have several devices share a single parallel
+ port and it is safe to compile the corresponding drivers into the
+ kernel.
+
+ To compile this driver as a module, choose M here: the module
+ will be called de600.
+
+config DE620
+ tristate "D-Link DE620 pocket adapter support"
+ depends on NET_POCKET && PARPORT
+ ---help---
+ This is a network (Ethernet) device which attaches to your parallel
+ port. Read <file:Documentation/networking/DLINK.txt> as well as the
+ Ethernet-HOWTO, available from
+ <http://www.tldp.org/docs.html#howto>, if you want to use
+ this. It is possible to have several devices share a single parallel
+ port and it is safe to compile the corresponding drivers into the
+ kernel.
+
+ To compile this driver as a module, choose M here: the module
+ will be called de620.
diff --git a/drivers/net/legacy/Makefile b/drivers/net/legacy/Makefile
index acbf0b2..e82ca16 100644
--- a/drivers/net/legacy/Makefile
+++ b/drivers/net/legacy/Makefile
@@ -3,3 +3,5 @@
#
obj-$(CONFIG_EL1) += 3c501.o
+obj-$(CONFIG_DE600) += de600.o
+obj-$(CONFIG_DE620) += de620.o
diff --git a/drivers/net/de600.c b/drivers/net/legacy/de600.c
similarity index 100%
rename from drivers/net/de600.c
rename to drivers/net/legacy/de600.c
diff --git a/drivers/net/de600.h b/drivers/net/legacy/de600.h
similarity index 100%
rename from drivers/net/de600.h
rename to drivers/net/legacy/de600.h
diff --git a/drivers/net/de620.c b/drivers/net/legacy/de620.c
similarity index 100%
rename from drivers/net/de620.c
rename to drivers/net/legacy/de620.c
diff --git a/drivers/net/de620.h b/drivers/net/legacy/de620.h
similarity index 100%
rename from drivers/net/de620.h
rename to drivers/net/legacy/de620.h
--
1.7.3.2.146.g2d444
^ permalink raw reply related
* [PATCH 02/15] 3c501: relocate ancient 8 bit ISA driver to legacy dir
From: Paul Gortmaker @ 2010-10-29 1:19 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1288315159-1350-1-git-send-email-paul.gortmaker@windriver.com>
As the oldest bit of "supported" hardware, this 8 bit relic from
the 1980's gets the dubious honour of being the 1st driver to
be relegated to the dark corners of the legacy dir.
It wasn't really a functional bit of kit back in the early 1990's
so don't be expecting it to work now either. Sure it compiles,
but it is largely a historical artefact.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/Kconfig | 14 --------------
drivers/net/Makefile | 1 -
drivers/net/{ => legacy}/3c501.c | 0
drivers/net/{ => legacy}/3c501.h | 0
drivers/net/legacy/Kconfig | 14 ++++++++++++++
drivers/net/legacy/Makefile | 2 ++
6 files changed, 16 insertions(+), 15 deletions(-)
rename drivers/net/{ => legacy}/3c501.c (100%)
rename drivers/net/{ => legacy}/3c501.h (100%)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 9515f76..cb7f3f4 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -641,20 +641,6 @@ config NET_VENDOR_3COM
the questions about 3COM cards. If you say Y, you will be asked for
your specific card in the following questions.
-config EL1
- tristate "3c501 \"EtherLink\" support"
- depends on NET_VENDOR_3COM && ISA
- ---help---
- If you have a network (Ethernet) card of this type, say Y and read
- the Ethernet-HOWTO, available from
- <http://www.tldp.org/docs.html#howto>. Also, consider buying a
- new card, since the 3c501 is slow, broken, and obsolete: you will
- have problems. Some people suggest to ping ("man ping") a nearby
- machine every minute ("man cron") when using this card.
-
- To compile this driver as a module, choose M here. The module
- will be called 3c501.
-
config EL2
tristate "3c503 \"EtherLink II\" support"
depends on NET_VENDOR_3COM && ISA
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 8045271..eb99117 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -183,7 +183,6 @@ obj-$(CONFIG_DEFXX) += defxx.o
obj-$(CONFIG_SGISEEQ) += sgiseeq.o
obj-$(CONFIG_SGI_O2MACE_ETH) += meth.o
obj-$(CONFIG_AT1700) += at1700.o
-obj-$(CONFIG_EL1) += 3c501.o
obj-$(CONFIG_EL16) += 3c507.o
obj-$(CONFIG_ELMC) += 3c523.o
obj-$(CONFIG_IBMLANA) += ibmlana.o
diff --git a/drivers/net/3c501.c b/drivers/net/legacy/3c501.c
similarity index 100%
rename from drivers/net/3c501.c
rename to drivers/net/legacy/3c501.c
diff --git a/drivers/net/3c501.h b/drivers/net/legacy/3c501.h
similarity index 100%
rename from drivers/net/3c501.h
rename to drivers/net/legacy/3c501.h
diff --git a/drivers/net/legacy/Kconfig b/drivers/net/legacy/Kconfig
index 4c23adf..fa2d6f8 100644
--- a/drivers/net/legacy/Kconfig
+++ b/drivers/net/legacy/Kconfig
@@ -1,2 +1,16 @@
# Legacy drivers for ancient ISA/EISA bus devices and the like.
+
+config EL1
+ tristate "3c501 \"EtherLink\" support"
+ depends on NET_VENDOR_3COM && ISA
+ ---help---
+ If you have a network (Ethernet) card of this type, say Y and read
+ the Ethernet-HOWTO, available from
+ <http://www.tldp.org/docs.html#howto>. Also, consider buying a
+ new card, since the 3c501 is slow, broken, and obsolete: you will
+ have problems. Some people suggest to ping ("man ping") a nearby
+ machine every minute ("man cron") when using this card.
+
+ To compile this driver as a module, choose M here. The module
+ will be called 3c501.
diff --git a/drivers/net/legacy/Makefile b/drivers/net/legacy/Makefile
index 33fd752..acbf0b2 100644
--- a/drivers/net/legacy/Makefile
+++ b/drivers/net/legacy/Makefile
@@ -1,3 +1,5 @@
#
# Makefile for the Linux legacy network device drivers.
#
+
+obj-$(CONFIG_EL1) += 3c501.o
--
1.7.3.2.146.g2d444
^ permalink raw reply related
* [PATCH 01/15] net: introduce legacy dir to absorb 10Mbit, ISA, EISA drivers
From: Paul Gortmaker @ 2010-10-29 1:19 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1288315159-1350-1-git-send-email-paul.gortmaker@windriver.com>
There are lots of drivers that date back to the early 1990's when
Linux was started, and they correspond to hardware and bus
technologies that have largely disappeared from in-use hardware over
10 years ago.
There is no need to have these drivers polluting the namespace
in the top level drivers directory any longer; relocation to a
subdirectory is long overdue. Start by creating this new home
for these drivers so that they can be targeted and relocated.
By leaving the default to include the legacy/Kconfig, we ensure
people who have existing stores of their own .config files will
not have drivers silently dropped from their builds.
Since the legacy drivers have their probe ordering defined in
the Space.c file, we don't have to strictly maintain any link
order in moving things from Makefile to legacy/Makefile.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/Kconfig | 14 ++++++++++++++
drivers/net/Makefile | 1 +
drivers/net/legacy/Kconfig | 2 ++
drivers/net/legacy/Makefile | 3 +++
4 files changed, 20 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/legacy/Kconfig
create mode 100644 drivers/net/legacy/Makefile
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f24179d..9515f76 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -28,6 +28,20 @@ menuconfig NETDEVICES
# that for each of the symbols.
if NETDEVICES
+config NETDEVICES_LEGACY
+ default y
+ bool "Legacy 10+ year old drivers (10Mbit, ISA, EISA, MCA etc.)"
+ ---help---
+ There are a lot of drivers that exist for really old network
+ hardware that have long since been out of production, and
+ are not really in active use by anyone with hardware that is
+ less than ten years old. Unless you are trying to use really
+ old hardware, you can say no here.
+
+if NETDEVICES_LEGACY
+source "drivers/net/legacy/Kconfig"
+endif
+
config IFB
tristate "Intermediate Functional Block support"
depends on NET_CLS_ACT
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index b8bf93d..8045271 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -299,3 +299,4 @@ obj-$(CONFIG_CAIF) += caif/
obj-$(CONFIG_OCTEON_MGMT_ETHERNET) += octeon/
obj-$(CONFIG_PCH_GBE) += pch_gbe/
+obj-$(CONFIG_NETDEVICES_LEGACY) += legacy/
diff --git a/drivers/net/legacy/Kconfig b/drivers/net/legacy/Kconfig
new file mode 100644
index 0000000..4c23adf
--- /dev/null
+++ b/drivers/net/legacy/Kconfig
@@ -0,0 +1,2 @@
+
+# Legacy drivers for ancient ISA/EISA bus devices and the like.
diff --git a/drivers/net/legacy/Makefile b/drivers/net/legacy/Makefile
new file mode 100644
index 0000000..33fd752
--- /dev/null
+++ b/drivers/net/legacy/Makefile
@@ -0,0 +1,3 @@
+#
+# Makefile for the Linux legacy network device drivers.
+#
--
1.7.3.2.146.g2d444
^ permalink raw reply related
* [PATCH 0/15] RFC: create drivers/net/legacy for ISA, EISA, MCA drivers
From: Paul Gortmaker @ 2010-10-29 1:19 UTC (permalink / raw)
To: davem; +Cc: netdev
The drivers/net dir has a lot of files - originally there were
no subdirs, but at least now subdirs are being used effectively.
But the original drivers from 10+ years ago are still right
there at the top. This series creates a drivers/net/legacy dir.
The initial target is things like ISA/EISA/MCA drivers, and with
that alone, we can get close to 90 files out of drivers/net.
Plus, by having a semi-defined description for legacy as being
"drivers more than 10 years old" we'll always have a destination
for drivers as they fall out of maintainership and use.
If in fact this series gets agreement, I'm figuring it makes sense
to have it go in either at the beginning of a dev cycle, or at
the very end -- I have no strict preference; whatever is easier
for people on the whole. Since I don't expect a lot of activity
in any of these drivers, hopefully it doesn't impact any one else's
pending changes too significantly either way.
All the moves are 100% translation; I didn't add or change any of
the driver sources at all, so I've used "-M" to format the patches
for e-mail. Similarly, if you apply them and git am nags about
whitespace, that comes directly from the original files.
Paul.
-----
The following changes since commit 19449bfc10d163f0024dd5ae5808e28cda32e7b4:
stmmac: enable/disable rx/tx in the core with a single write. (2010-10-28 11:47:54 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/net-2.6.git legacy-netdev
Paul Gortmaker (15):
net: introduce legacy dir to absorb 10Mbit, ISA, EISA drivers
3c501: relocate ancient 8 bit ISA driver to legacy dir
de6xx: relocate ancient parallel port eth drivers to legacy
sun3: Relocate the sun3 specific lance/83596 drivers to legacy
dec netdev: relocate DIGITAL based drivers to legacy
netdev: relocate i8258x and i8259x based drivers to legacy
lance: relocate legacy 7990 based drivers to legacy
netdev: relocate toplevel 8390 based drivers to legacy dir
netdev: relocate remaining ISA 3Com cards to legacy dir
netdev: relocate more one-off drivers to the legacy dir
netdev: kill off the concept of NET_VENDOR_FOO
netdev: relocate sb1000 ISA cable modem driver to legacy
netdev: kill off NET_ISA Kconfig option
MAINTAINERS: updates for new drivers/net/legacy dir
netdev: relocate LICENSE.SRC to legacy
MAINTAINERS | 19 +-
drivers/net/Kconfig | 747 +-------------------------------
drivers/net/Makefile | 63 +---
drivers/net/arm/etherh.c | 2 +-
drivers/net/{ => legacy}/3c501.c | 0
drivers/net/{ => legacy}/3c501.h | 0
drivers/net/{ => legacy}/3c503.c | 0
drivers/net/{ => legacy}/3c503.h | 0
drivers/net/{ => legacy}/3c505.c | 0
drivers/net/{ => legacy}/3c505.h | 0
drivers/net/{ => legacy}/3c507.c | 0
drivers/net/{ => legacy}/3c509.c | 0
drivers/net/{ => legacy}/3c515.c | 0
drivers/net/{ => legacy}/3c523.c | 0
drivers/net/{ => legacy}/3c523.h | 0
drivers/net/{ => legacy}/3c527.c | 0
drivers/net/{ => legacy}/3c527.h | 0
drivers/net/{ => legacy}/7990.c | 0
drivers/net/{ => legacy}/7990.h | 0
drivers/net/{ => legacy}/82596.c | 0
drivers/net/{ => legacy}/8390.c | 0
drivers/net/{ => legacy}/8390.h | 0
drivers/net/{ => legacy}/8390p.c | 0
drivers/net/legacy/Kconfig | 675 +++++++++++++++++++++++++++++
drivers/net/{ => legacy}/LICENSE.SRC | 0
drivers/net/legacy/Makefile | 78 ++++
drivers/net/{ => legacy}/ac3200.c | 0
drivers/net/{ => legacy}/apne.c | 0
drivers/net/{ => legacy}/ariadne.c | 0
drivers/net/{ => legacy}/ariadne.h | 0
drivers/net/{ => legacy}/at1700.c | 0
drivers/net/{ => legacy}/atarilance.c | 0
drivers/net/{ => legacy}/ax88796.c | 0
drivers/net/{ => legacy}/de600.c | 0
drivers/net/{ => legacy}/de600.h | 0
drivers/net/{ => legacy}/de620.c | 0
drivers/net/{ => legacy}/de620.h | 0
drivers/net/{ => legacy}/declance.c | 0
drivers/net/{ => legacy}/defxx.c | 0
drivers/net/{ => legacy}/defxx.h | 0
drivers/net/{ => legacy}/depca.c | 0
drivers/net/{ => legacy}/depca.h | 0
drivers/net/{ => legacy}/e2100.c | 0
drivers/net/{ => legacy}/eepro.c | 0
drivers/net/{ => legacy}/eexpress.c | 0
drivers/net/{ => legacy}/eexpress.h | 0
drivers/net/{ => legacy}/es3210.c | 0
drivers/net/{ => legacy}/eth16i.c | 0
drivers/net/{ => legacy}/ewrk3.c | 0
drivers/net/{ => legacy}/ewrk3.h | 0
drivers/net/{ => legacy}/hp-plus.c | 0
drivers/net/{ => legacy}/hp.c | 0
drivers/net/{ => legacy}/hplance.c | 0
drivers/net/{ => legacy}/hplance.h | 0
drivers/net/{ => legacy}/hydra.c | 0
drivers/net/{ => legacy}/ibmlana.c | 0
drivers/net/{ => legacy}/ibmlana.h | 0
drivers/net/{ => legacy}/lance.c | 0
drivers/net/{ => legacy}/lasi_82596.c | 0
drivers/net/{ => legacy}/lib82596.c | 0
drivers/net/{ => legacy}/lib8390.c | 0
drivers/net/{ => legacy}/lne390.c | 0
drivers/net/{ => legacy}/lp486e.c | 0
drivers/net/{ => legacy}/mac8390.c | 0
drivers/net/{ => legacy}/mvme147.c | 0
drivers/net/{ => legacy}/ne-h8300.c | 0
drivers/net/{ => legacy}/ne.c | 0
drivers/net/{ => legacy}/ne2.c | 0
drivers/net/{ => legacy}/ne2k-pci.c | 0
drivers/net/{ => legacy}/ne3210.c | 0
drivers/net/{ => legacy}/ni5010.c | 0
drivers/net/{ => legacy}/ni5010.h | 0
drivers/net/{ => legacy}/ni52.c | 0
drivers/net/{ => legacy}/ni52.h | 0
drivers/net/{ => legacy}/ni65.c | 0
drivers/net/{ => legacy}/ni65.h | 0
drivers/net/{ => legacy}/sb1000.c | 0
drivers/net/{ => legacy}/seeq8005.c | 0
drivers/net/{ => legacy}/seeq8005.h | 0
drivers/net/{ => legacy}/smc-mca.c | 0
drivers/net/{ => legacy}/smc-ultra.c | 0
drivers/net/{ => legacy}/smc-ultra32.c | 0
drivers/net/{ => legacy}/smc9194.c | 0
drivers/net/{ => legacy}/smc9194.h | 0
drivers/net/{ => legacy}/sni_82596.c | 0
drivers/net/{ => legacy}/stnic.c | 0
drivers/net/{ => legacy}/sun3_82586.c | 0
drivers/net/{ => legacy}/sun3_82586.h | 0
drivers/net/{ => legacy}/sun3lance.c | 0
drivers/net/{ => legacy}/wd.c | 0
drivers/net/{ => legacy}/znet.c | 0
drivers/net/{ => legacy}/zorro8390.c | 0
drivers/net/pcmcia/axnet_cs.c | 2 +-
drivers/net/pcmcia/pcnet_cs.c | 2 +-
94 files changed, 782 insertions(+), 806 deletions(-)
rename drivers/net/{ => legacy}/3c501.c (100%)
rename drivers/net/{ => legacy}/3c501.h (100%)
rename drivers/net/{ => legacy}/3c503.c (100%)
rename drivers/net/{ => legacy}/3c503.h (100%)
rename drivers/net/{ => legacy}/3c505.c (100%)
rename drivers/net/{ => legacy}/3c505.h (100%)
rename drivers/net/{ => legacy}/3c507.c (100%)
rename drivers/net/{ => legacy}/3c509.c (100%)
rename drivers/net/{ => legacy}/3c515.c (100%)
rename drivers/net/{ => legacy}/3c523.c (100%)
rename drivers/net/{ => legacy}/3c523.h (100%)
rename drivers/net/{ => legacy}/3c527.c (100%)
rename drivers/net/{ => legacy}/3c527.h (100%)
rename drivers/net/{ => legacy}/7990.c (100%)
rename drivers/net/{ => legacy}/7990.h (100%)
rename drivers/net/{ => legacy}/82596.c (100%)
rename drivers/net/{ => legacy}/8390.c (100%)
rename drivers/net/{ => legacy}/8390.h (100%)
rename drivers/net/{ => legacy}/8390p.c (100%)
create mode 100644 drivers/net/legacy/Kconfig
rename drivers/net/{ => legacy}/LICENSE.SRC (100%)
create mode 100644 drivers/net/legacy/Makefile
rename drivers/net/{ => legacy}/ac3200.c (100%)
rename drivers/net/{ => legacy}/apne.c (100%)
rename drivers/net/{ => legacy}/ariadne.c (100%)
rename drivers/net/{ => legacy}/ariadne.h (100%)
rename drivers/net/{ => legacy}/at1700.c (100%)
rename drivers/net/{ => legacy}/atarilance.c (100%)
rename drivers/net/{ => legacy}/ax88796.c (100%)
rename drivers/net/{ => legacy}/de600.c (100%)
rename drivers/net/{ => legacy}/de600.h (100%)
rename drivers/net/{ => legacy}/de620.c (100%)
rename drivers/net/{ => legacy}/de620.h (100%)
rename drivers/net/{ => legacy}/declance.c (100%)
rename drivers/net/{ => legacy}/defxx.c (100%)
rename drivers/net/{ => legacy}/defxx.h (100%)
rename drivers/net/{ => legacy}/depca.c (100%)
rename drivers/net/{ => legacy}/depca.h (100%)
rename drivers/net/{ => legacy}/e2100.c (100%)
rename drivers/net/{ => legacy}/eepro.c (100%)
rename drivers/net/{ => legacy}/eexpress.c (100%)
rename drivers/net/{ => legacy}/eexpress.h (100%)
rename drivers/net/{ => legacy}/es3210.c (100%)
rename drivers/net/{ => legacy}/eth16i.c (100%)
rename drivers/net/{ => legacy}/ewrk3.c (100%)
rename drivers/net/{ => legacy}/ewrk3.h (100%)
rename drivers/net/{ => legacy}/hp-plus.c (100%)
rename drivers/net/{ => legacy}/hp.c (100%)
rename drivers/net/{ => legacy}/hplance.c (100%)
rename drivers/net/{ => legacy}/hplance.h (100%)
rename drivers/net/{ => legacy}/hydra.c (100%)
rename drivers/net/{ => legacy}/ibmlana.c (100%)
rename drivers/net/{ => legacy}/ibmlana.h (100%)
rename drivers/net/{ => legacy}/lance.c (100%)
rename drivers/net/{ => legacy}/lasi_82596.c (100%)
rename drivers/net/{ => legacy}/lib82596.c (100%)
rename drivers/net/{ => legacy}/lib8390.c (100%)
rename drivers/net/{ => legacy}/lne390.c (100%)
rename drivers/net/{ => legacy}/lp486e.c (100%)
rename drivers/net/{ => legacy}/mac8390.c (100%)
rename drivers/net/{ => legacy}/mvme147.c (100%)
rename drivers/net/{ => legacy}/ne-h8300.c (100%)
rename drivers/net/{ => legacy}/ne.c (100%)
rename drivers/net/{ => legacy}/ne2.c (100%)
rename drivers/net/{ => legacy}/ne2k-pci.c (100%)
rename drivers/net/{ => legacy}/ne3210.c (100%)
rename drivers/net/{ => legacy}/ni5010.c (100%)
rename drivers/net/{ => legacy}/ni5010.h (100%)
rename drivers/net/{ => legacy}/ni52.c (100%)
rename drivers/net/{ => legacy}/ni52.h (100%)
rename drivers/net/{ => legacy}/ni65.c (100%)
rename drivers/net/{ => legacy}/ni65.h (100%)
rename drivers/net/{ => legacy}/sb1000.c (100%)
rename drivers/net/{ => legacy}/seeq8005.c (100%)
rename drivers/net/{ => legacy}/seeq8005.h (100%)
rename drivers/net/{ => legacy}/smc-mca.c (100%)
rename drivers/net/{ => legacy}/smc-ultra.c (100%)
rename drivers/net/{ => legacy}/smc-ultra32.c (100%)
rename drivers/net/{ => legacy}/smc9194.c (100%)
rename drivers/net/{ => legacy}/smc9194.h (100%)
rename drivers/net/{ => legacy}/sni_82596.c (100%)
rename drivers/net/{ => legacy}/stnic.c (100%)
rename drivers/net/{ => legacy}/sun3_82586.c (100%)
rename drivers/net/{ => legacy}/sun3_82586.h (100%)
rename drivers/net/{ => legacy}/sun3lance.c (100%)
rename drivers/net/{ => legacy}/wd.c (100%)
rename drivers/net/{ => legacy}/znet.c (100%)
rename drivers/net/{ => legacy}/zorro8390.c (100%)
^ permalink raw reply
* [PATCH 2.6.36/stable] vlan: Avoid hwaccel vlan packets when vid not used.
From: Jesse Gross @ 2010-10-28 23:19 UTC (permalink / raw)
To: David Miller; +Cc: Ben Greear, netdev
Normally hardware accelerated vlan packets are quickly dropped if
there is no corresponding vlan device configured. The one exception
is promiscuous mode, where we allow all of these packets through so
they can be picked up by tcpdump. However, this behavior causes a
crash if we actually try to receive these packets. This fixes that
crash by ignoring packets with vids not corresponding to a configured
device in the vlan hwaccel routines and then dropping them before they
get to consumers in the network stack.
Reported-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
--
Ben, this patch is pretty similar to yours, just with the addition of
the trap before bridging that I was describing.
---
net/8021q/vlan_core.c | 3 +++
net/core/dev.c | 13 +++++++++++++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index 0eb96f7..2dcff0b 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -43,6 +43,9 @@ int vlan_hwaccel_do_receive(struct sk_buff *skb)
struct net_device *dev = skb->dev;
struct vlan_rx_stats *rx_stats;
+ if (unlikely(!is_vlan_dev(dev)))
+ return 0;
+
skb->dev = vlan_dev_info(dev)->real_dev;
netif_nit_deliver(skb);
diff --git a/net/core/dev.c b/net/core/dev.c
index 660dd41..dd72996 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2891,6 +2891,19 @@ static int __netif_receive_skb(struct sk_buff *skb)
ncls:
#endif
+ /* If we got this far with a hardware accelerated VLAN tag, it means
+ * that we were put in promiscuous mode but nobody is interested in
+ * this vid. Drop the packet now to prevent it from getting propagated
+ * to other parts of the stack that won't know how to deal with packets
+ * tagged in this manner.
+ */
+ if (unlikely(vlan_tx_tag_present(skb))) {
+ if (pt_prev)
+ ret = pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
+ kfree_skb(skb);
+ goto out;
+ }
+
/* Handle special case of bridge or macvlan */
rx_handler = rcu_dereference(skb->dev->rx_handler);
if (rx_handler) {
--
1.7.1
^ permalink raw reply related
* Re: [patch v3] fix stack overflow in pktgen_if_write()
From: Andi Kleen @ 2010-10-28 23:11 UTC (permalink / raw)
To: Dan Carpenter
Cc: Nelson Elhage, Eric Dumazet, David S. Miller, Robert Olsson,
Andy Shevchenko, netdev
In-Reply-To: <20101028060529.GX6062@bicker>
Dan Carpenter <error27@gmail.com> writes:
> Reported-by: Nelson Elhage <nelhage@ksplice.com>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
> ---
> v3: just use kmalloc()
>
> diff --git a/net/core/pktgen.c b/net/core/pktgen.c
> index 2c0df0f..c8d3620 100644
> --- a/net/core/pktgen.c
> +++ b/net/core/pktgen.c
> @@ -887,12 +887,17 @@ static ssize_t pktgen_if_write(struct file *file,
> i += len;
>
> if (debug) {
> - char tb[count + 1];
> + char *tb;
> +
> + tb = kmalloc(count + 1, GFP_KERNEL);
This is still trivially exploitable (for root) -- think what happens
when count is near ULONG_MAX
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* [PATCH iproute2] macvlan/macvtap: support 'passthru' mode
From: Sridhar Samudrala @ 2010-10-28 23:10 UTC (permalink / raw)
To: Arnd Bergmann, Stephen Hemminger, Michael S. Tsirkin,
Patrick McHardy
Cc: netdev, kvm@vger.kernel.org
Add support for 'passthru' mode when creating a macvlan/macvtap device
which allows takeover of the underlying device and passing it to a KVM
guest using virtio with macvtap backend.
Only one macvlan device is allowed in passthru mode and it inherits
the mac address from the underlying device and sets it in promiscuous
mode to receive and forward all the packets.
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
-----------------------------------------------------------------------
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index f5bb2dc..23de79e 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -230,6 +230,7 @@ enum macvlan_mode {
MACVLAN_MODE_PRIVATE = 1, /* don't talk to other macvlans */
MACVLAN_MODE_VEPA = 2, /* talk to other ports through ext bridge */
MACVLAN_MODE_BRIDGE = 4, /* talk to bridge ports directly */
+ MACVLAN_MODE_PASSTHRU = 8, /* take over the underlying device */
};
/* SR-IOV virtual function management section */
diff --git a/ip/iplink_macvlan.c b/ip/iplink_macvlan.c
index a3c78bd..15022aa 100644
--- a/ip/iplink_macvlan.c
+++ b/ip/iplink_macvlan.c
@@ -23,14 +23,14 @@
static void explain(void)
{
fprintf(stderr,
- "Usage: ... macvlan mode { private | vepa | bridge }\n"
+ "Usage: ... macvlan mode { private | vepa | bridge | passthru }\n"
);
}
static int mode_arg(void)
{
fprintf(stderr, "Error: argument of \"mode\" must be \"private\", "
- "\"vepa\" or \"bridge\"\n");
+ "\"vepa\", \"bridge\" or \"passthru\" \n");
return -1;
}
@@ -48,6 +48,8 @@ static int macvlan_parse_opt(struct link_util *lu, int argc, char **argv,
mode = MACVLAN_MODE_VEPA;
else if (strcmp(*argv, "bridge") == 0)
mode = MACVLAN_MODE_BRIDGE;
+ else if (strcmp(*argv, "passthru") == 0)
+ mode = MACVLAN_MODE_PASSTHRU;
else
return mode_arg();
@@ -82,6 +84,7 @@ static void macvlan_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[]
mode == MACVLAN_MODE_PRIVATE ? "private"
: mode == MACVLAN_MODE_VEPA ? "vepa"
: mode == MACVLAN_MODE_BRIDGE ? "bridge"
+ : mode == MACVLAN_MODE_PASSTHRU ? "passthru"
: "unknown");
}
diff --git a/ip/iplink_macvtap.c b/ip/iplink_macvtap.c
index 35199b1..5665b6d 100644
--- a/ip/iplink_macvtap.c
+++ b/ip/iplink_macvtap.c
@@ -20,14 +20,14 @@
static void explain(void)
{
fprintf(stderr,
- "Usage: ... macvtap mode { private | vepa | bridge }\n"
+ "Usage: ... macvtap mode { private | vepa | bridge | passthru }\n"
);
}
static int mode_arg(void)
{
fprintf(stderr, "Error: argument of \"mode\" must be \"private\", "
- "\"vepa\" or \"bridge\"\n");
+ "\"vepa\", \"bridge\" or \"passthru\" \n");
return -1;
}
@@ -45,6 +45,8 @@ static int macvtap_parse_opt(struct link_util *lu, int argc, char **argv,
mode = MACVLAN_MODE_VEPA;
else if (strcmp(*argv, "bridge") == 0)
mode = MACVLAN_MODE_BRIDGE;
+ else if (strcmp(*argv, "passthru") == 0)
+ mode = MACVLAN_MODE_PASSTHRU;
else
return mode_arg();
@@ -79,6 +81,7 @@ static void macvtap_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[]
mode == MACVLAN_MODE_PRIVATE ? "private"
: mode == MACVLAN_MODE_VEPA ? "vepa"
: mode == MACVLAN_MODE_BRIDGE ? "bridge"
+ : mode == MACVLAN_MODE_PASSTHRU ? "passthru"
: "unknown");
}
^ permalink raw reply related
* [PATCH] macvlan: Introduce 'passthru' mode to takeover the underlying device
From: Sridhar Samudrala @ 2010-10-28 23:10 UTC (permalink / raw)
To: Arnd Bergmann, Patrick McHardy, Stephen Hemminger,
Michael S. Tsirkin
Cc: netdev, kvm@vger.kernel.org
With the current default 'vepa' mode, a KVM guest using virtio with
macvtap backend has the following limitations.
- cannot change/add a mac address on the guest virtio-net
- cannot create a vlan device on the guest virtio-net
- cannot enable promiscuous mode on guest virtio-net
To address these limitations, this patch introduces a new mode called
'passthru' when creating a macvlan device which allows takeover of the
underlying device and passing it to a guest using virtio with macvtap
backend.
Only one macvlan device is allowed in passthru mode and it inherits
the mac address from the underlying device and sets it in promiscuous
mode to receive and forward all the packets.
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
-------------------------------------------------------------------------
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 0ef0eb0..bca3cb7 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -38,6 +38,7 @@ struct macvlan_port {
struct hlist_head vlan_hash[MACVLAN_HASH_SIZE];
struct list_head vlans;
struct rcu_head rcu;
+ bool passthru;
};
#define macvlan_port_get_rcu(dev) \
@@ -169,6 +170,7 @@ static struct sk_buff *macvlan_handle_frame(struct sk_buff *skb)
macvlan_broadcast(skb, port, NULL,
MACVLAN_MODE_PRIVATE |
MACVLAN_MODE_VEPA |
+ MACVLAN_MODE_PASSTHRU|
MACVLAN_MODE_BRIDGE);
else if (src->mode == MACVLAN_MODE_VEPA)
/* flood to everyone except source */
@@ -185,7 +187,10 @@ static struct sk_buff *macvlan_handle_frame(struct sk_buff *skb)
return skb;
}
- vlan = macvlan_hash_lookup(port, eth->h_dest);
+ if (port->passthru)
+ vlan = list_first_entry(&port->vlans, struct macvlan_dev, list);
+ else
+ vlan = macvlan_hash_lookup(port, eth->h_dest);
if (vlan == NULL)
return skb;
@@ -284,6 +289,11 @@ static int macvlan_open(struct net_device *dev)
struct net_device *lowerdev = vlan->lowerdev;
int err;
+ if (vlan->port->passthru) {
+ dev_set_promiscuity(lowerdev, 1);
+ goto hash_add;
+ }
+
err = -EBUSY;
if (macvlan_addr_busy(vlan->port, dev->dev_addr))
goto out;
@@ -296,6 +306,8 @@ static int macvlan_open(struct net_device *dev)
if (err < 0)
goto del_unicast;
}
+
+hash_add:
macvlan_hash_add(vlan);
return 0;
@@ -310,12 +322,18 @@ static int macvlan_stop(struct net_device *dev)
struct macvlan_dev *vlan = netdev_priv(dev);
struct net_device *lowerdev = vlan->lowerdev;
+ if (vlan->port->passthru) {
+ dev_set_promiscuity(lowerdev, -1);
+ goto hash_del;
+ }
+
dev_mc_unsync(lowerdev, dev);
if (dev->flags & IFF_ALLMULTI)
dev_set_allmulti(lowerdev, -1);
dev_uc_del(lowerdev, dev->dev_addr);
+hash_del:
macvlan_hash_del(vlan);
return 0;
}
@@ -549,6 +567,7 @@ static int macvlan_port_create(struct net_device *dev)
if (port == NULL)
return -ENOMEM;
+ port->passthru = false;
port->dev = dev;
INIT_LIST_HEAD(&port->vlans);
for (i = 0; i < MACVLAN_HASH_SIZE; i++)
@@ -593,6 +612,7 @@ static int macvlan_validate(struct nlattr *tb[], struct nlattr *data[])
case MACVLAN_MODE_PRIVATE:
case MACVLAN_MODE_VEPA:
case MACVLAN_MODE_BRIDGE:
+ case MACVLAN_MODE_PASSTHRU:
break;
default:
return -EINVAL;
@@ -661,6 +681,10 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
}
port = macvlan_port_get(lowerdev);
+ /* Only 1 macvlan device can be created in passthru mode */
+ if (port->passthru)
+ return -EINVAL;
+
vlan->lowerdev = lowerdev;
vlan->dev = dev;
vlan->port = port;
@@ -671,6 +695,13 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
if (data && data[IFLA_MACVLAN_MODE])
vlan->mode = nla_get_u32(data[IFLA_MACVLAN_MODE]);
+ if (vlan->mode == MACVLAN_MODE_PASSTHRU) {
+ if (!list_empty(&port->vlans))
+ return -EINVAL;
+ port->passthru = true;
+ memcpy(dev->dev_addr, lowerdev->dev_addr, ETH_ALEN);
+ }
+
err = register_netdevice(dev);
if (err < 0)
goto destroy_port;
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 2fc66dd..8454805 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -232,6 +232,7 @@ enum macvlan_mode {
MACVLAN_MODE_PRIVATE = 1, /* don't talk to other macvlans */
MACVLAN_MODE_VEPA = 2, /* talk to other ports through ext bridge */
MACVLAN_MODE_BRIDGE = 4, /* talk to bridge ports directly */
+ MACVLAN_MODE_PASSTHRU = 8,/* take over the underlying device */
};
/* SR-IOV virtual function management section */
^ permalink raw reply related
* [PATCH iproute2] Support 'mode' parameter when creating macvtap device
From: Sridhar Samudrala @ 2010-10-28 23:10 UTC (permalink / raw)
To: Arnd Bergmann, Stephen Hemminger, Patrick McHardy,
Michael S. Tsirkin
Cc: netdev, kvm@vger.kernel.org
Add support for 'mode' parameter when creating a macvtap device.
This allows a macvtap device to be created in bridge, private or
the default vepa modes.
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
-------------------------------------------------------------------
diff --git a/ip/Makefile b/ip/Makefile
index 2f223ca..6054e8a 100644
--- a/ip/Makefile
+++ b/ip/Makefile
@@ -3,7 +3,7 @@ IPOBJ=ip.o ipaddress.o ipaddrlabel.o iproute.o iprule.o \
ipmaddr.o ipmonitor.o ipmroute.o ipprefix.o iptuntap.o \
ipxfrm.o xfrm_state.o xfrm_policy.o xfrm_monitor.o \
iplink_vlan.o link_veth.o link_gre.o iplink_can.o \
- iplink_macvlan.o
+ iplink_macvlan.o iplink_macvtap.o
RTMONOBJ=rtmon.o
diff --git a/ip/iplink_macvtap.c b/ip/iplink_macvtap.c
new file mode 100644
index 0000000..35199b1
--- /dev/null
+++ b/ip/iplink_macvtap.c
@@ -0,0 +1,90 @@
+/*
+ * iplink_macvtap.c macvtap device support
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <sys/socket.h>
+#include <linux/if_link.h>
+
+#include "rt_names.h"
+#include "utils.h"
+#include "ip_common.h"
+
+static void explain(void)
+{
+ fprintf(stderr,
+ "Usage: ... macvtap mode { private | vepa | bridge }\n"
+ );
+}
+
+static int mode_arg(void)
+{
+ fprintf(stderr, "Error: argument of \"mode\" must be \"private\", "
+ "\"vepa\" or \"bridge\"\n");
+ return -1;
+}
+
+static int macvtap_parse_opt(struct link_util *lu, int argc, char **argv,
+ struct nlmsghdr *n)
+{
+ while (argc > 0) {
+ if (matches(*argv, "mode") == 0) {
+ __u32 mode = 0;
+ NEXT_ARG();
+
+ if (strcmp(*argv, "private") == 0)
+ mode = MACVLAN_MODE_PRIVATE;
+ else if (strcmp(*argv, "vepa") == 0)
+ mode = MACVLAN_MODE_VEPA;
+ else if (strcmp(*argv, "bridge") == 0)
+ mode = MACVLAN_MODE_BRIDGE;
+ else
+ return mode_arg();
+
+ addattr32(n, 1024, IFLA_MACVLAN_MODE, mode);
+ } else if (matches(*argv, "help") == 0) {
+ explain();
+ return -1;
+ } else {
+ fprintf(stderr, "macvtap: what is \"%s\"?\n", *argv);
+ explain();
+ return -1;
+ }
+ argc--, argv++;
+ }
+
+ return 0;
+}
+
+static void macvtap_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
+{
+ __u32 mode;
+
+ if (!tb)
+ return;
+
+ if (!tb[IFLA_MACVLAN_MODE] ||
+ RTA_PAYLOAD(tb[IFLA_MACVLAN_MODE]) < sizeof(__u32))
+ return;
+
+ mode = *(__u32 *)RTA_DATA(tb[IFLA_VLAN_ID]);
+ fprintf(f, " mode %s ",
+ mode == MACVLAN_MODE_PRIVATE ? "private"
+ : mode == MACVLAN_MODE_VEPA ? "vepa"
+ : mode == MACVLAN_MODE_BRIDGE ? "bridge"
+ : "unknown");
+}
+
+struct link_util macvtap_link_util = {
+ .id = "macvtap",
+ .maxattr = IFLA_MACVLAN_MAX,
+ .parse_opt = macvtap_parse_opt,
+ .print_opt = macvtap_print_opt,
+};
^ permalink raw reply related
* Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link
From: Maciej Żenczykowski @ 2010-10-28 22:50 UTC (permalink / raw)
To: Lorenzo Colitti; +Cc: netdev, Brian Haley
In-Reply-To: <AANLkTim-2ghTVVEaJesMkXcRL-eCPBoHkehKF8HXhyK+@mail.gmail.com>
> It's random, but the random interface ID is a property of the
> interface, not of the address, and thus survives interface up/down:
Interesting, that actually means a link down/up will break the
temporary address lifetimes (reset them).
# uname -a
Linux nike 2.6.34.7-61.fc13.x86_64 #1 SMP Tue Oct 19 04:06:30 UTC 2010
x86_64 x86_64 x86_64 GNU/Linux
# echo --Dump--; ip -6 addr list dev eth0 secondary; echo --Down--; ip
link set eth0 down; echo --Dump--; ip -6 addr list dev eth0 secondary;
echo --Up--; ip link set eth0 up; echo --Dump--; ip -6 addr list dev
eth0 secondary; echo --Sleep30--; sleep 30; echo --Dump--; ip -6 addr
list dev eth0 secondary; echo --Sleep60--; sleep 60; echo --Dump--; ip
-6 addr list dev eth0 secondary; echo --Done--
--Dump--
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2620:0:1000:1301:ab:5938:64ce:ae20/64 scope global temporary dynamic
valid_lft 604667sec preferred_lft 85667sec
--Down--
--Dump--
--Up--
--Dump--
--Sleep30--
--Dump--
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2620:0:1000:1301:ab:5938:64ce:ae20/64 scope global temporary dynamic
valid_lft 604775sec preferred_lft 85775sec
--Sleep60--
--Dump--
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2620:0:1000:1301:ab:5938:64ce:ae20/64 scope global temporary dynamic
valid_lft 604715sec preferred_lft 85715sec
--Done--
Notice that when the v6 temp address comes back (presumably after
receiving an RA) it comes back with fresh valid/preferred lifetimes,
instead of the already partially expired ones that we had before the
link went down.
I was already aware that v6 temp addresses didn't work all that well
with short RA timeouts, but it looks like the logic needs a bit more
tweaking...
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link
From: Lorenzo Colitti @ 2010-10-28 22:41 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: netdev, Brian Haley
In-Reply-To: <AANLkTim-2ghTVVEaJesMkXcRL-eCPBoHkehKF8HXhyK+@mail.gmail.com>
On Thu, Oct 28, 2010 at 3:23 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
> It's random, but the random interface ID is a property of the
> interface, not of the address, and thus survives interface up/down:
Also note that it's fairly trivial, instead of deleting all privacy
addresses when link is lost, to simply deprecate them so they
automatically come back after link comes back if an RA refreshes their
lifetime.
I'd rather not do this, because it introduces a brief window on link
up where the system has broken IPv6 connectivity and all connection
attempts hang for three minutes. But if this is the only alternative
to the current behaviour (where all connection attempts hang forever
until all old addresses have exhausted their lifetimes), then we can
do it.
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link
From: Lorenzo Colitti @ 2010-10-28 22:23 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: netdev, Brian Haley
In-Reply-To: <AANLkTi=AyYrmSWDTZVWb2s+jgnyjNyHo-fkV4U+Fm45n@mail.gmail.com>
On Wed, Oct 27, 2010 at 1:39 PM, Maciej Żenczykowski
<zenczykowski@gmail.com> wrote:
> static int __ipv6_regen_rndid(struct inet6_dev *idev) {
> get_random_bytes(idev->rndid, sizeof(idev->rndid));
> idev->rndid[0] &= ~0x02;
>
> certainly seem to point towards it being totally random.
It's random, but the random interface ID is a property of the
interface, not of the address, and thus survives interface up/down:
# ip -6 a li dev wlan0 secondary
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2620:0:1000:fd01:952f:2586:ed6f:408c/64 scope global
secondary dynamic
valid_lft 604363sec preferred_lft 85363sec
# ip link set wlan0 down
# ip -6 a li dev wlan0 secondary
# ip link set wlan0 up
# ip -6 a li dev wlan0 secondary
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2620:0:1000:167d:952f:2586:ed6f:408c/64 scope global
secondary dynamic
valid_lft 604799sec preferred_lft 85799sec
^ permalink raw reply
* Re: [PATCH 1/5] netdev: bfin_mac: clean up printk messages
From: David Miller @ 2010-10-28 22:15 UTC (permalink / raw)
To: vapier; +Cc: netdev, uclinux-dist-devel
In-Reply-To: <1288078827-17495-1-git-send-email-vapier@gentoo.org>
These patches don't apply cleanly to the current tree.
Please respin these and resubmit.
Thanks.
^ permalink raw reply
* Re: [PATCH ethtool 0/7] Update RX n-tuple filtering
From: Jeff Garzik @ 2010-10-28 22:02 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1285278428.7794.27.camel@achroite.uk.solarflarecom.com>
On 09/23/2010 05:47 PM, Ben Hutchings wrote:
> This patch series brings ethtool up to date with my recent changes to RX
> n-tuple filtering in the kernel.
>
> Ben.
>
> Ben Hutchings (7):
> ethtool-copy.h: sync with net-next
> ethtool: Generalise cmdline_info::unwanted_val to a "seen" flag or
> bitmask
> ethtool: Fix RX n-tuple masks and documentation
> ethtool: Add MAC parameter type based on the parse_sopass() function
> ethtool: Add Ethernet-level RX n-tuple filtering and 'clear' action
> ethtool: Update sfc register dump
> ethtool: Add my authorship and Solarflare copyright notice
>
> AUTHORS | 1 +
> ethtool-copy.h | 228 +++++++++++++++++++++++++++++++++---------------
> ethtool.8 | 79 ++++++++++++-----
> ethtool.c | 265 +++++++++++++++++++++++++++++++++++++++++---------------
> sfc.c | 25 +++---
Looks good... will push into this release (ethtool 2.6.36)
^ permalink raw reply
* Re: ethtool: missing implementation of n_priv_flags
From: Jeff Garzik @ 2010-10-28 21:59 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Brandeburg, Jesse, netdev@vger.kernel.org, Wyborny, Carolyn
In-Reply-To: <20101028215417.GL15074@solarflare.com>
On Thu, Oct 28, 2010 at 10:54:18PM +0100, Ben Hutchings wrote:
> Brandeburg, Jesse wrote:
> [...]
> > We'll take a shot at an implementation in the ethtool proper and post it
> > (hopefully soon). I imagine it will just be printed when one runs the
> > command
> > # ethtool ethX
> >
> > and the set side will probably be implemented as part of -s
> >
> > # ethtool -s ethX pflag [0-0xFFFFFFFF]
>
> This is crap. Use ETHTOOL_GSTRINGS with string_set = ETH_SS_PRIV_FLAGS
> to get the flag names, then convert that array into an array of struct
> cmdline_info and parse the flags by name.
Indeed. It was intended to be a flexible interface where a driver can
easily pass arbitrary text-named flags to the user for setting/clearing.
If e1000e has a special Intel-specific feature that makes the NIC
process packets more rapidly, you could select the string "go_faster" in
the ethtool private flags interface. The ethtool utility reads the
strings, which determine the flags exported for that network interface.
Jeff
^ permalink raw reply
* Re: ethtool: missing implementation of n_priv_flags
From: Ben Hutchings @ 2010-10-28 21:54 UTC (permalink / raw)
To: Brandeburg, Jesse
Cc: jgarzik@redhat.com, netdev@vger.kernel.org, Wyborny, Carolyn
In-Reply-To: <alpine.WNT.2.00.1010281405001.11080@jbrandeb-desk1.amr.corp.intel.com>
Brandeburg, Jesse wrote:
[...]
> We'll take a shot at an implementation in the ethtool proper and post it
> (hopefully soon). I imagine it will just be printed when one runs the
> command
> # ethtool ethX
>
> and the set side will probably be implemented as part of -s
>
> # ethtool -s ethX pflag [0-0xFFFFFFFF]
This is crap. Use ETHTOOL_GSTRINGS with string_set = ETH_SS_PRIV_FLAGS
to get the flag names, then convert that array into an array of struct
cmdline_info and parse the flags by name.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: ethtool: missing implementation of n_priv_flags
From: Jeff Garzik @ 2010-10-28 21:53 UTC (permalink / raw)
To: Brandeburg, Jesse; +Cc: netdev@vger.kernel.org, Wyborny, Carolyn
In-Reply-To: <F169D4F5E1F1974DBFAFABF47F60C10AA5E60671@orsmsx507.amr.corp.intel.com>
On Thu, Oct 28, 2010 at 01:34:34PM -0700, Brandeburg, Jesse wrote:
> Was just looking at implementing the driver private flags to add a new feature to
> a driver.
>
> It appears that nothing in the core ethtool.c ever accesses or prints n_priv_flags,
> even if a driver assigns it (which none in the kernel currently do)
>
> Is this just an oversight?
It was waiting for the first user, basically... I created an example
kernel patch for one Intel driver, but you guys didn't seem interested
in it at the time. Glad to see it's getting some attention.
Jeff
^ permalink raw reply
* Re: [RFC PATCH 1/1] vhost: TX used buffer guest signal accumulation
From: Shirley Ma @ 2010-10-28 21:40 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: Michael S. Tsirkin, David Miller, netdev, kvm, linux-kernel
In-Reply-To: <1288299878.30131.2.camel@sridhar.beaverton.ibm.com>
On Thu, 2010-10-28 at 14:04 -0700, Sridhar Samudrala wrote:
> It would be some change in virtio-net driver that may have improved
> the
> latency of small messages which in turn would have reduced the
> bandwidth
> as TCP could not accumulate and send large packets.
I will check out any latency improvement patch in virtio_net. If that's
the case, whether it is good to have some tunable parameter to benefit
both BW and latency workload?
Shirley
^ permalink raw reply
* Re: [PATCH] cxgb4vf: fix crash due to manipulating queues before registration
From: Casey Leedom @ 2010-10-28 21:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20101028.132122.245402585.davem@davemloft.net>
On Oct 28, 2010, at 1:21 PM, David Miller wrote:
> From: Casey Leedom <leedom@chelsio.com>
> Date: Thu, 28 Oct 2010 13:16:47 -0700
>
>> Before commit "net: allocate tx queues in register_netdevice"
>> netif_tx_stop_all_queues and related functions could be used between
>> device allocation and registration but now only after registration.
>> cxgb4 has such a call before registration and crashes now. Move it
>> after register_netdev.
>>
>> Signed-off-by: Casey Leedom <leedom@chelsio.com>
>
> Why are you manipulating the queue at all here?
>
> The queue state is "don't care" at this point in time,
> and has no meaning until ->open() is invoked.
True. This driver was modeled on cxgb4, we wanted to make sure that the cxgb4 crash fix is ported to cxgb4vf. Let me sync up with the other Chelsio maintainers.
Casey
^ permalink raw reply
* Re: ethtool: missing implementation of n_priv_flags
From: Brandeburg, Jesse @ 2010-10-28 21:10 UTC (permalink / raw)
To: Ben Hutchings
Cc: jgarzik@redhat.com, netdev@vger.kernel.org, Wyborny, Carolyn
In-Reply-To: <20101028210024.GK15074@solarflare.com>
On Thu, 28 Oct 2010, Ben Hutchings wrote:
> Brandeburg, Jesse wrote:
> > Was just looking at implementing the driver private flags to add a new feature to
> > a driver.
> >
> > It appears that nothing in the core ethtool.c ever accesses or prints n_priv_flags,
> > even if a driver assigns it (which none in the kernel currently do)
> [...]
>
> You mean net/core/ethtool.c? Or the ethtool utility?
The ethtool utility (the app that would print the 1-1 match between bits
and strings)
> If you set it in your get_drvinfo() operation then it will be copied out.
> As for the ethtool utility, I've implemented some generic flag parsing and
> printing functionality so it shouldn't be too hard to use that for private
> flags.
Right, I see the code where it gets copied into drvinfo in the kernel but
nothing ever prints it on the userspace side.
We'll take a shot at an implementation in the ethtool proper and post it
(hopefully soon). I imagine it will just be printed when one runs the
command
# ethtool ethX
and the set side will probably be implemented as part of -s
# ethtool -s ethX pflag [0-0xFFFFFFFF]
^ permalink raw reply
* Re: [RFC PATCH 1/1] vhost: TX used buffer guest signal accumulation
From: Sridhar Samudrala @ 2010-10-28 21:04 UTC (permalink / raw)
To: Shirley Ma; +Cc: Michael S. Tsirkin, David Miller, netdev, kvm, linux-kernel
In-Reply-To: <1288296835.11251.24.camel@localhost.localdomain>
On Thu, 2010-10-28 at 13:13 -0700, Shirley Ma wrote:
> On Thu, 2010-10-28 at 12:32 -0700, Shirley Ma wrote:
> > Also I found a big TX regression for old guest and new guest. For old
> > guest, I am able to get almost 11Gb/s for 2K message size, but for the
> > new guest kernel, I can only get 3.5 Gb/s with the patch and same
> > host.
> > I will dig it why.
>
> The regression is from guest kernel, not from this patch. Tested 2.6.31
> kernel, it's performance is less than 2Gb/s for 2K message size already.
> I will resubmit the patch for review.
>
> I will start to test from 2.6.30 kernel to figure it when TX regression
> induced in virtio_net. Any suggestion which guest kernel I should test
> to figure out this regression?
It would be some change in virtio-net driver that may have improved the
latency of small messages which in turn would have reduced the bandwidth
as TCP could not accumulate and send large packets.
Thanks
Sridhar
^ permalink raw reply
* Re: ethtool: missing implementation of n_priv_flags
From: Ben Hutchings @ 2010-10-28 21:00 UTC (permalink / raw)
To: Brandeburg, Jesse
Cc: jgarzik@redhat.com, netdev@vger.kernel.org, Wyborny, Carolyn
In-Reply-To: <F169D4F5E1F1974DBFAFABF47F60C10AA5E60671@orsmsx507.amr.corp.intel.com>
Brandeburg, Jesse wrote:
> Was just looking at implementing the driver private flags to add a new feature to
> a driver.
>
> It appears that nothing in the core ethtool.c ever accesses or prints n_priv_flags,
> even if a driver assigns it (which none in the kernel currently do)
[...]
You mean net/core/ethtool.c? Or the ethtool utility?
If you set it in your get_drvinfo() operation then it will be copied out.
As for the ethtool utility, I've implemented some generic flag parsing and
printing functionality so it shouldn't be too hard to use that for private
flags.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: multi-machine simultaneous kernel panic in tcp_transmit_kcb
From: Ben Hutchings @ 2010-10-28 20:42 UTC (permalink / raw)
To: Doug Hughes; +Cc: netdev
In-Reply-To: <4CC8CC0A.5000705@will.to>
Doug Hughes wrote:
> 3 machines within 1 minute of each other (odd, by itself, but not the
> root of the question).
>
> 2 of this:
> 2.6.18-164.15.1.el5 #1 SMP Wed Mar 17 11:30:06 EDT 2010 x86_64 x86_64
> x86_64 GNU/Linux
> (I have a screen shot on the kvm)
> all Cent 5.4
[...]
Please don't ask netdev to support an old distribution kernel. Try
asking on CentOS support forums or buy support from Red Hat.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox