OT(?) -- Should the net.agent script cause "ifup lo" to be run?
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · Miles Lane
I am wondering how much of the work that is currently handled by init scripts like
/etc/rc.d/init.d/networkought 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
Quoted 8 lines
on the
/etc/rc.d/init/hotpluginit 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/lowasn't enabled. For some reason, mozilla doesn't finish initializing if/dev/loisn'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 [email protected] \ / 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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · Miles Lane
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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" <[email protected]>
To: <[email protected]>
Sent: Sunday, February 25, 2001 1:37 PM
Subject: Re: OT(?) -- Should the net.agent script cause "ifup lo" to be run?
Quoted 13 lines
Quoted 4 lines · Miles Lane
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:
Quoted 6 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · 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?
Any PCI device in an non-hotplug slot is not really hot-pluggable (at least without risk to the card and motherboard. ;) )
Quoted 1 line
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.)
Quoted 2 lines
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. :)
Quoted 2 lines
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.
Quoted 1 line
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines
From: "Bill Nottingham" <[email protected]>
Sent: Sunday, February 25, 2001 4:38 PMQuoted 2 lines · 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?
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?
Quoted 6 lines
Quoted 1 line
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.
Quoted 4 lines
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.)
Quoted 4 lines
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.
Quoted 5 lines
Quoted 2 lines
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?
Quoted 7 lines
Quoted 2 lines
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").
Quoted 6 lines
Quoted 1 line
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.
Quoted 4 lines
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 ... ;-)
Quoted 3 lines
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.
Quoted 6 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · David Brownell
Quoted 5 lines
Quoted 2 lines
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.
Quoted 4 lines
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'.
Quoted 6 lines
Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
Quoted 3 lines
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.
Quoted 3 lines
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. :)
Quoted 6 lines
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)...
Quoted 10 lines
Quoted 6 lines
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)
Quoted 3 lines
I could imagine an
/etc/hotplug/pci.blacklistfile, 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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines · Bill Nottingham
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 andxircom_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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · David Brownell
Quoted 7 lines
From: "Bill Nottingham" <[email protected]>
Sent: Sunday, February 25, 2001 4:38 PMI 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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · Bill Nottingham
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines
From: "Adam J. Richter" <[email protected]>
Sent: Sunday, February 25, 2001 2:03 AMI 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.
Quoted 1 line
On such a system, the boot process proper could be very fast.
A very useful side effect!
Quoted 4 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 11 lines
From: "Bill Nottingham" <[email protected]>
Sent: Sunday, February 25, 2001 8:12 PMQuoted 4 lines
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.
Quoted 2 lines
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?
Quoted 8 lines
Quoted 3 lines
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:
Quoted 5 lines
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.
Quoted 4 lines
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.
Quoted 8 lines
Quoted 4 lines
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".
Quoted 7 lines
Quoted 6 lines
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.
Quoted 7 lines
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, ...)
Quoted 3 lines
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!
Quoted 6 lines
Quoted 3 lines
I could imagine an
/etc/hotplug/pci.blacklistfile, 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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · David Brownell
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 4 lines
Quoted 4 lines
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:
Quoted 8 lines
Quoted 5 lines
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.
Quoted 3 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 2 lines
If the fb modules are hotpluggable, then
/sbin/hotplugwould 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.
Quoted 5 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines
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.)
Quoted 5 lines
Quoted 3 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines
Quoted 3 lines
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?)
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 1 line
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines
Quoted 5 lines
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.
Quoted 2 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines · David Brownell
Quoted 3 lines
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.)
Quoted 9 lines
Quoted 5 lines
Quoted 3 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · David Brownell
Noise in
/var/log/messagesthat will normally be ignored. (If it's a problem, wouldn't it be a cardmgr problem?)
Yes, you could certainly make cardmgr be quiet.
Quoted 4 lines
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.
Quoted 2 lines
"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.
Quoted 6 lines
Quoted 1 line
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines
Quoted 4 lines
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 ...
Quoted 9 lines
Quoted 6 lines
Quoted 1 line
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines · Bill Nottingham
Quoted 7 lines
Quoted 3 lines
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!
Quoted 5 lines
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.
Quoted 1 line
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.oAs 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):
Quoted 36 lines
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_idandpcmcia_drivertypes, 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_TABLEentries 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/hotplugevents 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:
Quoted 8 lines
-- 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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · David Brownell
Quoted 3 lines
Quoted 3 lines
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.
Quoted 2 lines
Quoted 2 lines
That's rather ugly (cardmgr will still print messages for everything that's inserted),
It shouldn't, since it should be ignoring those devices.
Quoted 5 lines
Noise in
/var/log/messagesthat will normally be ignored. (If it's a problem, wouldn't it be a cardmgr problem?)Quoted 2 lines
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>
Quoted 4 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 1 line
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 11 lines · Bill Nottingham
Quoted 7 lines · David Brownell
Quoted 3 lines
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.
Quoted 6 lines
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?
Quoted 11 lines
Quoted 9 lines
Quoted 5 lines
Quoted 3 lines
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.
Quoted 5 lines
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/dialerinteraction, 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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 24 lines · Bill Nottingham
Quoted 2 lines · David Brownell
Noise in
/var/log/messagesthat will normally be ignored. (If it's a problem, wouldn't it be a cardmgr problem?)Yes, you could certainly make cardmgr be quiet.
Quoted 4 lines
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.
Quoted 2 lines
"Have both these installed and any supported card will work" doesn't seem odd! Quite the opposite.
Quoted 5 lines
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.
Quoted 3 lines
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.
Quoted 10 lines
Quoted 6 lines
Quoted 1 line
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · Miles Lane
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_cssupport in order to get the cardmgr and cardctl programs and the various config and opts files. If you do this, thenpcmcia_csshouldn'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.
Quoted 4 lines
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.
Quoted 4 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 12 lines · David Hinds
Quoted 9 lines · Miles Lane
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_cssupport in order to get the cardmgr and cardctl programs and the various config and opts files. If you do this, thenpcmcia_csshouldn't do any "beeping" during the boot process, because all PC Cards will be configured by/sbin/hotplug.
Quoted 4 lines
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.
Quoted 7 lines
Quoted 4 lines
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?
Quoted 7 lines
Quoted 4 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines
Quoted 4 lines
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:
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · Miles Lane
Quoted 2 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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/dialerinteraction, 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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · Miles Lane
Quoted 2 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 14 lines · David Brownell
Quoted 5 lines
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/dialerinteraction, 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.
Quoted 5 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · Bill Nottingham
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel