From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Knecht Date: Thu, 18 Jan 2001 18:03:18 +0000 Subject: RE: netdevice problem - 1394 SPB-2 Drives Message-Id: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org Hi, I'm a total 'lurker' here, but am involved on the hardware side with the work going on with Linux-1394 support.=20 How do you guys seeing 1394 disk drives fitting into the hot-plug mix? The performance is much higher than USB, similar maybe to SCSI, but as of right now I do not believe that it will be possible to boot from a 1394 drive, so the file system problems may not be a bad as SCSI. We do have the beginnings of drive support there. Folks are starting to use 1394 hard disks, as well as CDs and DVDs. Mark -----Original Message----- From: David Brownell [mailto:david-b@pacbell.net] Sent: Thursday, January 18, 2001 9:04 AM To: Andrew Morton; linux-hotplug-devel@lists.sourceforge.net Subject: Re: 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. 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 _______________________________________________ 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