> also sprach Thomas Hood <[EMAIL PROTECTED]> [2005.02.17.2125 +0100]: > > > also sprach Thomas Hood <[EMAIL PROTECTED]> [2005.02.17.2111 +0100]: > > > > * hotplug should run ifrename and call ifplugd.hotplug and > > > > waproamd.hotplug with INTERFACE set to the new name > > > > or else > > > > * ifplugd.hotplug and waproamd.hotplug should each call ifrename > > > > for the interface named in INTERFACE and then should start > > > > ifplugd/waproamd with the new interface name. > > > > > > Clearly, then, the first should be favoured. > > > > Why do you favor the first over the second? > > Sorry, should be more explicit. I favour the first over the second > because it handles interface renaming at the same location as udev > does (approximately). Then ifplugd, waproamd, foobar, and xyz do not > ever need to worry about it. If ifrename's syntax changes, only > hotplug needs to be changed.
The first option may have advantages but Md does not seem to favor it. On Feb 16, I wrote: > How to solve the problem? Running ifrename from /sbin/hotplug > instead of from net.agent works for me. and Md replied: > This will not happen, hotplug-ng uses a C program and anyway on udev > systems udevsend will be used as the hotplug multiplexer. > OTOH, when udevsend is used then udev should be able to rename the > interfaces before other hotplug scripts are run. (It is possible that Md's views have changed since he wrote this, of course. This is cc:ed to him so he can tell us what he thinks now.) There is another option, actually (call it 'option #3') which is for ifrename to wrap /sbin/hotplug with a script that runs ifrename, changes INTERFACE and execs the original /sbin/hotplug. * Divert /sbin/hotplug to /sbin/hotplug.hotplug * Include /sbin/hotplug which ifrenames and execs /sbin/hotplug.hotplug This should work both with hotplug and with the future hotplug-ng. This wouldn't handle the case where the future udev is installed that does: echo /sbin/udevsend > /proc/sys/kernel/hotplug If we want ifrename to work with that future udev then /sbin/udevsend will have to be wrapped in a similar way (... if we adopt option #3). -- Thomas Hood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
