From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthias Schwarzott Date: Tue, 13 Nov 2007 16:22:18 +0000 Subject: Fwd: udev suggestion (persistent-net) Message-Id: <200711131722.18917.zzam@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Hi list! This is a mail I received these days from Martin Vaeth. Matthias ---------- Forwared Mail ---------- The problem with net-persistent.rules is of course that there is trouble when mirroring a system or when e.g. in a server - typically accessible only over network - a network card has to be exchanged. This topic came up in de.comp.os.unix.misc and a suggestion was made which gave me an idea which - when properly elaborated - would work reliable (keeping essentially net-persistent.rules) but would simultaneously avoid the above difficulties for most systems. Actually there are two similar ideas which can even be combined: The first idea is to store in net-persistent.rules always one interface *less* than what is actually found. This works really reliable: The first "unknown" (i.e. not stored in net-persistent.rules) interface should simply get the smallest number not associated with any interface from net-persistent.rules. Of course, if a second "unknown" interface appears it must get a further number, and that further interface (and its number) is stored in net-persistent.rules. This way you get at the next booting *reliably* the same interface numbering, however, one interface less is needed in net-persistent.rules [Of course, the interface might be stored nevertheless as a comment, so that people can easily exchange the interfaces if they want; the point is that this information is not *needed*]. Hence, in many cases no net-persistent.rules would be necessary at all, although one still has reliable boot order if the situation changes. But the solution becomes even more powerful if combined with the following idea (which can also be used independently if you do not like the above one): Instead of storing the full MAC immediately store only a not-so-unique information like e.g. the used kernel module first: Only if further interfaces using the same kernel module appear, store the MAC of that *further* interfaces. Again, this works reliable at the next boot (the first "unknown" interface is supposed to be the one which had appeared first at the last boot and gets the corresponding name). [As for the other idea, the full MAC might be stored nevertheless as a comment so that people can easily exchange if they want] Combining both ideas, most setups will require no persistent-net.rules, and people using typical setups like e.g. if there is only one ethernet card and e.g. the ieee ethernet interface could easily modify their persistent-net.rules so that it will still work reliable even if they exchange the ethernet card (they just have to make sure that they store *only* the ieee module name and its number in net-persistent.rules). People using two ethernet cards using different modules could at least exchange one of these ethernet cards and the other one against at card using the same module without any problem etc. So, roughly speaking, in many cases, one could write rules which run on more than just one setup which avoids many problems (e.g. also for mirroring setups for a computer park of similar systems). And the boot order remains reliable even if the hardware completely changes, because net-persistent.rules will then still be extended... I would be really glad if udev would be heading into such a direction. Please feel free to forward this posting also upstream (I do not know who is most open to such a suggestion). Regards Martin -- Matthias Schwarzott (zzam) ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel