On Fri, 21 Jul 2000, Dennis wrote: > >I expect, given your posting history, that you want Linux to be just a clone > >of BSD, and want BSD/Sun style naming. We made the decision in 1992 that > No, I use BSD as an example of an OS that does usually things right, that > doesnt lock up under load and that has consistency across drivers. So shoot > me. What I'd like is for people to realize that LINUX is only suitable to > penguinites... I was told in private email that you were just posting to create a flame war, not for any constructive reason. There is a difference between trying to make the system better, and just trying to create chaos and bogus features. Your messages are solidly in the latter category. Most people should skip the remaining technical part of this reply, as I am just humoring Dennis. Just remember: don't add kernel bloat because of one shrill demand for features. > >> its pretty difficult to label an enclosure when the port changes depending > >> on what cards you have in the box. > >> > >> How can the behavior be modified? > > > >Easily. And I pointed out how. Don't use the "eth%d" name to set up your > >machine. Use the MAC/station address. This is a unique ID number that > >precisely identifies the PCI card in use. This assures you are configuring > >the device that you expect, without needed to guess how the slots are > >numbered or what bus bridges exist. > > LOL. Donald, you need to get out more. You're going to try to tell some > bozo who barely knows how to find the on/off switch to "review the mac > addresses and plug in his cables accordingly"? What color is the sky in > your world? :-) No. I'm saying that you have a unique requirement. Your requirements can be solved in user space. It is not a kernel, network stack, or driver issue. Insisting that code need to be put into the kernel to change the behavior is demanding more kernel bloat. > This is not a real-world solution. As some point LINUX has to become > workable in the general population, not just among hackers. Most real-world machines have a single network interface. In the LAN world it's 99% likely that it's a single Ethernet connection. We have chosen to consistently name that connection "eth0". This has resulted in much simplified documentation vs. the alternatives. Specially, the BSD approach was good when there was only one or two variants of each device type. It is *bad* in the modern world and will only get worse. > >Linux supported five types by the end of 1992, triple that number by 1993 > >and zillions now. People would be driven insane if we had "wd0" and "ne0" > >and "fz0" and "tc0" and "hp0" and "tu0" and ... > > At least I know what card they are using when they write for support. With > linux I have to get some brain-dead, MSCE in-progress college student to > figure our which driver was scanned first, or we have to review the bootup > code ourselves. The problem here would be the same regardless of the name > since it only occurs when both controllers are the save driver. So whether > they are named eth0 and eth1 or fxp0 or fxp1 doesnt make much difference. Do you know the difference between a 21040 and 21143-TD? Or even a 21143-TC vs TD? That is an important difference, one having a new interface name prefix for each major card type doesn't address. So you need the detection information to track down problems anyway. Embedding a useless-alone subset of debugging information in the interface name just makes it difficult for the system users without providing any real benefit. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Beowulf Clusters / Linux Installations Annapolis MD 21403 - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.rutgers.edu
