Re: OT(?) -- Should the net.agent script cause "ifup lo" to be run?

[Bill Nottingham <notting@redhat.com>]

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