diff for duplicates of <20091010113219.3136fb8b@s6510> diff --git a/a/1.txt b/N1/1.txt index 7e42f1f..d74e77e 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -30,7 +30,7 @@ Matt Domsch <Matt_Domsch@dell.com> wrote: > loaded played a role in determining the name of the device. Drivers > loaded first would get their devices named first. If I have two types > of devices, say an e100-driven NIC and a tg3-driven NIC, I could -> figure out that the names would be eth0á00 and eth1=tg3 by setting +> figure out that the names would be eth0=e100 and eth1=tg3 by setting > the load order in /etc/modules.conf (now modprobe.conf). If I wanted > the other order, fine, just switch it around in modules.conf and > reboot. OS installers, being the first running instance of Linux, @@ -63,7 +63,7 @@ Matt Domsch <Matt_Domsch@dell.com> wrote: > device; if the device is a bridge, scan the busses behind it.). This > caused NICs on bus 0 device 5, and bus 1 device 3, (eth0 and 1 > respectively) to be enumerated differently due to the a bridge from -> bus 0 to bus 1 at 0:4. My crude hack of pci¿sort, with some dmi +> bus 0 to bus 1 at 0:4. My crude hack of pci=bfsort, with some dmi > strings to match and auto-enable, at least reverted this back to the > ordering the 2.4 kernel and Windows used. Now we have to keep adding > systems to this DMI list (Dell has a number of systems on this list diff --git a/a/content_digest b/N1/content_digest index 2e380d4..30993fc 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -5,7 +5,7 @@ "ref\020091010044056.GA5350@mock.linuxdev.us.dell.com\0" "From\0Stephen Hemminger <shemminger@vyatta.com>\0" "Subject\0Re: PATCH: Network Device Naming mechanism and policy\0" - "Date\0Sat, 10 Oct 2009 18:32:19 +0000\0" + "Date\0Sat, 10 Oct 2009 11:32:19 -0700\0" "To\0Matt Domsch <Matt_Domsch@dell.com>\0" "Cc\0netdev@vger.kernel.org" linux-hotplug@vger.kernel.org @@ -45,7 +45,7 @@ "> loaded played a role in determining the name of the device. Drivers\n" "> loaded first would get their devices named first. If I have two types\n" "> of devices, say an e100-driven NIC and a tg3-driven NIC, I could\n" - "> figure out that the names would be eth0\303\24100 and eth1=tg3 by setting\n" + "> figure out that the names would be eth0=e100 and eth1=tg3 by setting\n" "> the load order in /etc/modules.conf (now modprobe.conf). If I wanted\n" "> the other order, fine, just switch it around in modules.conf and\n" "> reboot. OS installers, being the first running instance of Linux,\n" @@ -78,7 +78,7 @@ "> device; if the device is a bridge, scan the busses behind it.). This\n" "> caused NICs on bus 0 device 5, and bus 1 device 3, (eth0 and 1\n" "> respectively) to be enumerated differently due to the a bridge from\n" - "> bus 0 to bus 1 at 0:4. My crude hack of pci\302\277sort, with some dmi\n" + "> bus 0 to bus 1 at 0:4. My crude hack of pci=bfsort, with some dmi\n" "> strings to match and auto-enable, at least reverted this back to the\n" "> ordering the 2.4 kernel and Windows used. Now we have to keep adding\n" "> systems to this DMI list (Dell has a number of systems on this list\n" @@ -196,4 +196,4 @@ "in slot 0, it will come back with the same name. This is not what server\n" customers expect. -e02526b19b8b1b712b08d58993fe5d903da4255234fb3cd6206c1ba53e19c430 +cf82fef6833f85b4dfccf14a7fc9104a55d225b0b7eec3a58e5551ca1f2c86de
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.