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

If such a flag is set, don't automatically bring up the interface
when the hotplug event occurs.

It would be nice to be able to determine whether an interface
is created because someone manually loaded the module or whether
kmod loaded it, but I'm not sure how that would be instrumented.

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

Um, ppp is not a dynamic configuration.

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

No, it's just two different methods.

> In the 2.5
> kernels it might be good to make all network interfaces
> fit into a common initialization model.

I think you're fundamentally misunderstanding how PPP works; for
the general modem case, you set up the serial port, dial out, make
a connection, and *then* start the PPP negotiation. At this point,
pppd is running, and it does all the parts that set IP addresses.
In short, there really is *nothing* for hotplug to do with this
interface.

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

It's a documented feature on how to intiate a redial. I'm not
sure there's anything else I can say, but it isn't going to change
for our next release.

> Unfortunately, distros seem
> to be set up to rely on unstable naming schemes.  (Which
> SCSI controller gets initted first, ...)

Well, with ethernet devices you really don't have a choice.

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

That's rather ugly (cardmgr will still print messages for everything
that's inserted), inconsistent in UI (cardmgr beeps, etc., hotplug
doesn't), and just generally odd from an end-user's perspective
(You see, if you plug *that* card into the slot, you need cardmgr
running; if you plug that other card in, you need hotplug.)

It's actually not too hard to make cardmgr work fine with 2.4.

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

They aren't exactly hotpluggable though (they pretty much all
are unremovable.)  Also, when they fail, they tend to fail
pretty spectacularly, but that's not really hotplug's concern.

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

However, the modules.<foo>map are updated automatically
when a kernel introduces new drivers, support for new IDs,
etc. This is a great benefit. Also, shoving an XML parser
onto the root partition might be more than most people want...

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