Re: hotplug and ifup
On Sun, Feb 23, 2003 at 02:08:17AM +1000, Anthony Towns wrote:
Ok there are two problems:
1) Hotplug is called when existing devices are discovered but the kernel
when a module is loaded and also when new devices are discovered by
existing drivers... but hotplug can't tell the difference and act
accordingly.
So we should get the kernel to tell hotplug how the device was discovered.
2) S20modutils S36discover S39ifupdown all end up trying to configure
the network... yet S39ifupdown is where it should be done.
But maybe we are coming at this the wrong way.
If hotplug is _the_ way of the future, then perhaps our thinking about
how Debian does the configuration needs to change.
Perhaps we should have:
S20ifupdown-prepare
which sets up ifstate etc and gets the
network infrastructure in place.
move S20modules to S21modules
to make sure it happens after
S20ifupdown-prepare
S39ifupdown
can then make sure the "auto" interfaces are up, but
doesn't need to do any of the ifstate clearing.
This way things "just happen" which is what the majority of users
want... but you can also have better control if you choose (for example
I don't use discover - it keeps finding extra drivers for things that
make my box unstable. And I can't be bothered to work out how to
blacklist those things, and I prefer to be specific about what modules I
load.)
--
Paul
> Unfortunately, being the work of underbeings from Hell, hotplug isn't
> quite this simple: in fact, it will tell userspace about every interface
> that suddenly appears, whether it was physically added to the machine,
> or has always been there. Which means that whenever you do:
>
> # modprobe netdriver
>
> the kernel will helpfully run `ifup ethX' for you behind the scenes.
>
> This is annoying in and of itself -- you might not want this to
> come up at all, you might just want to do some anonymous snooping or
> something (see Bug#172671, eg) and if you're modprobe is a pre-up in
> your /etc/network/interfaces you've got an irritating race condition
> (which shouldn't cause problems now ifupdown does locking, but is still
> obnoxious).
>
> But, while it's annoying, that's not a major problem. What is,
> is that "modprobe netdriver" will be invoked on your behalf by both
> /etc/rcS.d/S20modutils and /etc/rcS.d/S36discover, and possibly other
> things. hotplug will run ifup at this point, which is bad, because
> S39ifupdown clears ifup's statefile, causing all sorts of confusion
> (see Bug#141399, eg).
>
> In essence, the question is, given:
>
> a PCI network card is installed
> the driver for that card is compiled in as a module
> hotplug is installed
> its module is listed in /etc/modules or discover is installed
>
> what should happen, and how should it happen? Should:
>
> * it behave as if the driver was compiled in directly (not as a
> module) -- ie, hotplug not called at all; it only gets enabled
> automatically if /etc/network/interfaces has an "auto" line
> for it ?
>
> * it get hotplug'ed just like dynamic cards, but in a way that
> doesn't break ?
>
> * hotplug not be called by the kernel for devices that were
> already attached when the module was loaded ?
>
> * something else ?
>
> If hotplug's not going to get called for it, how do we arrange it? Can
> we set /proc/sys/kernel/hotplug to /bin/true until we've finished booting?
> Or is there some way to special case modprobe so that hotplug doesn't get
> called for the modules you're loading? Or is something else possible?
>
> If hotplug _is_ going to get called for it, it'll have to be delayed
> somehow, at least until /etc/network/ifstate is writable. How can we
> do that?
>
> Cheers,
> aj
>
> --
> Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
> I don't speak for anyone save myself. GPG signed mail preferred.
>
> ``Dear Anthony Towns: [...] Congratulations --
> you are now certified as a Red Hat Certified Engineer!''
Reply to: