| 1 |
On Fri, Mar 16, 2012 at 15:41, Joost Roeleveld <joost@××××××××.org> wrote: |
| 2 |
> On Friday, March 16, 2012 02:54:16 PM Pandu Poluan wrote: |
| 3 |
>> What I have in mind for "helper scripts" would be (for example) a |
| 4 |
>> script to ensure that, on boot, ethernet devices will maintain their |
| 5 |
>> relative order. This needs to be stuck into /etc/mdev.conf (already |
| 6 |
>> part of stage3). |
| 7 |
>> |
| 8 |
>> (And if someone's well-versed enough in Linux, maybe he/she will |
| 9 |
>> convert the shellscript into a simple -- and faster -- binary with |
| 10 |
>> exact same functionality). |
| 11 |
> |
| 12 |
> I think you are talking about a script that handles a more "dynamic" database |
| 13 |
> to force renames/softlinks for devices keeping names identical? |
| 14 |
> I haven't played with mdev yet, but isn't that already in mdev? |
| 15 |
> Or does mdev require it to be set manually? |
| 16 |
> |
| 17 |
|
| 18 |
Well, to make mdev simple enough for embedded devices (whose devices |
| 19 |
always come up in the same order), busybox devs do not include any |
| 20 |
database of devices. |
| 21 |
|
| 22 |
However, mdev is perfectly able to execute a program (script or |
| 23 |
binary) when it detects a device coming up, and it can choose which |
| 24 |
program to execute based on the device name. |
| 25 |
|
| 26 |
Let's say you have two NICs, one will get eth0, the other will get |
| 27 |
eth1, depending on the order that the kernel initializes the device |
| 28 |
name. For that, you don't have to do a thing. |
| 29 |
|
| 30 |
However, if the devices somehow gets initialized at the same time |
| 31 |
(e.g., hotplug events), it's a toss which dev will get which name. |
| 32 |
|
| 33 |
That is why, the busybox devs recommended the "linuxrc" file to |
| 34 |
contain the line "mdev -s", which will handle dev initializations |
| 35 |
during boot in a sequential fashion, ensuring exact same device names. |
| 36 |
|
| 37 |
> Btw, the "keep same devicename" is rather annoying when having to replace the |
| 38 |
> network card and the network then doesn't come back up... |
| 39 |
> |
| 40 |
|
| 41 |
There are several scenarios: |
| 42 |
|
| 43 |
Scenario 1: eth1 is replaced, eth0 stays -- if the new card is |
| 44 |
initialized after eth0, it will automatically assume eth1. If the new |
| 45 |
card is initialized before eth0, it will become the new eth0, and the |
| 46 |
previous eth0 will become eth1 automatically. |
| 47 |
|
| 48 |
Scenario 2: eth0 is replaced, eth1 stays -- if the new card is |
| 49 |
initialized before eth1, it will automatically assume eth0. If the new |
| 50 |
card is initialized after eth1, the previous eth1 gets eth0, while the |
| 51 |
new card gets eth1. |
| 52 |
|
| 53 |
The program (script) I'm planning will have a simple 'database' |
| 54 |
(actually, a text file) containing pairs of MAC address and devname. |
| 55 |
This should ensure that devices with a certain MAC address will |
| 56 |
*always* get the same devname, while devices not listed in the |
| 57 |
database will get the first available devname. |
| 58 |
|
| 59 |
Thus, in the case where devname swapping would happen (see the second |
| 60 |
situation in Scenarios 1 & 2), *at least* the non-replaced device will |
| 61 |
get the exact devname as before replacement happens. |
| 62 |
|
| 63 |
Rgds, |
| 64 |
-- |
| 65 |
FdS Pandu E Poluan |
| 66 |
~ IT Optimizer ~ |
| 67 |
|
| 68 |
• LOPSA Member #15248 |
| 69 |
• Blog : http://pepoluan.tumblr.com |
| 70 |
• Linked-In : http://id.linkedin.com/in/pepoluan |
Archives