From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Thu, 18 Jan 2001 17:04:16 +0000 Subject: Re: netdevice problem Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org > 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. > There are several ways of doing this, most notably: >=20 > a) Buffer the results of the bootup PCI scan and > spit out hotplug events after filesystems have > been mounted, etc. >=20 > b) Scan the buses from initscripts, synthesise hotplug > events from userspace. >=20 > Both approaches are broken, because we'll end up > running /sbin/hotplug N 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?) > 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! > 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? > 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. > 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,=20 > '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=3Dlinux-hotplug-devel&m=97906053523984&w=3D2 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. > 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. >=20 > 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 Linux-hotplug-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel