From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Mon, 26 Feb 2001 03:40:28 +0000 Subject: Re: OT(?) -- Should the net.agent script cause "ifup lo" to be run? Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org > From: "Bill Nottingham" > Sent: Sunday, February 25, 2001 4:38 PM > > David Brownell (david-b@pacbell.net) said: > > I guess I don't see what you mean by "actual hotplug device". > > What PCI or USB device wouldn't be a hotplug device, why? > > Any PCI device in an non-hotplug slot is not really hot-pluggable > (at least without risk to the card and motherboard. ;) ) So this is only an issue with PCI devices ... and maybe mostly PCI networking devices. Is there some reason why there should be a second config scheme, other than the fact that the previous sysadmin framework wasn't really hotplugging? Shouldn't there (eventually) just be one config system used by both "hot" and "cold" plugged PCI devices? > > What "drastic change"? > > In all our previous OS releases, interfaces are not necessarily > brought up just because the module is loaded; this changes that. > For example, we have documented behavior on how to mark interfaces > not to be brought up at boot time; hotplug now breaks these assumptions. You could submit a patch against the network hotplug agent to teach it how to use that information, if it's present. > Also, to maintain stable network interface ordering (with the current > kernel semantics), we load all the network modules once at boot so > all the device -> ethX mappings remain consistent; now hotplug tries > to activate all these interfaces. That can't work when devices are really getting "hot" plugged, right? No way you're going to know what kind of network interface I'll be hotplugging next ... but you're expecting to know them all in advance. Do you try to do anything like popping up a configuration GUI when a user adds a new and previously never-seen network interface? Or have a mode where all interfaces (say, LAN ones) act as DHCP clients rather than needing interface-at-a-time setup? (The former would surprise me right now, but not the latter.) > We've also noticed that (presumably > because of the PCI hotplug stuff), if you bring down an interface and > try and unload a module, it comes back. (This last one may be currently > fixed; it was reported against our last beta.) I'm not sure what would cause that. Network interfaces going down should be ignored in the current hotplug scripts. > > That patch to not make the ppp/isdn/... interfaces go "ifup" is > > in CVS, by the way. > > Cool. You probably want to add plip to the list if it's not > already on it. :) You left it out of your patch. Next putback I do will have "plip" and "lo". How can we know that we've got all of those interface types that require funky "ifup" handling? > > Am I correct that the issue is that those > > devices get brought "up" differently than eth* interfaces? > > Very differently. In fact, for PPP, by the time the device > exists in the kernel, you pretty much have to have already > run 'ifup' in some manner, unless you're not using any > networking scripts as all. So it really IS a bug in "ifup": it's not recognizing when those interface is up (and then doing nothing). That bug may be so long-standing that it's now called a "feature" though (as in, "can't ever fix that"). > > And "lo" has yet a third kind of init model magic? > > Not really, it's just brought up automatically here > when the network is started. It's certainly something > the hotplug scripts could do in the future; it's just > that it's not really a pluggable interface. Sure sounds like a third interface init model to me! A category that likely has just one member; IPv4 has the (class A) loopback network built in. > I was probably overly harsh in my assessment; it's not that > the scripts are buggy (aside from the ppp thing); it's that > in the current state what they do conflicts with how the > distribution used to work before. It's almost as if we were doing beta testing of the system integration, right now ... ;-) > It would be good to be > able to configure it so that it can mesh better (for example, > handle USB and cardbus, but ignore other PCI stuff.) Suggestions? Patches? Remember that Hotplugging is a PCI-wide feature ... it's not specific to Cardbus, cPCI, Hotplug-PCI, or so forth. This relates to my question above about whether there really _should_ be a second config mechanism for various random PCI devices. For the next OS distros, I'd expect distros to say "yes", but longer term ... I think all distros and end users would likely benefit from a different answer. > One other minor note; it currently didn't seem to handle > multiple modules that support the same device as well, in > that I couldn't tell it to load tulip instead of xircom_tulip_cb, > without editing the modules.pcimap directly. Not sure where > you'd put 'preferences' like this though. (Please, correct > me if I'm wrong.) Yes, there's an issue there. Same issue with "uhci" and "usb-uhci". (Why does tulip have that issue? How many such "duplicate drivers" are there?) I could imagine an /etc/hotplug/pci.blacklist file, used to prevent hotplugging from using a particular driver. Maybe it shouldn't be a PCI-specific file. - 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