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

[David Brownell <david-b@pacbell.net>]

> From: "Bill Nottingham" <notting@redhat.com>
> 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