| Message ID | 1288315159-1350-6-git-send-email-paul.gortmaker@windriver.com |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
On Thu, 28 Oct 2010, Paul Gortmaker wrote: > 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. NAK for the TURBOchannel bits (defxx.[ch] and declance.c) unless you give a plausible justification. You won't get these drivers offered unless you have the bus in your system anyway, and if you do than you don't want to have them hidden somewhere in the corner. If you see anything wrong with these drivers, then please do let me know. Also defxx.c is PCI too (apart from being EISA and TC). > 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 Maciej -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: "Maciej W. Rozycki" <macro@linux-mips.org> Date: Fri, 29 Oct 2010 05:21:35 +0100 (BST) > On Thu, 28 Oct 2010, Paul Gortmaker wrote: > >> 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. > > NAK for the TURBOchannel bits (defxx.[ch] and declance.c) unless you give > a plausible justification. You won't get these drivers offered unless you > have the bus in your system anyway, and if you do than you don't want to > have them hidden somewhere in the corner. If you see anything wrong with > these drivers, then please do let me know. > > Also defxx.c is PCI too (apart from being EISA and TC). PCI things can be legacy too. This is not about a specific bus technology, it's simply for "really old stuff" so we can declutter the top-level of drivers/net -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 28 Oct 2010, David Miller wrote: > > NAK for the TURBOchannel bits (defxx.[ch] and declance.c) unless you give > > a plausible justification. You won't get these drivers offered unless you > > have the bus in your system anyway, and if you do than you don't want to > > have them hidden somewhere in the corner. If you see anything wrong with > > these drivers, then please do let me know. > > > > Also defxx.c is PCI too (apart from being EISA and TC). > > PCI things can be legacy too. > > This is not about a specific bus technology, it's simply for > "really old stuff" so we can declutter the top-level of drivers/net Hmm, what's the difference between placing these drivers here or there and what's so particular about them that they cause clutter? I mean a mere high number of items does not cause a mess by itself -- the lack of order might. Also -- if this change goes ahead -- when I add new TURBOchannel drivers, should they go straight to legacy/? It sounds odd to me to have a thing obsolete straight from the beginning. Maciej -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 29 Oct 2010, Maciej W. Rozycki wrote: > > This is not about a specific bus technology, it's simply for > > "really old stuff" so we can declutter the top-level of drivers/net > > Hmm, what's the difference between placing these drivers here or there > and what's so particular about them that they cause clutter? I mean a > mere high number of items does not cause a mess by itself -- the lack of > order might. I have given myself some food for thought and have come up with the following proposal: how about simply classifying drivers according to the physical layer they support or if multiple are, such as with the Ethernet that is backwards compatible, the newest variation they do? This would be no different to what we do wrt network protocols under net/, so drivers would go to ethernet/, fasteth/, gbeth/, 10gbeth/, fddi/, tokenring/, atm/, appletalk/, etc. (names up to debate if need be) as applicable. This would scale well, avoid the need for arbitrary decisions (is this piece legacy yet or not?) and automatically classify drivers as more or less obsolescent too, as obviously none of the stuff under ethernet/, fddi/ or tokenring/ can be reasonably recent unlike 10gbeth/. Software stuff such as SLIP or PPP could go either into separate subdirectories or grouped together under software/; I gather we have a few such pieces only. What do you think? Maciej -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: "Maciej W. Rozycki" <macro@linux-mips.org> Date: Fri, 29 Oct 2010 05:54:56 +0100 (BST) > Hmm, what's the difference between placing these drivers here or there > and what's so particular about them that they cause clutter? I mean a > mere high number of items does not cause a mess by itself -- the lack of > order might. > > Also -- if this change goes ahead -- when I add new TURBOchannel drivers, > should they go straight to legacy/? It sounds odd to me to have a thing > obsolete straight from the beginning. This patch series started with a "0/15" introduction posting which explains the intention and reasoning. It might be easier for you to read it instead of asking me to repeat it's contents :-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 28 Oct 2010, David Miller wrote: > This patch series started with a "0/15" introduction posting which > explains the intention and reasoning. Well, I didn't reach it (ENOBREAKFAST that has been fixed since ;) ), but I sort of guessed it anyway and didn't like the arbitrary nature of assigning drivers to legacy/. > It might be easier for you to read it instead of asking me to repeat > it's contents :-) See my proposal that crossed with your e-mail. I think it fits the purpose very well. :) Maciej -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: "Maciej W. Rozycki" <macro@linux-mips.org> Date: Fri, 29 Oct 2010 06:46:13 +0100 (BST) > This would be no different to what we do wrt network protocols under > net/, so drivers would go to ethernet/, fasteth/, gbeth/, 10gbeth/, fddi/, > tokenring/, atm/, appletalk/, etc. (names up to debate if need be) as > applicable. This would scale well, avoid the need for arbitrary decisions > (is this piece legacy yet or not?) and automatically classify drivers as > more or less obsolescent too, as obviously none of the stuff under > ethernet/, fddi/ or tokenring/ can be reasonably recent unlike 10gbeth/. Why are you so hung up about something being called legacy? I would be proud to be labelled "legacy", as that means I've served a purpose for a long time and some folks even want or need me to stick around for a bit longer. Legacy hardware is just old and the drivers for them are in a purely "sustaining" state, that is all. And using link layer technology to classify is really stupid since many devices match multiple of the categories you've suggested. I think the existing proposal is just fine. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: "Maciej W. Rozycki" <macro@linux-mips.org> Date: Fri, 29 Oct 2010 06:50:17 +0100 (BST) > On Thu, 28 Oct 2010, David Miller wrote: > >> It might be easier for you to read it instead of asking me to repeat >> it's contents :-) > > See my proposal that crossed with your e-mail. I think it fits the > purpose very well. :) No, it's foolish, see my reply. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 28 Oct 2010, David Miller wrote: > > See my proposal that crossed with your e-mail. I think it fits the > > purpose very well. :) > > No, it's foolish, see my reply. Well, you are the maintainer, so it's your call. I disagree and I have given what I believe is a reasonable justification, but that's about as much as I can do -- I can't force it onto you. As I say my concern is about the arbitrary assignment and not things being called "legacy" or "best-ever", "pre-y2k", or whatever. And splitting a bunch of pieces of software that are loosely related to one another into two bunches isn't going to reduce clutter, but to spread it instead -- now you'll have clutter in two places rather than just one, so I think the change is just missing the point. Again, as the maintainer it's your right to disagree. Thank you for the time you've taken to consider my comments nonetheless. Maciej -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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/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