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

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

[Miles Lane]

I am wondering how much of the work that is
currently handled by init scripts like
/etc/rc.d/init.d/network ought to migrate into
the hotplug scripts.  If the answer is "almost
none," then how should running of "ifup lo"
get triggered when "ifup ethN" is getting run
from /etc/hotplug/net.agent?  I ask because
I have been experimenting with relying more
on the /etc/rc.d/init/hotplug init script to
get my PCI, net and USB device drivers loaded
and the devices configured.  To this end, I
disabled /etc/rc.d/init/network.  The result
is that booting my system worked great, except
/dev/lo wasn't enabled.  For some reason, mozilla
doesn't finish initializing if /dev/lo isn't
activated.

I suppose this is all stuff that can get sorted
out later by distribution developers, but I
thought there might be some value in sorting out
as much of this boot process stuff as possible
during the hotplug development process.

I hope this isn't too far off topic.

	Miles


_______________________________________________
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

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

[Adam J. Richter]

Miles Lane <miles@megapathdsl.net> writes:
>I am wondering how much of the work that is
>currently handled by init scripts like
>/etc/rc.d/init.d/network ought to migrate into
>the hotplug scripts.  If the answer is "almost
>none," then how should running of "ifup lo"
>get triggered when "ifup ethN" is getting run
>from /etc/hotplug/net.agent?  I ask because
>I have been experimenting with relying more
>on the /etc/rc.d/init/hotplug init script to
>get my PCI, net and USB device drivers loaded
>and the devices configured.  To this end, I
>disabled /etc/rc.d/init/network.  The result
>is that booting my system worked great, except
>/dev/lo wasn't enabled.  For some reason, mozilla
>doesn't finish initializing if /dev/lo isn't
>activated.

	I would like to see systems in the future that are
much more usage driven than the ones of today.  For example,
I would like to see /etc/fstab handled by some future variant
of autofs (not sure if autofs4 would do be enough) and, on systems
that do not want to run inetd, I could image the ethernet
card being fully powered on and DHCP'ed or otherwise configured
only as a result of something on the system trying to send a packet
on the network (detected by a facility like diald, which you could
try if you want to go that extreme with the "lo" interface).
Likewise, getty and xdm would be spawned only as virtual consoles,
frame buffers, keyboards and mice were detected (per a policy controlled
by /etc/devfsd.conf).  Other things which are "configured" today
would adjust automatically to accomodate usage: sendmail, httpd,
mountd and nfsd would be spawned by inetd in response to requests
and these daemons would stick around to handle other requests in
case of high load, in the cases of sendmail and httpd, spawning
helper children up to some limit if required by the load, but they
would eventually exit after a few minutes of inactivity.

	On such a system, the boot process proper could be very fast.
If you wanted to boot your system to edit a few files on your root
IDE hard disk, it might never get around to spinning up your your
second SCSI hard disk or even loading the driver for the scsi
controller.  It might not even bother dhcp'ing your network
interface.

	On the other hand, you might want your system to configure
everything, at least in the background, just to reduce the pauses
the first time you were to use each device.  It would depend on how
much you cared about kernel footprint and power consumption.

	Just to illustrate, here is a rough example of the boot process
that I have in mind for a system in the future (parts of this are not
accurate today):

	mount /dev
	# FIXME: Will fsck or autofs need /proc to be manually mounted?

	# fsck is very fast, because future systems will 
	# run GFS or some other journaling or log based file system.

	rootdev=$(get_root_device)
	if ! fsck -p $rootdev ; then
		exec < /dev/console > /dev/console 2>&1
		echo "fsck of root device ($rootdev) failed!"
		if ! fsck -r $rootdev ; then
			echo "System will reboot when you exit this shell."
			sh
		fi
		echo "Rebooting."
		reboot
	fi
	autofs -fstab /etc/fstab
	devfsd /dev
	enable_hotplugging
	modprobe isa-pnp
	modprobe nubus
	modprobe sbus
	modprobe pci
	# Someday "pci" will be a separate module to make the standard
	# kernel binary's footprint smaller on older non-PCI machines,
	# and it might not be loaded by the initial ramdisk if the boot
	# device is on, say, the ISA bus.

	# Imagine that in the future we have nice consistent names
	# for busses:
	for slot in /proc/bus/*/[0-9]*/[0-9]* ; do
		hotplug $slot
		# The hotplug scripts will probably only call modprobe
		# for the devices that we actively want to "listen" to,
		# like removable media drives and interfaces to other
		# pluggable busses like USB, FireWire, SCSI, and IDE.
		# Probably everything else could be triggered by usage,
		# although you might want to preload them anyhow just
		# to avoid pauses the first time you access things.
		# Note that these "listener" kernel modules ought to
		# have some kind of facility to tell "modprobe -r" not
		# to automatically remove them even if they've been unused
		# for a while.
	done

	# The following two lines would actually be done by /etc/inittab
	# or some more exotic runlevel-based system:
	cron
	inetd

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

_______________________________________________
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

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

[Bill Nottingham]

Miles Lane (miles@megapathdsl.net) said: 
> the hotplug scripts.  If the answer is "almost
> none," then how should running of "ifup lo"
> get triggered when "ifup ethN" is getting run
> from /etc/hotplug/net.agent? 

I'd almost argue that the hotplug scripts should be
doing *less*.

The current feature of automatically bringing up any interface
on device creation removal is OK for *actual* hotplug interfaces,
but for other interfaces is:

a) a drastic change in behavior
b) annoying
c) seriously broken for non-hardware-tied interfaces (ppp/slip/plip)

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

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

[David Brownell]

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?
What "drastic change"?

That patch to not make the ppp/isdn/... interfaces go "ifup" is
in CVS, by the way.  Am I correct that the issue is that those
devices get brought "up" differently than eth* interfaces?
And "lo" has yet a third kind of init model magic?

- Dave

----- Original Message ----- 
From: "Bill Nottingham" <notting@redhat.com>
To: <linux-hotplug-devel@lists.sourceforge.net>
Sent: Sunday, February 25, 2001 1:37 PM
Subject: Re: OT(?) -- Should the net.agent script cause "ifup lo" to be run?


> Miles Lane (miles@megapathdsl.net) said: 
> > the hotplug scripts.  If the answer is "almost
> > none," then how should running of "ifup lo"
> > get triggered when "ifup ethN" is getting run
> > from /etc/hotplug/net.agent? 
> 
> I'd almost argue that the hotplug scripts should be
> doing *less*.
> 
> The current feature of automatically bringing up any interface
> on device creation removal is OK for *actual* hotplug interfaces,
> but for other interfaces is:
> 
> a) a drastic change in behavior
> b) annoying
> c) seriously broken for non-hardware-tied interfaces (ppp/slip/plip)
> 
> 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

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

[Bill Nottingham]

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

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

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

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

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

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

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

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

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

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

[David Brownell]

> 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

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

[Bill Nottingham]

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

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

[Bill Nottingham]

Bill Nottingham (notting@redhat.com) said: 
> 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)

There also will probably be two aic7xxx drivers in the tree
at some point in the future, if/when Justin Gibbs's driver
is accepted for inclusion.

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

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

[Miles Lane]

David Brownell wrote:

>> From: "Bill Nottingham" <notting@redhat.com>
>> Sent: Sunday, February 25, 2001 4:38 PM

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

Hi Bill and Co.,

In the early design phase of the hotplug system (it was 
USB-specific at the time, IIRC), David Brownell foresaw 
that we would reach a point were the folks involved in
developing distribution init scripts would get involved.
I am delighted to see that that day has arrived!  It's a
definite milestone.

At that time, David mentioned that a huge amount of the
work in improving and fine-tuning the hotplug system
would require the resources, effort and expertise of the
distribution vendor staff.  So, your input and contributions
are most welcome!

In order to ensure that we implement a solid, general system,
it would be wonderful if you would invite others at Redhat
and at the other distribution vendors, as well, to
participate in the hotplug development process on this
mailing list.

You mention some problems Redhat encountered in recent
rawhide testing.  It would be fantastic if you could help
ensure that any hotplug-related problems are reported to
this mailing list quickly, so we can work together on a
solution.  Since this is a big change to hotplugging and
since good hotplugging is one of the most significant
improvements we can make to improve user experience on
the desktop, it seems important that we get this all
ironed out rapidly.  This will obviously help Redhat and
all the other vendors deliver great 2.4-based Linux
releases more quickly.

Best wishes,

	Miles


_______________________________________________
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

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

[Miles Lane]

Bill Nottingham wrote:


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

Have you read Adam Richter's recent message to
linux-hotplug-devel (02/24/01 @ 8:25:02PM)?

This message is the result of a discussion that occured
in response to a message I posted containing a list
of requirements from David Hinds for migrating PCMCIA
support into the kernel tree.

As a short-term solution, recent cardmgr builds will
ignore all devices that occur in the modules.pcimap
on machines running a 2.4.x kernel.  This means that 
PCMCIA configuration should not step on the toes of 
devices that the new hotplug system supports.

I haven't seen any feedback to Adam's post, yet.  
Hopefully a substantive discussion will lead to an
agreed design.  

I'd like to see another discussion occur that explores
the implementation of PCMCIA support in the kernel
in light of Adam's recent mail.  It's my understanding
that the PCMCIA migration is all 2.5 work.  In the 
meantime, I think the hack in cardmgr is sufficient.
Agreed?

	Miles


_______________________________________________
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

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

[David Brownell]

> From: "Adam J. Richter" <adam@yggdrasil.com>
> Sent: Sunday, February 25, 2001 2:03 AM
> 
> I would like to see systems in the future that are
> much more usage driven than the ones of today.

Me too -- for all that it's a significant change in "user model"
from traditional UNIX.  Today, autoconfiguration is much
more important that it was way back when; and conserving
system power usage starts to be a lot more important.

> On such a system, the boot process proper could be very fast.

A very useful side effect!

> On the other hand, you might want your system to configure
> everything, at least in the background, just to reduce the pauses
> the first time you were to use each device.  It would depend on how
> much you cared about kernel footprint and power consumption.

Today, the hotplug scripts are set up to configure everything they
can, even for the "cold plugged" boot scenario, on the grounds
that we don't have code to support multiple operational policies
yet, and that's the most general single policy to adopt.  (Plus,
from having done this sort of thing before, I know that having
multiple such policies is confusing to pretty much everyone.)

I certainly agree that richer system models for autoconfiguration
will be needed.  Different kinds of systems should be able to have
different levels of autonomy ... as well as adopting different power
management policies.

- 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

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

[David Brownell]

> 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

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

[Bill Nottingham]

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

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

[David Brownell]

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

One thing I'm saying is that such things shouldn't matter.
Intent shouldn't be asked; reliable program systems
rarely have "if (CameFrom (...)) ..." logic.

What should get tested is something explicit, such as
the interface state:  is it already "up", is there a carrier,
does it even need a carrier, and so on.  I don't know
that all the right information is available ... unless you
apply heuristics based on device names.  (Such
heuristics seem to be the only solution for now.)


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

I think you're misunderstanding what I'm saying.  But since
network interface operation can't change for 2.4, and I
think that's what you're focussed on, I won't try to clarify.

- 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

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

[David Brownell]

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

Noise in /var/log/messages that will normally be ignored.
(If it's a problem, wouldn't it be a cardmgr problem?)


>    inconsistent in UI (cardmgr beeps, etc., hotplug
> doesn't), 

If there are only two possible devices, and you're in an
environment where the noise is OK, beeps are unlikely
to be annoying.  Even two at boot time.

Systems with a dozen USB devices are not uncommon;
I'd rather rely on hub LEDs for feedback than get lots of
noise on reboot, or when I plug in a hub that has a bunch
of devices already connected.

Though if you really think that CardBus hotplugging should
beep, that should be an easy patch ... cPCI evidently uses
blue lights in its feedback (doesn't Compaq's Hotplug PCI
use LEDs too?), so that shouldn't be a PCI-wide policy.


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

"Have both these installed and any supported card will work"
doesn't seem odd!  Quite the opposite.


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

Never said it was.  The question is how to handle cardbus
support, given that pcmcia_cs (with cardmgr) is oriented
towards pcmcia while the overall Linux direction seems to
be to towards a more general framework for pci hotplug.

- 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

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

[David Brownell]

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

Sure, but what about all the OTHER metadata that's not
in the *map files?  The *map files are a great feature, for
exactly the reason you identified, but I don't think that
should be the end of the road.  They don't say which of
the drivers are experimental, or provide driver docs.


>     Also, shoving an XML parser
> onto the root partition might be more than most people want...

A decent nonvalidating XML parser in C shouldn't be large;
I'm thinking 10KB, maybe it's a bit larger; how big's "expat"?
Though I'd not assume any tools using that other metadata
would necessarily need to be used at boot time.

- 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

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

[Bill Nottingham]

David Brownell (david-b@pacbell.net) said: 
> > 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.
> 
> One thing I'm saying is that such things shouldn't matter.
> Intent shouldn't be asked; reliable program systems
> rarely have "if (CameFrom (...)) ..." logic.

Maybe. I'd prefer something more flexible. Because, all hotplug issues
aside, the assumption that you automatically want to bring up an
interface immediately on loading any module is one that's never been
made before, and one that I personally find irritating. (Then again,
I can just disable hotplug entirely, but I'd prefer to have it for
other things.)

> > > 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
> 
> I think you're misunderstanding what I'm saying.  But since
> network interface operation can't change for 2.4, and I
> think that's what you're focussed on, I won't try to clarify.

Please clarify. What I'm saying is that PPP is so fundamentally different
that you *can't* fit it into the ethernet model, even in a 2.5 framework,
unless you're willing to redesign the whole kernel/pppd/dialer interaction,
which would be a lot of code and would probably meet with a lot of
resistance.

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

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

[Bill Nottingham]

David Brownell (david-b@pacbell.net) said: 
> Noise in /var/log/messages that will normally be ignored.
> (If it's a problem, wouldn't it be a cardmgr problem?)

Yes, you could certainly make cardmgr be quiet.

> Systems with a dozen USB devices are not uncommon;
> I'd rather rely on hub LEDs for feedback than get lots of
> noise on reboot, or when I plug in a hub that has a bunch
> of devices already connected.

I'm not talking about USB at all. I'm talking about the transition
of users from 2.2 based systems to 2.4, and their expectations
thereof.

> "Have both these installed and any supported card will work"
> doesn't seem odd!  Quite the opposite.

I don't see how telling people 'you know all that stuff that used
to work fine? Now you need to install this *additional* package, which
is subtly different, and is configured differently, just to get 
the same functionality' wouldn't seem odd to them, especially when
they have to keep the old package around.

Basically, I just find the idea of using both at the same time ugly;
I'd prefer sticking with cardmgr, or doing the kernel work and
going fully to the hotplug package.

> > It's actually not too hard to make cardmgr work fine with 2.4.
> 
> Never said it was.  The question is how to handle cardbus
> support, given that pcmcia_cs (with cardmgr) is oriented
> towards pcmcia while the overall Linux direction seems to
> be to towards a more general framework for pci hotplug.

One can use cardmgr's previous cardbus support with minor kernel
patches.

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

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

[David Brownell]

> > Systems with a dozen USB devices are not uncommon;
> > I'd rather rely on hub LEDs for feedback than get lots of
> > noise on reboot, or when I plug in a hub that has a bunch
> > of devices already connected.
> 
> I'm not talking about USB at all. I'm talking about the transition
> of users from 2.2 based systems to 2.4, and their expectations
> thereof.

Yet full support for 2.4 includes hotplugging of USB, and one of
your issues was the lack of audible hotplug feedback ...


> > > It's actually not too hard to make cardmgr work fine with 2.4.
> > 
> > Never said it was.  The question is how to handle cardbus
> > support, given that pcmcia_cs (with cardmgr) is oriented
> > towards pcmcia while the overall Linux direction seems to
> > be to towards a more general framework for pci hotplug.
> 
> One can use cardmgr's previous cardbus support with minor kernel
> patches.

This is the first time I've heard that; the topic has come up
several times, and the story I've gotten from the answers is that
pcmcia_cs integration with kernel cardbus support is still weak.
(I don't have a Cardbus setup, so I have to trust those answers.)

It could be that folk have been going at that question with
different assumptions.

- 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

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

[Miles Lane]

Bill Nottingham wrote:


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

This isn't true.  The 2.4.x kernel drivers should handle virtually
all Cardbus *and* PCMCIA devices.  At least, that's what David
Hinds told me.  So, if you compile a 2.4.x kernel with Cardbus
and i82365 and build the necessary drivers, you should be able 
to load the modules and use your PCMCIA devices.  You'd just
build pcmcia_cs support in order to get the cardmgr and cardctl
programs and the various config and opts files.  If you do this,
then pcmcia_cs shouldn't do any "beeping" during the boot process,
because all PC Cards will be configured by /sbin/hotplug.

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

David Hinds' recent cardmgr releases should already have the 
work-around built in to not attempt to configure any devices 
that 2.4.x kernel hotplugging will handle.  NOTE:  This is *not* 
just for Cardbus PC Cards.  There are 2.4.x in-kernel drivers 
that do handle PCMCIA cards.  For example, for PCMCIA cards.  
I build:

    ls /lib/modules/2.4.2/kernel/drivers/net/pcmcia/

	3c574_cs.o  aironet4500_cs.o  netwave_cs.o  pcnet_cs.o
	smc91c92_cs.o  xirc2ps_cs.o  3c589_cs.o  fmvj18x_cs.o
	nmclan_cs.o  ray_cs.o  wavelan_cs.o  xircom_tulip_cb.o

     ls /lib/modules/2.4.2/kernel/drivers/char/pcmcia/

	serial_cb.o  serial_cs.o

As a reminder, here is David Hinds list of work items related
to getting PCMCIA support into the kernel (the recent design
work done by Adam Richter, Oliver Neukum and others overhauls
portions of this list):

 > To include 16-bit PCMCIA cards in the hotplug framework
 > would require few driver changes; the only mandatory
 > changes would be in how drivers register themselves and
 > are hooked up with appropriate devices:
 >
 > -- Make up pcmcia_device_id and pcmcia_driver types, and
 > write new register/unregister calls to parallel PCI and
 > USB drivers.  This would eventually take over for the "ds"
 > module and cardmgr.
 >
 > -- Rewrite all PCMCIA client drivers to have
 > MODULE_DEVICE_TABLE entries and use the new driver
 > services.  This can all be done incrementally, with
 > ds/cardmgr handling old-style drivers.
 >
 > -- The CIS override functionality in the PCMCIA package
 > is unpleasant to support in a completely in-kernel framework.
 >
 > Missing functionality in the hot plug framework:
 >
 > -- Only new network devices generate /sbin/hotplug events
 > now.  Modify all other device types to also do so: the ones
 > currently handled by PCMCIA include serial, parallel, SCSI
 > (all types), and IDE.
 >
 > -- There is no mechanism to request a card eject in the new
 > framework.  This is required for clean shutdown of SCSI and
 > IDE adapters.
 >
 > -- The PCMCIA device configuration scripts have a lot of
 > capabilities that the hotplug scripts do not have yet.
 > At the moment, the extent of device-specific hotplug
 > configuration is running "ifup".
 >
 > Missing functionality in the 2.4 PCMCIA drivers:
 >
 > -- The yenta driver can't handle CardBus adapter cards for
 > desktop systems.  Many require explicit overrides for the
 > default interrupt delivery settings, and a few require other
 > special bridge settings.
 >
 > -- The i82365 driver can't handle (non-CardBus) PCI-to-PCMCIA
 > bridges any more.  Some of the PCI code in the old i82365
 > driver needs to be put back.

Anyhow, I am looking forward to seeing a restatement of this
list by Adam Richter and Oliver Neukum in light of their
recent discussions.

	Miles


_______________________________________________
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

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

[Miles Lane]

David Brownell wrote:

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

No.  Unless I am greatly mistaken, all PC Cards can be handled
by /sbin/hotplug by 2.4.x drivers and cardmgr should ignore
devices supported by those drivers.  I guess all that's really
needed from pcmcia_cs at this point is cardctl and the config
files.

>> That's rather ugly (cardmgr will still print messages for everything
>> that's inserted), 

It shouldn't, since it should be ignoring those devices.

> Noise in /var/log/messages that will normally be ignored.
> (If it's a problem, wouldn't it be a cardmgr problem?)
> 
>>    inconsistent in UI (cardmgr beeps, etc., hotplug
>> doesn't), 

Shouldn't happen, unless you are trying to mix 2.4.x
drivers with pcmcia_cs drivers (can this even work?).
I punted on testing pcmcia_cs stuff a long time ago
and just use the 2.4.x drivers for everything.  Works
for me.

<snip>

> Though if you really think that CardBus hotplugging should
> beep, that should be an easy patch ... cPCI evidently uses
> blue lights in its feedback (doesn't Compaq's Hotplug PCI
> use LEDs too?), so that shouldn't be a PCI-wide policy.

I don't think the beeps are needed, but I suppose we could
make it a configuration setting.  Some people, understandably,
like the reassurance of system feedback telling them that
everything is working as it should be.

>>    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.)
> 
> 
> "Have both these installed and any supported card will work"
> doesn't seem odd!  Quite the opposite.

If you are using the 2.4.x kernel drivers and pcmcia_cs cardctl
and config files, none of this should be a problem.

>> It's actually not too hard to make cardmgr work fine with 2.4.
> 
> 
> Never said it was.  The question is how to handle cardbus
> support, given that pcmcia_cs (with cardmgr) is oriented
> towards pcmcia while the overall Linux direction seems to
> be to towards a more general framework for pci hotplug.

The sooner we can supercede pcmcia_cs functionality with
drivers in the kernel tree and a hotplug support package, 
the happier I'll be.

	Miles


_______________________________________________
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

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

[Miles Lane]

Bill Nottingham wrote:

> David Brownell (david-b@pacbell.net) said: 
> 
>>> 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.
>> 
>> One thing I'm saying is that such things shouldn't matter.
>> Intent shouldn't be asked; reliable program systems
>> rarely have "if (CameFrom (...)) ..." logic.
> 
> 
> Maybe. I'd prefer something more flexible. Because, all hotplug issues
> aside, the assumption that you automatically want to bring up an
> interface immediately on loading any module is one that's never been
> made before, and one that I personally find irritating. (Then again,
> I can just disable hotplug entirely, but I'd prefer to have it for
> other things.)

A net.opts text file could be used to flag which devices to
ignore in the hotplug process.  Wouldn't this be trivial to 
implement?

>>>> 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
>> 
>> I think you're misunderstanding what I'm saying.  But since
>> network interface operation can't change for 2.4, and I
>> think that's what you're focussed on, I won't try to clarify.
> 
> 
> Please clarify. What I'm saying is that PPP is so fundamentally different
> that you *can't* fit it into the ethernet model, even in a 2.5 framework,
> unless you're willing to redesign the whole kernel/pppd/dialer interaction,
> which would be a lot of code and would probably meet with a lot of
> resistance.

Agreed.  In my usage of PCMCIA modems, I have only wanted to 
be connected when I am active on the internet.  I never did
get diald to work, probably because I just didn't take the
effort required.  I do wish that demand-dialing were more 
straightforward to set up.  

What I *would* like to see is support for noticing when a 
new type of modem is inserted and some sort of interactive
configuration system popping up under XFree86.  I suppose
there could be a text-mode version that could launch during
the boot process if a new device is present at boot time.
Then the device could get configured before XFree86 launches.

This is pretty much how I'd like all new system devices
get set up that require sysadmin/user configuration (network
devices, printers, etc).  

This is meant to address, in part, your earlier comments 
regarding the need to a different method of determining 
which network interfaces are assigned to network devices 
at boot time, instead of just relying of PCI bus slot 
location.

This could apply to USB network devices as well.  Basically,
the notion is to map an interface and configuration based
on a flexible set of device characteristics (USB topology
location, device type or the order of a port on a multiport
device).

I know I am probably bungling this feature description,
but hopefully you'll get the gist of the idea.

	Miles


_______________________________________________
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

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

[Miles Lane]

Bill Nottingham wrote:

> David Brownell (david-b@pacbell.net) said: 
> 
>> Noise in /var/log/messages that will normally be ignored.
>> (If it's a problem, wouldn't it be a cardmgr problem?)
> 
> 
> Yes, you could certainly make cardmgr be quiet.
> 
> 
>> Systems with a dozen USB devices are not uncommon;
>> I'd rather rely on hub LEDs for feedback than get lots of
>> noise on reboot, or when I plug in a hub that has a bunch
>> of devices already connected.
> 
> 
> I'm not talking about USB at all. I'm talking about the transition
> of users from 2.2 based systems to 2.4, and their expectations
> thereof.
> 
> 
>> "Have both these installed and any supported card will work"
>> doesn't seem odd!  Quite the opposite.
> 
> 
> I don't see how telling people 'you know all that stuff that used
> to work fine? Now you need to install this *additional* package, which
> is subtly different, and is configured differently, just to get 
> the same functionality' wouldn't seem odd to them, especially when
> they have to keep the old package around.

If we don't jettison pcmcia_cs soon by just bundling cardctl
and the config files into a hotplug distribution, aren't we
just overlooking the obvious?  Please explain to me why I
am wrong about this.

> Basically, I just find the idea of using both at the same time ugly;
> I'd prefer sticking with cardmgr, or doing the kernel work and
> going fully to the hotplug package.

Yes.  I believe the plan is to go hotplug-only ASAP.  If you
can suggest exactly what you think is needed to make that
happen, that would be a good start.

>>> It's actually not too hard to make cardmgr work fine with 2.4.
>> 
>> Never said it was.  The question is how to handle cardbus
>> support, given that pcmcia_cs (with cardmgr) is oriented
>> towards pcmcia while the overall Linux direction seems to
>> be to towards a more general framework for pci hotplug.
> 
> 
> One can use cardmgr's previous cardbus support with minor kernel
> patches.

Can you explain what you mean a bit more?

	Miles


_______________________________________________
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

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

[David Hinds]

On Mon, Feb 26, 2001 at 10:23:37PM -0800, Miles Lane wrote:
> 
> This isn't true.  The 2.4.x kernel drivers should handle virtually
> all Cardbus *and* PCMCIA devices.  At least, that's what David
> Hinds told me.  So, if you compile a 2.4.x kernel with Cardbus
> and i82365 and build the necessary drivers, you should be able 
> to load the modules and use your PCMCIA devices.  You'd just
> build pcmcia_cs support in order to get the cardmgr and cardctl
> programs and the various config and opts files.  If you do this,
> then pcmcia_cs shouldn't do any "beeping" during the boot process,
> because all PC Cards will be configured by /sbin/hotplug.

Err no.  2.4.x kernel drivers exist for most of the 16-bit PCMCIA
cards supported by pcmcia-cs.  But they are not hotplug drivers; only
the Cardbus drivers are hotplug aware.  No 16-bit PC Cards are
configured by /sbin/hotplug.

> David Hinds' recent cardmgr releases should already have the 
> work-around built in to not attempt to configure any devices 
> that 2.4.x kernel hotplugging will handle.  NOTE:  This is *not* 
> just for Cardbus PC Cards. 

Yes it is just for CardBus cards.  And it will actually require a
small one-line kernel patch which I haven't submitted yet.

> As a reminder, here is David Hinds list of work items related
> to getting PCMCIA support into the kernel (the recent design
> work done by Adam Richter, Oliver Neukum and others overhauls
> portions of this list):

As far as I know none of the things I listed are done yet.  Is that
not correct?

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

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

[Miles Lane]

David Hinds wrote:

> On Mon, Feb 26, 2001 at 10:23:37PM -0800, Miles Lane wrote:
> 
>> This isn't true.  The 2.4.x kernel drivers should handle virtually
>> all Cardbus *and* PCMCIA devices.  At least, that's what David
>> Hinds told me.  So, if you compile a 2.4.x kernel with Cardbus
>> and i82365 and build the necessary drivers, you should be able 
>> to load the modules and use your PCMCIA devices.  You'd just
>> build pcmcia_cs support in order to get the cardmgr and cardctl
>> programs and the various config and opts files.  If you do this,
>> then pcmcia_cs shouldn't do any "beeping" during the boot process,
>> because all PC Cards will be configured by /sbin/hotplug.
>
> Err no.  2.4.x kernel drivers exist for most of the 16-bit PCMCIA
> cards supported by pcmcia-cs.  But they are not hotplug drivers; only
> the Cardbus drivers are hotplug aware.  No 16-bit PC Cards are
> configured by /sbin/hotplug.

Hmm, okay.  Sorry I overlooked the need to hotplug-enable the
PCMCIA drivers in the kernel tree.

>> David Hinds' recent cardmgr releases should already have the 
>> work-around built in to not attempt to configure any devices 
>> that 2.4.x kernel hotplugging will handle.  NOTE:  This is *not* 
>> just for Cardbus PC Cards. 
> 
> Yes it is just for CardBus cards.  And it will actually require a
> small one-line kernel patch which I haven't submitted yet.

When do you plan to submit your patch?

>> As a reminder, here is David Hinds list of work items related
>> to getting PCMCIA support into the kernel (the recent design
>> work done by Adam Richter, Oliver Neukum and others overhauls
>> portions of this list):
> 
> As far as I know none of the things I listed are done yet.  Is that
> not correct?

They aren't done.  In fact, the work on the list is still in the
design discussion phase.  The discussion got a bit myopically
focussed on the problem of getting hotplug event handling 
implemented in a really sensible and race-free way.  Adam Richter
and Oliver Neukum have reached an agreement between them about
a design solution.  A message was sent to the list containing
the design.  So far, noone has given them feedback.  Hopefully,
once the event handling design is agreed upon, the discussion
will get back to addressing your list of issues and we'll 
come up with a general design and development plan.  

If you are willing to give feedback on the event handling
design, please read Adam's message with the subject:

	Update on hot plugging serialization without
	kernel event queuing

The message was sent on 02/24/01 at 8:25pm.

Thanks,
	Miles



_______________________________________________
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

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

[David Brownell]

> > David Hinds' recent cardmgr releases should already have the 
> > work-around built in to not attempt to configure any devices 
> > that 2.4.x kernel hotplugging will handle.  NOTE:  This is *not* 
> > just for Cardbus PC Cards. 
> 
> Yes it is just for CardBus cards.  And it will actually require a
> small one-line kernel patch which I haven't submitted yet.

So David -- were you (indirectly) agreeing with much of what
I had said about Cardbus direction?  Specifically:

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

Given that patch of yours, and working PCI hotplug support,
what else do you think is needed to make Cardbus support
be as functional as you've gotten PCMCIA to be?  Testing
for sure, and I suspect at least a few more items on that list
of yours.  "PCI eject" functionality comes to mind too, and
maybe supporting hotplug in a few layers above hotplug.

(This isn't a recap of that "PCMCIA hotplug" discussion;
it should be a truncated version, since the PCI drivers are
already converted to handle PCI hotplug ... )

- 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

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

[David Hinds]

On Tue, Feb 27, 2001 at 09:14:15PM -0800, Miles Lane wrote:

> > Yes it is just for CardBus cards.  And it will actually require a
> > small one-line kernel patch which I haven't submitted yet.
> 
> When do you plan to submit your patch?

I decided to re-do the cardmgr bit so the patch is not needed.  It
will be in today's PCMCIA snapshot.

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

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

[David Brownell]

>>>> In the 2.5
>>>> kernels it might be good to make all network interfaces
>>>> fit into a common initialization model.
>     ...
> Please clarify. What I'm saying is that PPP is so fundamentally different
> that you *can't* fit it into the ethernet model, even in a 2.5 framework,
> unless you're willing to redesign the whole kernel/pppd/dialer interaction,
> which would be a lot of code and would probably meet with a lot of
> resistance.

I didn't say turn PPP into Ethernet, or vice versa, but find the
commonality.  It's there somewhere in the OS ... if some parts
of the initialization model are only available implicitly by using
interface names (which can change, someone said) then it should
be made explicit, so tools can work without heuristics.  (OK,
some folk really like heuristics there, I don't.)  If the model is
needlessly complex, simplify it.

For one example, it can be argued that it's wrong for the kernel
to report that "ppp0" has been "registered".  It's in some config
file somewhere, "registered" but just not known to the kernel.
Maybe "register" is the wrong network hotplug event to report
in such a case, hmm?

- 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

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

[Bill Nottingham]

Miles Lane (miles@megapathdsl.net) said: 
> > One can use cardmgr's previous cardbus support with minor kernel
> > patches.
> 
> Can you explain what you mean a bit more?

Well, cardmgr currently detects cardbus cards and does most of
the userland stuff OK; it's just that the device names it
passes to userspace get really confused. One can add some
hacks to get the network device right, but this can cause
other problems.

Alternatively, you can have cardmgr deal with all the insertion/removal
events, and just have hotplug deal with the interfaces created
(i.e., stub /etc/pcmcia/network.)

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

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

[Bill Nottingham]

David Brownell (david-b@pacbell.net) said: 
> > Please clarify. What I'm saying is that PPP is so fundamentally different
> > that you *can't* fit it into the ethernet model, even in a 2.5 framework,
> > unless you're willing to redesign the whole kernel/pppd/dialer interaction,
> > which would be a lot of code and would probably meet with a lot of
> > resistance.
> 
> I didn't say turn PPP into Ethernet, or vice versa, but find the
> commonality.  It's there somewhere in the OS ... if some parts
> of the initialization model are only available implicitly by using
> interface names (which can change, someone said) then it should
> be made explicit, so tools can work without heuristics.  (OK,
> some folk really like heuristics there, I don't.)  If the model is
> needlessly complex, simplify it.
> 
> For one example, it can be argued that it's wrong for the kernel
> to report that "ppp0" has been "registered".  It's in some config
> file somewhere, "registered" but just not known to the kernel.
> Maybe "register" is the wrong network hotplug event to report
> in such a case, hmm?

Maybe. It technically is a registration event, though, in that's
when the device is first registered. I guess the distinction
is that a ppp device is registered as *part* of the process of
bringing it up. Ethernet devices aren't.

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

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

[David Hinds]

On Thu, Mar 01, 2001 at 12:27:50AM -0500, Bill Nottingham wrote:
> 
> Alternatively, you can have cardmgr deal with all the insertion/removal
> events, and just have hotplug deal with the interfaces created
> (i.e., stub /etc/pcmcia/network.)

In the latest beta, cardmgr will do nothing when it sees a card that
has a matching hotplug driver; it assumes that the hotplug stuff will
take care of loading drivers as well as configuring interfaces.

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

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

[David Brownell]

> Alternatively, you can have cardmgr deal with all the insertion/removal
> events, and just have hotplug deal with the interfaces created
> (i.e., stub /etc/pcmcia/network.)

Given the latest hotplug scripts release, do you know of any problems
(including missing functionality that matters) with /etc/hotplug/net.agent
being used to handle what the /etc/pcmcia/network stuff did before?
At least on systems that can rely on "ifup".

It does what I need it to do, but that's not a very thorough test ... :)

If so, that'll mean we've completed that "mutual non-interference pact"
needed to keep pcmcia_cs and hotplug from stepping on each others'
toes -- in this case.

- 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