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 8:12 PM
> 
> > 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'.

I'm not clear what you mean by this.


> We currently don't do much of anything with any new hotplugged network
> devices if they haven't been configured beforehand.

I think figuring out what to do in such cases is pretty important for
handling network hotplugging.  I understand that not every system
can autoconfigure all its network interfaces (certain servers require
static configuration just to let a network do a cold boot!), but
couldn't a lot of systems just use dynamic config (DHCP, PPP,
or whatever) on every network interface?


> > 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

So you think "ethernet" is special ... while I think that's
normal, and the other interfaces are funky!  In the 2.5
kernels it might be good to make all network interfaces
fit into a common initialization model.


> 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.

Likely that's the best solution for now.


> > 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.

I think you proved my point about long-standing behavior ... :-)
It doesn't make any sense to me to say "ifup" means anything
more than "make sure the interface is up".


> > 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.

This ties into the discussions about stable schemes for
device naming.  Names assigned based on which device
got initialized first are by definition unstable.  Ones assigned
based on system "topology" (say, PCI slot/function) will
by definition be pretty stable.  Unfortunately, distros seem
to be set up to rely on unstable naming schemes.  (Which
SCSI controller gets initted first, ...)


> 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)...

I think the plan of record for 2.4 is to make hotplug handle cardbus
and pcmcia_cs/cardmgr handle pcmcia.  If anyone thinks it's
something else, please speak up!


> > 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?)

If the fb modules are hotpluggable, then /sbin/hotplug would
most certainly be hotplugging them!

I'll put in a blacklist mechanism, unless someone suggests
a better solution to the "multiple drivers for device" problem.

Eventually, I think something like XML databases for all
the device and driver config data would be a good idea.
More extensible than the "modules.*" syntax, easier to
document and validate, and flexible enough to handle a
variety of applications and be self-documenting.

- 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