netdevice problem
As far as I know, the "vision" is that the hotplug architecture can be used at boot time. We identify all the ISA/PCI/whatever devices and create hotplug insertion events for them, and just let the hotplug magic happen.
There are several ways of doing this, most notably:
a) Buffer the results of the bootup PCI scan and
spit out hotplug events after filesystems have
been mounted, etc.
b) Scan the buses from initscripts, synthesise hotplug events from userspace.
Both approaches are broken, because we'll end up running /sbin/hotplug N times concurrently. The assignment of eth0, eth1, eth2, etc will be totally random and people will hate us.
The fixes appear to be:
1: Funky hard-wired delay in the hotplug synthesiser. (cs89x0
will require five seconds, please...)
2: Funky userland locking which blocks each hotplug synthesis
until the previous one has completed its `ifconfig up', if it indeed did it. This is crap.
3: Stick with modutils.conf to drive the bootup process,
switch to hotplug scripts for post-boot insert/remove. This is a sad mix.
4: Rework call_usermodehelper for synchronous (or completion
callback) semantics. So the pci layer's callout doesn't return until both 'hotplug pci' and its child, 'hotplug net' have terminated.
Option 4 is of course the patch-which-didn't-make-it. I haven't resubmitted because the jury is still out on whether it's still needed. If the current setup can be reasonably used from userspace then let's not hassle Linus.
But I now feel it's needed. Any clever ideas out there?
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
At boot time, you should run something like this (this is hand written because I do not want to wade through the other cruft currently in our boot scripts):
# We include "off" in the list to avoid a shell syntax error # in case the other modules turn out to be an empty list. modprobe -s -k isa-pnp
for module in off $(isapnpmodules) $(pcimodules) ; do
modprobe -s -k $module
done
( modprobe i82365 || modprobe tcic ) && cardmgr -o
# The isapnpmodules and pcimodules loop must be run before # parportmodules is evaluated because they may load parallel # port controllers. Perhaps this is also true of PCMCIA. for module in off $(parportmodules) ; do
modprobe -s -k $module
done
# USB initialization occurs as a result of USB host controllers # being loaded (usually from pcimodules), and the host controller # modules generating hot plug events for the devices that are # already attached. Other devices
# This is all synchronous becuase, in the kernel, while # usermode_helper is not synchronous, request_module is. # So, we always load the modules in the same order at each # boot (given the same hardware).
# We did the initialization in order of least likely to do hot # plugging to most likely in order to reduce the likelihood of # gaps in device numbering as devices are added and removed # (basically as a user interface issue, not for any other reason).
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104 [email protected] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines
As far as I know, the "vision" is that the hotplug architecture can be used at boot time. We identify all the ISA/PCI/whatever devices and create hotplug insertion events for them, and just let the hotplug magic happen.
Nobody's presented reasons why that shouldn't be the case. I can wonder about the risks of duplicated events, but we don't have that problem yet ... and hotplug event handlers need to handle such cases.
Quoted 11 lines
There are several ways of doing this, most notably:
a) Buffer the results of the bootup PCI scan and
spit out hotplug events after filesystems have
been mounted, etc.b) Scan the buses from initscripts, synthesise hotplug events from userspace.
Both approaches are broken, because we'll end up
running/sbin/hotplugN times concurrently.
I'm not sure I see why (b) should have that flaw, but queuing up hotplug notifications in the kernel might well have problem (a) unless there's a throttling mechanism like permitting only one /sbin/hotplug call at a time.
I've been assuming (b) in any case, but will not have time soon to write an /etc/hotplug/pci.rc script to do that. (Volunteers?)
Quoted 3 lines
The
assignment of eth0, eth1, eth2, etc will be totally random and people will hate us.
If the kernel device scanning order is defined, then it can be followed in userland. If the kernel doesn't define that order ... people should hate the kernel instead!
Quoted 1 line
The fixes appear to be:
You mean fixes to the "everything collides" problem, yes? The one I've seen to completely wedge a Linux box, so that I'm very glad to have SysRq enabled?
Quoted 10 lines
1: Funky hard-wired delay in the hotplug synthesiser. (cs89x0
will require five seconds, please...)2: Funky userland locking which blocks each hotplug synthesis
until the previous one has completed its `ifconfig up', if it indeed did it. This is crap.3: Stick with modutils.conf to drive the bootup process,
switch to hotplug scripts for post-boot insert/remove. This is a sad mix.
All of those seem like we'd be better without them. Usermode workarounds, not real fixes.
Quoted 4 lines
4: Rework
call_usermodehelperfor synchronous (or completion
callback) semantics. So the pci layer's callout doesn't return until both 'hotplug pci' and its child, 'hotplug net' have terminated.
Or the USB layer's ... this closely relates to one of the remaining issues on my own "Hotplug TTD" list (async change issues)
http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m—906053523984&w=2
and curiously enough, other than integrating Keith's usb_device_id patch and writing code to emulate hotplug for boot time events, this seems like one of the main remaining issues.
Quoted 6 lines
Option 4 is of course the patch-which-didn't-make-it. I haven't resubmitted because the jury is still out on whether it's still needed. If the current setup can be reasonably used from userspace then let's not hassle Linus.
But I now feel it's needed. Any clever ideas out there?
I've liked it too, and it's been on my list (see above :-). Having given up on chasing a driver problem for a while, I'll get back to this one soon.
Perhaps you should post your patch to this list, so that more folk can see it and evaluate your option 4? Or even help out with the testing/development. It seems to me this is the main unresolved "hotplug infrastructure" problem just now; most of the other stuff should be ready to go, given Keith's patch.
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel