Package: ifupdown
Version: 0.6.4-4.12exp3
Currently, ifupdown completly ignore everyting related to
hotplug. The end result is that people wanting to use hotplug to
configure network interfaces have to go through all kind of hoops and
the whole system is IMHO clunky.
As removable network interfaces are becomming more common
(Pcmcia, Cardbus, USB...), this is a growing issue.
So, I propose that ifupdown embrace Hotplug and makes it a
first class citizen.
If the ifupdown maintainers are opposed to this prospect, the
alternative is for them to propose a mechanism to deal with removable
interfaces. I personally would not want to go down this path...
1) First part : configuration
-------------
ifupdown should have some configuration syntax defining what
to do about hotplug interfaces.
Currently it doesn't, which lead the Hotplug package to add
configuration about it : "all", "auto" and "hotplug". As Thomas
pointed out, none of these options are really usefull, because they
are too coarse, and this is confusing, because users don't know which
one they should pick. Also, the option that might make most sense,
"noauto", is not provided.
For me, the big issue is that this configuration is done
outside /e/n/i, and I believe all network configuration should be done
in one place.
The current preferred option is to set Hotplug in mode
"hotplug" and to use some mapping to select which interface should be
enabled. This would look like :
-------------------------
mapping hotplug
script grep
map eth3 eth5
-------------------------
The first issue is that such mapping magic is not provided as
standard in the package /e/n/i, and not really documented, so unless
people read through bug report or weird page on the web, they won't
know it exist, and won't be able to use it.
The second issue is that it's too complex for the average
user, look too much like black magic, so he won't understand what it
does and how to debug it in case of problems. Moreover, if the user
want to use mapping for those interfaces (like ifscheme), he is going
to get confused.
Proposal :
Add a "hotplug" keyword to /e/n/i that has the exact same
syntax as the keyword "auto". The "hotplug" keyword defines interfaces
that should be configured via Hotplug, all interfaces that don't have
this keyword are ignored when called via hotplug (it does the
equivalent of the mapping above behind the curtain).
The resulting configuration would look very neat and user
friendly :
-------------------------
# Ethernet PCI to infrastructure
auto eth4
iface eth4 inet dhcp
# USBNET peer to peer to other PC
hotplug usb0
iface usb0 inet static
address 10.0.0.2
network 10.0.0.0
netmask 255.255.255.0
broadcast 10.0.0.255
-------------------------
2) Second part : invocation
--------------
ifupdown should define the way it wants to be called from the
hotplug scripts. The advantage is that ifupdown could modify its
behaviour to make things work properly with Hotplug and optimise
further later.
Here is a way ifupdown *could* modify its behaviour.
If ifupdown were to include interface renaming, the difference
between a normal invocation and a hotplug invocation is that normal
invocation specify the name as the user want to see it, after renaming
(i.e. ifrename -n ethX), whereas hotplug specifies the name before
renaming (i.e. ifrename -i ethX).
Another difference in behaviour *could* be locking of
/e/n/ifstate. In normal invocation, ifupdown would wait for the lock,
whereas for hotplug invocation it would just exits if the log is
taken to avoid deadlock.
Currently, the hotplug scripts may add a logical interface
name "hotplug" when calling ifup, but not always (depend on hotplug
config). When using the "all" and "auto" mode, ifupdown has no way to know
Adding a logical interface is ok, but not great. I believe
logical interfaces where not really intended for this, and it involves
string manipulations. I personally would prefer a command line
argument, which is simple and explicit.
So, we could define the Hotplug invocation as follows :
exec /sbin/ifup --hotplug $INTERFACE
Waiting for your comments...
Have fun...
Jean
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
