From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bill Nottingham Date: Mon, 26 Feb 2001 04:12:07 +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 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. In the existing scheme, yes. > 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? Presumably, yes. Basically, the best way to do this, now that I think about it, is to extend the current 'not on boot' semantics to mean not on 'module load/insertion'. > > 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? Correct. But it works fine for the non-hotplug cases. > 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 currently don't do much of anything with any new hotplugged network devices if they haven't been configured beforehand. > > 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. I'll poke at it some and see if I can reproduce it. > > > 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. Someone just noticed it over the weekend after the original patch was done; I don't think anyone here uses plip. > 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? It's not really that they require 'special' handling in ifup; it's more that they are special otherwise. Basically, you have the ethernet devices that does: device created -> various userland setup and you have the ppp, CIPE, plip, etc. devices that do: various userland setup -> device created Since the setup parts are in the ifup script, it doesn't make sense to call ifup for the latter type. I'm not sure if there's a better solution other than explicitly enumerating them, though. > 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"). Nope, it's a feature. ;) You re-run ifup manually to initiate a redial; but you don't want the system doing that automatically, it creates quite a loop. > > 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? Determining whether hardware is behind a cardbus bridge or not is pretty easily, I'll try and look at that. > Remember that Hotplugging is > a PCI-wide feature ... it's not specific to Cardbus, cPCI, > Hotplug-PCI, or so forth. Hotplug-architecture in the kernel, yes. Whether the actual hardware in the machine in question supports hotplugging is a different matter. :) > 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. Probably. The biggest question in the current framework I see is that (unless I missed it) there's no ordering guarantees; i.e., if you have multiple (regular PCI) network cards how does the hotplugging system determine order - just PCI bus order? This is good in that it's consistent, but bad if you want to try and force it to something else. There's also the cardbus->hotplug/pcmcia->cardmgr mess for the time being, but that's a whole different story (and a non-trivial one to clean up)... > > 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?) Conceivably, the de4x5 drivers and tulip could overlap, I don't think they do in the current tree. The ones that do: - usb-uhci and uhci - dmfe and tulip - eepro100 and (vendor supplied) e100 - tulip and xircom_tulip_cb (only in RH's tree ATM, I think) > 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. I can certainly see where people would put fb modules in there (does hotplug load those automatically?) Bill _______________________________________________ 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