+built-in interfaces, the main difference is that we will use Hotplug
+event with the uDev system instead of the init scripts. This requires
+a fairly recent distributions, older distributions don't have uDev or
+uDev system not capable enough.
+ Note that you can also use removable interfaces with the
+original Hotplug scripts. This is detailed in the next section. The
+installation of uDev changes a lot of things on a system, so may not
+be for everybody, however recent version of Gnome and KDE seem to
+require it.
+
+ 1) Applicability
+ ----------------
+ The Hotplug configuration method is the best choice for any
+removable network interface, such as :
+ o Pcmcia (16 bits) network cards
+ o CardBus (32 bits) network cards
+ o USB network dongles
+ o Hot-PCI network cards
+ It may also be used to manage other types of network
+interfaces, although it may not be the best choice for them.
+
+ 2) How Hotplug works with the uDev scripts
+ ------------------------------------------
+ When using uDev, the concept is similar to the original
+Hotplug scripts, however the implementation is slightly less
+transparent. Also, the name of the rules and the location of scripts
+vary from distribution from distribution.
+
+ When something interesting happens, the Linux kernel generates
+an Hotplug event. The uDev deamon (udevd) receive the event, does some
+processing on its own, use the rules in /etc/udev/rules.d/, and
+finally run the proper script in /lib/udev/.
+ There are 3 types of Hotplug events we care about :
+ o PCI event : a CardBus device is added or removed
+from the system. The hotplug rule loads the driver, in my case
+/etc/udev/rules.d/z55_hotplug.rules.
+ o USB event : a USB device is added or removed from
+the system. The hotplug rule loads the driver, in my case
+/etc/udev/rules.d/z55_hotplug.rules.
+ o Network event : a network interface is added or
+removed from the system. The script /lib/udev/net.agent is run.
+
+ If we insert a CardBus network card in the system, the
+following happens :
+ 1) Kernel detects new CardBus device
+ 2) Kernel generates PCI Hotplug event
+ 3) udevd receive the event, runs the Hotplug rule.
+ 4) The Hotplug rule find the proper driver module and loads it.
+ 5) Driver module initialises, creates new network device
+ 6) Kernel detects new network device
+ 7) Kernel generates Network Hotplug event
+ 8) /lib/udev/net.agent runs, configures network device
+ The sequence of events is similar for USB devices and for removals.
+
+ 3) Installing uDev for Debian Lenny
+ -----------------------------------
+ Thanks to the great work of many people, Debian Lenny has all
+the necessary packages and complete udev support, and will work mostly
+'out of the box'.
+ You will need to install the following packages :
+ o udev
+ o ifrename
+
+ The configuration of Hotplug and uDev is simple. You only have
+to modify the file /etc/network/interfaces to enable your interfaces
+to be managed with Hotplug and uDev.
+ By default, ifup ignore all hotplug network events, as it
+assume network interfaces are configured using the static init
+scripts. To enable ifup to configure specific network interfaces on
+hotplug events, you need to list those interface in a "allow-hotplug"
+statement.
+ For example, your /etc/network/interfaces would include :
+--------- /etc/network/interfaces -----------
+# Enable Hotplug support (Etch and later)
+#
+allow-hotplug prism0 acx0
+---------------------------------------------
+
+ 4) Installing uDev for Debian Etch (4.0)
+ ----------------------------------------
+ The uDev system provided with Debian Etch (4.0) is fully
+functional, except for one missing feature. This version of uDev can
+not integrate with ifrename. The version of ifrename provided also
+lacks uDev support.
+ If you want to use uDev with Debian Etch (4.0), there are two
+possibilities. The first solution is use the uDev system to rename
+interfaces, loosing some of the power of ifrename. The second solution
+is to upgrade both udevd and ifrename.
+
+ This is the procedure I personally use to upgrade udevd on
+Debian Etch (4.0) :
+ o Get the canonical version of udev 107 from :
+ http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
+ o Compile it with "make".
+ o Do not "make install" !
+ o Run "strip udevd"
+ o Save a copy of the original udevd "cp /sbin/udevd /sbin/udevd.orig"
+ o Copy the new udevd with "cp udevd /sbin/udevd".
+ Note that udevd is an essential component of the OS. This
+procedure should be safe, but I do not guarantee it will always be
+safe.
+
+ Upgrading ifrename is simple, this is like installing ifrename
+and is described above in this document.
+
+ Once those two packages are upgraded, you can go follow the
+procedure going back to step (3).
+
+ 5) Installing uDev for Debian Sarge (3.1)
+ -----------------------------------------
+ The uDev system provided with Debian Sarge (3.1) is a very old
+version of uDev that is not integrated with the Hotplug scripts. In
+other words, if you install uDev with Sarge, you will still need to
+use the original Hotplug scripts and configure your system with them.
+
+ 6) Installing uDev on other distributions
+ --------------------------------------------
+ The canonical version of hotplug is available at :
+ http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
+ The mailing list for udev is the Hotplug mailins list :
+ http://linux-hotplug.sourceforge.net/
+ http://marc.theaimsgroup.com/?l=linux-hotplug-devel&r=1&w=2
+
+ Most distributions have highly customized uDev packages and
+most likely the canonical version won't completely work on your
+system. The udevd deamon is has usually little changes, however the
+rules and scripts are very different.
+ To be able to use uDev with ifrename, you will need uDev
+version 107 and later, which has support for calling ifrename. You
+will also need ifrename version 29.pre17 or later (I recommend version
+29). Most modern distributions should already have those versions.
+ If this is the case, you only need to install the uDev and
+ifrename package. If there is no ifrename package, it's easy to
+compile it from source and install it.
+
+ 7) Making uDev call ifrename
+ ----------------------------
+ We need to make sure that 'ifrename' is run by the uDev
+subsystem at the right time. Because of the complex way uDev works,
+the smooth integration can only be done one way. Other methods may
+leave the uDev system in a confused state, which may be a problem when
+the card/interface is removed.
+
+ Most often, the only thing to do it to copy the file
+'19-udev-ifrename.rules' from the Wireless Tools package to the
+directory "/etc/udev/rules.d/". It should work on most system.
+
+ What follow is a detailed explanation of what this additional
+rules does.
+ uDev needs to call ifrename as an IMPORT rule, and with the
+right parameter. As I said, this requires uDev version 107 and later
+and ifrename version 29.pre17 or later.
+ The ifrename rule need to be called *before* the 'persistent'
+rules. I also like the ifrename rule to happen after local rules. The
+uDev rules are processed in alphabetical orders, which is why the
+rules filename start usually with numbers. However, those name vary
+betwen distributions. Make sure the ifrename rule has a proper
+filename for your distribution.
+
+ The rules we add looks like this :
+------ /etc/udev/rules.d/19-udev-ifrename.rules ------
+# Main ifrename rule.
+# If interface is found in /etc/iftab, subsequent rename rules are bypassed.
+# If interface is not found in /etc/iftab, subsequent rename rules applies.
+SUBSYSTEM=="net", ACTION=="add", IMPORT="/sbin/ifrename -u -i %k", NAME:="%k"
+------------------------------------------------------
+
+ Lastly, make sure the rule has the right path for ifrename :
+--------------------------
+> which ifrename
+/sbin/ifrename
+--------------------------
+
+ 8) Loading driver modules
+ -------------------------
+ Wow ! The most difficult part is done.
+ In theory, you don't need to do any specific configuration for
+the driver modules to be loaded. The uDev system should load the right
+driver module for you.
+ Also, you don't need to define aliases in /etc/modprobe.d/* or
+in /etc/modprobe.conf, it's useless and may be counterproductive.
+
+ If you use a driver compiled statically in the kernel, you
+also have nothing to do.
+
+ 9) Renaming interfaces
+ -----------------------
+ We still use ifrename to assign names to interfaces. The
+configuration of 'ifrename' is the same. To keep the possibility of
+having multiple wireless cards (one in each CardBus slot), we use
+wildcards in both the MAC address and the name :
+
+--------- /etc/iftab -----------------------
+# SMC 2835W wireless CardBus card
+prism* mac 00:30:B4:*
+---------------------------------------------
+
+ If you insert two cards, they would be named prism0 and
+prism1. If you want to control which card get each name, you should
+not use wildcards and set a specific line for each card :
+
+--------- /etc/iftab -----------------------
+# SMC 2835W wireless CardBus card
+prism0 mac 00:30:B4:64:27:8B
+prism1 mac 00:30:B4:64:27:8D
+---------------------------------------------
+
+ 10) Configuring interfaces
+ --------------------------
+ At this point, configuration of uDev network interfaces is done
+just like their built-in counterparts. This part is still distribution
+specific, and still already documented in the file DISTRIBUTIONS.txt.
+
+ In Debian, you would need to modify the file
+/etc/network/interfaces like this :
+
+--------- /etc/network/interfaces -----------
+# Enable Hotplug support (Etch and later)
+#
+allow-hotplug prism0
+
+# SMC 2835W wireless CardBus card
+iface prism0 inet static
+ address 10.0.1.2
+ netmask 255.255.255.0
+ broadcast 10.0.1.255
+ wireless-essid THE_ESSID
+ wireless-mode ad-hoc
+ wireless-channel 5
+---------------------------------------------
+
+ Note that you can also use graphical tools such as
+NetworkManager to configure interfaces at this point.
+
+ Now, just cross your fingers and plug the card in the slot...
+ If it does not work, there is a troubleshooting section at the
+end of this document.
+
+
+CONFIGURATION VIA THE ORIGINAL HOTPLUG SCRIPTS
+----------------------------------------------
+ The previous section was dealing with removable interfaces
+with Hotplug events and the uDev system. In various cases, or for old
+distributions, it's preferable to use the original Hotplug
+scripts. The original Hotplug scripts are much less invasive on the
+system than uDev.
+ Using the original Hotplug scripts is similar to using uDev or
+dealing with built-in interfaces, the main difference is that the
+script used are different. Another difference is that it will likely
+require more work on your part because most distributions do not have
+all part properly integrated.