hotplug TTD
So. What needs to be done to finish this thing?
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Well, for one thing, my Belkin BusPort Mobile USB Host-controller (which is a Cardbus PCcard) needs to start getting configured when it is inserted. This was working in 2.4.0-test12-pre5 and broken in all subsequent kernels.
Another thing, we need to add in support for collecting the device detection events early in the boot process and then replay those events to /sbin/hotplug, so that those devices get configured.
Also, currently we still get errors during the boot process where Request_module fails with an error like this one:
kernel: request_module[scsi_hostadapter]: Root fs not mounted
Since this message is being generated during a time when it is impossible to actually load modules, this error message should not be emitted.
I imagine there are other issues in addition to these.
Cheers,
Miles
Quoted 6 lines · Morton, Andrew [WOLL:4009-M:EXCH] wrote:
So. What needs to be done to finish this thing?
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Hmm. I assume that by "finish this thing", you mean the generic portion of hotplug support. There are obviously boatloads of changes needed in all the hotplug bus trees and for all the hotpluggable devices.
The respective development communities will need to enumerate the requirements for their areas (this IS an invitation):
SCSI
Fusion MPT?
I2O?
IrDA
FireWire
PCMCIA/PC-Card
- Network adapter cards
- SCSI adapter cards
- USB host-controller cards
- Wireless network adapter cards
- ISDN adapter -- AVM A1 PCMCIA (Fritz)
Wireless Networking
PCI
USB
A somewhat tangential project is porting support for all the devices covered by the pcmcia-cs package into the kernel tree. This project also includes working out all the usermode utility and configuration support issues. Currently, the pcmcia-cs configuration does not work for the native kernel drivers in 2.4.0 (yenta, 3c59x, etc).
I would prefer to see default configuration files live in the kernel tree and be installed by the kernel installation process when PCMCIA/Cardbus support is selected. Ideally, the necessary usermode support utilities would be disseminated in the same way that ksymoops and modutils are now.
Other thoughts?
Miles
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Perhaps I'm just being pedantic, but I'd like to just clarify
that many of the Linux-related facilities that people refer to as "hot plugging" in are not really hot plugging, but rather a set of facilities used by most of the kernel hot plugging schemes:
1. a standardized hardware identification scheme for the bus in question (ISAPnP, PCI, USB, other systems covered by Intel Plug'n'Play standards, etc.)
2. a facility for dynamically loading kernel driver modules for that bus.
3. A MODULE_DEVICE_ID table for that format in each relevant driver.
4. Support for that ID table format in depmod
5. A user level program that reads the appropriate depmod modules.___map and figures out which modules to load.
For example, I understand that ISAPnP hardware is not
capable of hot plugging, but it uses these same facilities. Conceivably, other non-hotplug busses that have quasi-standard schemes for hardware enumeration could use these facilities as well (NuBus? S-Bus?).
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 1 line
So. What needs to be done to finish this thing?
Can one "finish" software, ever? :-)
A few things on my mind: move the hotplug scripts to this new linux-hotplug project. Create better hotplug docs, put them on the a website. Maybe the hotplug programs should turn into C programs not scripts, who knows. Volunteers?
Technically, there are open issues I think need to be addressed.
First, get hotplugging back to the behavior I saw in about test11, which is bugfixing and testing. Call this "kernel 2.4.1 work" for the most part; basically, hotplugging for USB, PCI/Cardbus, and NETworking should all work smoothly.
- Sync up with the 2.4.0-final ABI change for usb_device_id, including "usbutils" and various bugs (usb-serial etc) that snuck in with that change. (I think modutils is set.)
- More testing on the "new" user mode hotplug scripts (which use /etc/hotplug exclusively) ... adding a PCI hotplug agent (steal from the old one).
- Find out what's up with those async changes (test12) that sometimes seem to wedge things when I modprobe a USB HCD for a controller that's got a network adapter pre-connected. (Andrew, I've not yet made time to try your sync/async patch putting USB back in pure synchronous mode; chasing an oops.)
- Similarly for the PCI/Cardbus hotplug situation; Miles has reported problems there.
- Are those network API changes a 2.4.1 issue -- replacing init_etherdev() with prepare_etherdev()/withdraw_netdev() ? It was my understanding they were needed to cleanly do network hotplugging.
I think that all USB devices other than some of the funkier HID devices should be ready to hotplug at this time ... the main win from that ABI change was simpler handling for usb-storage, but we got some destabilization too.
Second, there are various types of related functionality to be developed. Addressing the "can't hotplug during boot" issue (something kudzu-like to scan /proc/bus/{usb,pci}/*/* and create hotplug events). Some sort of generic analogue to "cardctl eject" would be good. And as Miles noted, "pcmcia_cs" is a degenerate case of (generic) hotplug ...
There's also device/driver specific initialization that we should understand better. We know how to ensure that a USB controller (on any PCI bus) is cleanly initted. I don't think we know how to do that for a disk drive (start with SCSI and generalize) or printer.
- Dave
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Hi Adam,
Quoted 4 lines
Perhaps I'm just being pedantic, but I'd like to just clarify
that many of the Linux-related facilities that people refer to as "hot plugging" in are not really hot plugging, but rather a set of facilities used by most of the kernel hot plugging schemes:
I don't think there's been a strict definition of "hotplugging", but you're _absolutely right_ that what we've got is a collection of facilities that need to be reasonably well integrated. Which is one of the challenges in growing it, moving forward.
Quoted 3 lines
1. a standardized hardware identification scheme for the bus in question (ISAPnP, PCI, USB, other systems covered by Intel Plug'n'Play standards, etc.)
That's pretty much what the original "PCI Hotplug" config option did. It's evolved a bit since then ... ;-)
Quoted 2 lines
2. a facility for dynamically loading kernel driver modules for that bus.
That's one of the subtasks "/sbin/hotplug" (CONFIG_HOTPLUG) enables; but not the only one.
Quoted 4 lines
3. A
MODULE_DEVICE_IDtable for that format in each relevant driver.4. Support for that ID table format in depmod
Also within each bus framework ... USB, PCI, and ISAPNP use those tables when binding drivers to devices.
Quoted 2 lines
5. A user level program that reads the appropriate depmod modules.___map and figures out which modules to load.
And there's more:
- "Network hotplugging" isn't specific to any given bus, it works for all network devices.
- I suspect that "SCSI" hotplugging (like "input" hotplugging) will be more what one might think of as a "logical" bus that needn't correspond to any particular type of hardware. (USB storage device, even flash memory, are virtual SCSI devices; the input subsystem isn't USB-specific.)
- It includes device configuration, not just module loading; Hotplugging is useful even on fully static kernels.
Basically, "plug the device in and it's immediately usable" is the goal of hotplugging. So it's got to cover more than just device-to-driver binding issues; in some cases it'll need to know how to notify applications about new devices they should be managing.
Quoted 5 lines
For example, I understand that ISAPnP hardware is not
capable of hot plugging, but it uses these same facilities. Conceivably, other non-hotplug busses that have quasi-standard schemes for hardware enumeration could use these facilities as well (NuBus? S-Bus?).
Yes. I usually think of hotplug as "autoconfiguring Linux". The same kinds of facilities (and "design patterns" if I can mention that here without getting shot!) can apply in many contexts.
For example, I think there's no virtue to having separate ways to configure USB or PCI devices depending on whether they were there at powerup time ("cold plugging") or were plugged in later ("hot" pluggging).
Once I start thinking that way, I think "hotplug" maybe wasn't the perfect name ... not that I know a better one, of course!
- Dave
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
ACPI.
-- Andy
Quoted 5 lines
From: Miles Lane [mailto:[email protected]] The respective development communities will need to enumerate the requirements for their areas (this IS an invitation):
Quoted 14 lines
SCSI
Fusion MPT?
I2O?
IrDA
FireWire
PCMCIA/PC-Card
- Network adapter cards
- SCSI adapter cards
- USB host-controller cards
- Wireless network adapter cards
- ISDN adapter -- AVM A1 PCMCIA (Fritz)
Wireless Networking
PCI
USB
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Is it unreasonable, long-term, to move towards a unified Linux hotplug architecture?
Under both Windows and BeOS, a given bus driver is responsible for enumerating the devices on it, and it tells a central "configuration manager", who then is the one who loads the drivers.
Having one entity who knows about all devices on a system is also great for power management, and implementing suspend-to-memory and suspend-to-disk.
Thoughts?
Regards -- Andy
Quoted 24 lines
From: Adam J. Richter [mailto:[email protected]]
Perhaps I'm just being pedantic, but I'd like to just clarify
that many of the Linux-related facilities that people refer to as "hot plugging" in are not really hot plugging, but rather a set of facilities used by most of the kernel hot plugging schemes:1. a standardized hardware identification scheme for the bus in question (ISAPnP, PCI, USB, other systems covered by Intel Plug'n'Play
standards, etc.)2. a facility for dynamically loading kernel driver modules for that bus.
3. A
MODULE_DEVICE_IDtable for that format in each relevant driver.4. Support for that ID table format in depmod
5. A user level program that reads the
appropriate depmod
modules.___map and figures out which
modules to load.
Quoted 5 lines
For example, I understand that ISAPnP hardware is not
capable of hot plugging, but it uses these same facilities. Conceivably, other non-hotplug busses that have quasi-standard schemes for hardware enumeration could use these facilities as well (NuBus? S-Bus?).
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · David Brownell
- Are those network API changes a 2.4.1 issue -- replacing
init_etherdev()with prepare_etherdev()/withdraw_netdev() ? It was my understanding they were needed to cleanly do network hotplugging.
No, they're not likely to be a problem. The unpopular dev_probe_lock() protects us for Cardbus and PCI devices. A sleep 1' prior to running ifconfig up' will pretty well avoid any problems. Probably unnecessary though.
Quoted 11 lines
I think that all USB devices other than some of the funkier HID devices should be ready to hotplug at this time ... the main win from that ABI change was simpler handling for usb-storage, but we got some destabilization too.
Second, there are various types of related functionality to be developed. Addressing the "can't hotplug during boot" issue (something kudzu-like to scan
/proc/bus/{usb,pci}/*/*and create hotplug events). Some sort of generic analogue to "cardctl eject" would be good. And as Miles noted, "pcmcia_cs" is a degenerate case of (generic) hotplug ...
mm.. For PCI isn't it simply a matter of parsing /proc/bus/pci/*/* (or lspci output) to determine all the devices, then synthesising hotplug events for them?
Now, there are a number of bells-n-whistles which could be added here. For example, people get irritated when they put their network cards into different slots and eth0 and eth1 get swapped around. We could fix this with some constraints, or a manual override before the automatic hotplug synthesis.
This is just one requirement - there are surely many others. 'fraid I haven't started to get my head around it yet.
Quoted 5 lines
There's also device/driver specific initialization that we should understand better. We know how to ensure that a USB controller (on any PCI bus) is cleanly initted. I don't think we know how to do that for a disk drive (start with SCSI and generalize) or printer.
err, yes. Plus if you run `/sbin/hotplug pci' five times
back-to-back for five devices, you'll cause a great storm of initialisation activity, concurrent execution of modprobe and all sorts of things. Kernels will explode,
I promise :) This is going to be complex.
We do need to bring the devices up sequentially and methodically.
-
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 11 lines · Andrew
Is it unreasonable, long-term, to move towards a unified Linux hotplug architecture?
Under both Windows and BeOS, a given bus driver is responsible for enumerating the devices on it, and it tells a central "configuration manager", who then is the one who loads the drivers.
Having one entity who knows about all devices on a system is also great for power management, and implementing suspend-to-memory and suspend-to-disk.
Not sure I completely understand this one.
Given that all the different bus ("resource"?) types have different discovery mechanisms, I think you're proposing that, once discovered, they will be recorded in a database of some form? In a unified format?
So we have, if you like, an array of objects each of which represents a device in the system, and they each have state, eject', powerdown' methods, etc?
Heh. XircomNic is-a CardbusDevice is-a PCIDevice is-a Device is-a blah.
It could get complex with devices behind bridges behind bridges. Is a bridge a device? Do we need to care about bridges?
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · Andrew
ACPI.
What are the ACPI requirements??
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines
From: Grover, Andrew <[email protected]>
Sent: Tuesday, January 09, 2001 10:34 PMIs it unreasonable, long-term, to move towards a unified Linux hotplug architecture?
I don't see why it would be unreasonable. Arguably, that's the direction that has been set already. But -- what do you mean by "architecture"? That's a loaded word in many minds.
So far I've been happy to start seeing subsystems share more structure and start to behave in the same kinds of ways. I think there's a long way we can usefuly go down that path. "Lightweight architecture"? The design patterns used by various subsystems need to fit together effectively.
Quoted 3 lines
Under both Windows and BeOS, a given bus driver is responsible for enumerating the devices on it, and it tells a central "configuration manager", who then is the one who loads the drivers.
Many of us don't know those two systems very well; but perhaps the "/sbin/hotplug" policy agent is analagous to that mananager. Except that it can't just "load drivers", it's got to configure them too. Maybe you could elaborate a bit?
Using USB and PCI (in Linux 2.4 kernels) as an example, clearly the bus drivers (USB HCDs, Cardbus or Hotplug PCI bridges) are going to enumerate devices and handle some of the config change details. But the goal is to punt all the hard policy questions (what driver, how to set it up) to userspace through one mechanism (/sbin/hotplug).
Quoted 2 lines
Having one entity who knows about all devices on a system is also great for power management, and implementing suspend-to-memory and suspend-to-disk.
I'm glad you mentioned power management, the "hot" in "hot plug"!
USB has some work to do yet for power management. For example, I suspect that USB Host Controller Drivers ("HCDs") should mediate suspend/resume processing for each of their devices, ensuring devices get suspended before bridges (and resumed after). That's simple enough to do (Cardbus got complicated because of PCMCIA) but it calls for "struct usb_driver" API updates.
So far I've been thinking of power management as _mostly_ an issue that subsystems should deal with locally ... following global rules and policies. Likely you have clearer ideas about how those should get reflected down to the subsystems, or back to some global/central entity when policy questions arise.
- Dave
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 12 lines
From: Andrew Morton <[email protected]>
Sent: Wednesday, January 10, 2001 2:58 AMQuoted 7 lines · David Brownell
Second, there are various types of related functionality to be developed. Addressing the "can't hotplug during boot" issue (something kudzu-like to scan
/proc/bus/{usb,pci}/*/*and create hotplug events). Some sort of generic analogue to "cardctl eject" would be good. And as Miles noted, "pcmcia_cs" is a degenerate case of (generic) hotplug ...
Quoted 3 lines
mm.. For PCI isn't it simply a matter of parsing
/proc/bus/pci/*/*(or lspci output) to determine all the devices, then synthesising hotplug events for them?
Yes.
Though when I started to think about how to do that stuff robustly, I began to wish a kernel "module" didn't stop being a visible component when it gets statically linked. There's a rather arbitrary line between static linking (build tools) and dynamic linking (modutils). Hotplugging a device shouldn't need to care so much how the driver module is linked.
Quoted 5 lines
Now, there are a number of bells-n-whistles which could be added here. For example, people get irritated when they put their network cards into different slots and eth0 and eth1 get swapped around. We could fix this with some constraints, or a manual override before the automatic hotplug synthesis.
David Hinds at one point spoke in favor of having more info passed to the network hotplug events than just the interface name. That's critical for statically configured hardware (servers); dynamically configured ones (pure DHCP clients, say) should not care.
It's a generic problem with the notion of automagically assigning "user meaningful names" to hardware. Happens all the time when USB devices show up ... two card readers, two cameras, etc have exactly analagous problems. And it's not a problem "devfs" is able to handle, near as I can tell.
Quoted 2 lines
This is just one requirement - there are surely many others. 'fraid I haven't started to get my head around it yet.
Me either. Hence my "..." above ... ;-)
Quoted 11 lines
Quoted 5 lines
There's also device/driver specific initialization that we should understand better. We know how to ensure that a USB controller (on any PCI bus) is cleanly initted. I don't think we know how to do that for a disk drive (start with SCSI and generalize) or printer.
err, yes. Plus if you run `/sbin/hotplug pci' five times
back-to-back for five devices, you'll cause a great storm of initialisation activity, concurrent execution of modprobe and all sorts of things. Kernels will explode, I promise :)
Exploding penguin-shaped TV set-top boxes ... the holy grail of kernel development? Clearly a sign that we need Python developers involved ... ;-)
- Dave
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · David Brownell
Though when I started to think about how to do that stuff robustly, I began to wish a kernel "module" didn't stop being a visible component when it gets statically linked. There's a rather arbitrary line between static linking (build tools) and dynamic linking (modutils). Hotplugging a device shouldn't need to care so much how the driver module is linked.
Yes this is useful. For PCMCIA, I created /proc/bus/pccard/drivers to list what drivers are present, as static or modules. But a kernel wide solution would be better (even if it is /proc/bus/*/drivers).
Quoted 4 lines
David Hinds at one point spoke in favor of having more info passed to the network hotplug events than just the interface name. That's critical for statically configured hardware (servers); dynamically configured ones (pure DHCP clients, say) should not care.
Yes, I can tell you that if only the interface name is passed, it is going to frustrate some people who are used to having more information from PCMCIA. It isn't entirely bad... at least, you can get the interface's hardware address, and use that to choose configurations. But I find it quite useful to know that eth0 is "the 3C575 card in PCMCIA socket 1", or vice versa.
-- Dave
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Hi Dave,
Quoted 11 lines · David Brownell
Quoted 6 lines
Though when I started to think about how to do that stuff robustly, I began to wish a kernel "module" didn't stop being a visible component when it gets statically linked. There's a rather arbitrary line between static linking (build tools) and dynamic linking (modutils). Hotplugging a device shouldn't need to care so much how the driver module is linked.
Yes this is useful. For PCMCIA, I created
/proc/bus/pccard/driversto list what drivers are present, as static or modules. But a kernel wide solution would be better (even if it is/proc/bus/*/drivers).
It'd not just be "better", I suspect...
The first USB hotplug "/etc/usb/policy" checked /proc/bus/usb/drivers, but the current one doesn't.
Why? Because there are driver frameworks that are built on top of USB (like usb-serial, usb-storage, "input") so that multiple modules may need to get loaded. And so, lacking an explicit representation of the kernel's module structure, knowing the "usbcore" drivers that were there just wouldn't let me check if the driver actually did what I expected it to do. (Load/init OK, and bind to the device.)
In the case of "input", I think the hope is that someone will donate time to create an "input" hotplug system, that USB HID (and ADB?) will be able to use; it'll cause "keybdev", "mousedev", "joydev", and so on to get loaded.
But I don't think we should expect every driver framework to be that generic. A better global tool could really help robustness. It'd apply to big Linux servers, not just desktops ... the facilities needed to dynamically reconfigure a big server (downtime is bad!) aren't that different from those which prevent a desktop from needing to reboot when you install a new device. (Except that the desktop really needs to assume there's normally nobody that understands sysadmin.)
Quoted 11 lines
Quoted 4 lines
David Hinds at one point spoke in favor of having more info passed to the network hotplug events than just the interface name. That's critical for statically configured hardware (servers); dynamically configured ones (pure DHCP clients, say) should not care.
Yes, I can tell you that if only the interface name is passed, it is going to frustrate some people who are used to having more information from PCMCIA. It isn't entirely bad... at least, you can get the interface's hardware address, and use that to choose configurations. But I find it quite useful to know that eth0 is "the 3C575 card in PCMCIA socket 1", or vice versa.
This sort of issue can get sorted out as pcmcia_cs and hotplugging start to ... "co-evolve"? :-)
Quoted 1 line
-- Dave
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Devices on the ACPI bus need to have drivers loaded for them.
(For those that aren't familiar with it, one of ACPI's purposes is to replace PNPBIOS. So the ACPI driver has a list of hardware IDs that, if a mechanism existed to do so, it could load the appropriate drivers for.)
On a laptop undock, some of these would go away, and would need to be unloaded too.
If you would like me to expand further I am willing to. ;-)
Regards -- Andy
Quoted 10 lines
From: Andrew Morton [mailto:[email protected]]
Quoted 1 line
ACPI.
What are the ACPI requirements??
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines
From: Andrew Morton [mailto:[email protected]]
Quoted 1 line · Andrew
Having one entity who knows about all devices on a system
is also great for
Quoted 1 line
power management, and implementing suspend-to-memory and
suspend-to-disk.
Quoted 1 line
Quoted 6 lines
Not sure I completely understand this one.
Given that all the different bus ("resource"?) types have different discovery mechanisms, I think you're proposing that, once discovered, they will be recorded in a database of some form? In a unified format?
While different buses have different discovery mechanisms, they all will either result in either device removal or device insertion notifications. Since we will want to have one hotplug module loader (yes?) it seems necessary that the various bus enumerators communicate with it in a common format.
Having the loading entity keep track of what devices/drivers are already present would then have two advantages:
1) Bus enumeration drivers can, when queried, report all devices found, and do not have to worry about which ones have come or gone, because the manager is keeping track.
2) Because we know the entire device attachment tree, when suspending, we can send power-down requests outermost-first and vice-versa when resuming.
Quoted 4 lines
So we have, if you like, an array of objects each of which represents a device in the system, and they each have state,
eject',powerdown' methods,
etc?
I think so. But perhaps the appropriate structure is a tree, because devices depend on each other and we will need to sequence power transitions with that in mind. (e.g. don't turn off the PCI bus until all PCI devices are powered down.)
Quoted 6 lines
Heh. XircomNic is-a CardbusDevice is-a PCIDevice is-a Device is-a blah.
It could get complex with devices behind bridges behind bridges. Is a bridge a device? Do we need to care about bridges?
Yes, it can get complex, but I think we do need to account for bridges.
Regards -- Andy
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 11 lines
From: David Brownell [mailto:[email protected]]
Quoted 2 lines
From: Grover, Andrew <[email protected]> Is it unreasonable, long-term, to move towards a unified
Linux hotplug
Quoted 1 line
architecture?
I don't see why it would be unreasonable. Arguably, that's the direction
that has been set already. But -- what do you mean by "architecture"? That's a loaded word in many minds.
I mean we have individual subsystems doing HP all over the place. While each has bus-specific stuff, a lot of the stuff is the same across all of these.
Quoted 8 lines
Quoted 3 lines
Under both Windows and BeOS, a given bus driver is responsible for enumerating the devices on it, and it tells a central "configuration manager", who then is the one who loads the drivers.
Many of us don't know those two systems very well; but perhaps the "
/sbin/hotplug" policy agent is analagous to that mananager. Except that it can't just "load drivers", it's got to configure them too. Maybe you could elaborate a bit?
Well, of course devices need to be configured, but in my mind once we've loaded the driver that's half the battle. If I insert a USB foo device, the foo driver is going to be the one who knows how to configure it, yes? And, I remember reading that the latest modutils had some mechanism to pass config info, but I haven't looked further..
Quoted 5 lines
Using USB and PCI (in Linux 2.4 kernels) as an example, clearly the bus drivers (USB HCDs, Cardbus or Hotplug PCI bridges) are going to enumerate devices and handle some of the config change details. But the goal is to punt all the hard policy questions (what driver, how to set it up) to userspace through one mechanism (
/sbin/hotplug).
True, some setup info is surely needed. But one of the goals of hotplug is you insert the device and it "just works". Won't that be awesome?? ;-)
Quoted 5 lines
So far I've been thinking of power management as _mostly_ an issue that subsystems should deal with locally ... following global rules and policies. Likely you have clearer ideas about how those should get reflected down to the subsystems, or back to some global/central entity when policy questions arise.
I agree, a given subsystem driver is in a much better position to power manage itself instead of a global entity. But I also think the system needs be able to veto a subsystem's PM in light of the system's overall state.
For example, in Windows, a driver can request to be put into a power state. If the system has no objections, it turns around and tells the driver to switch states. This has two advantages: 1) it gives the OS the chance to not fulfill the request (if it knows turning off the device would have bad consequences) and 2) it lets the OS implement a simple PM strategy, that can then be overridden by the subsystem if it wishes. This saves each driver from worrying about PM policy if the OS's default policy is good enough.
Regards -- Andy
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
While I think of it. Something Linus said a few weeks back:
Quoted 3 lines
1: yenta driver sees the card insertion. schedules a call to
pci_insert_device
We should actually change this, and do it only for the case where we don't already have a driver for the device. If we have a driver fior the device, we should assume that it is the drivers responsibility to notify the system about higher-level events.
Does this really matter? We'll get a failed modprobe...
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Andrew,
Quoted 5 lines
Quoted 2 lines
1: yenta driver sees the card insertion. schedules a call to
pci_insert_deviceWe should actually change this, and do it only for the case where we don't already have a driver for the device.
Why? It's a "here's a new device" notification, being called when there's a new device!
It might be reasonable to have a _separate_ notification for the "this device has no driver" case, but those "new device" notifications will still be needed.
Quoted 3 lines
If we have a driver fior the device,
we should assume that it is the drivers responsibility to notify the system about higher-level events.
Not all higher level events; just some of them. Potentially.
The hotplug events in the current system are primarily what one could call "container" notifications: bus subsystems (USB, PCI) reporting add/remove events for their devices, or the network subsystem reporting register/unregister events at the higher level that it works with (above busses, below apps).
I don't think we want to encourage every driver to call some user mode helper directly, though I'm willing to accept that as a useful tool for rare cases. (Your async/sync fixes are helpful there, even enabling such calls in_interrupt.) The overall system has to be manageable and simple; encouraging lots of per-driver variation doesn't lead that direction.
- Dave
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Andy,
Quoted 2 lines
Well, of course devices need to be configured, but in my mind once we've loaded the driver that's half the battle.
This is true enough to be confusing. For some simple drivers it's the WHOLE of the battle!
If they show up as filesystem devices, apps use only filesystem-based discovery (after device connection), and the device is so simple that it doesn't need more configuration ... then that's enough. But that's not going to work for all devices or drivers.
Quoted 2 lines
If I insert a USB foo device, the
foo driver is going to be the one who knows how to configure it, yes?
The UNIX convention (inherited by Linux) is that some sysadmin knows how to configure it, using driver and application/service/tool docs (or sometimes UTSL) along with site policy knowledge (security, tool choice, etc) ... when additional configuration is needed.
So no, the driver is NOT going to be the one to know how to configure. It never has been, as a rule. There are lots of reasons why, and many of them can/will be automated through /sbin/hotplug; but there will be a few cases where sysadmins still need to help out.
Quoted 2 lines
True, some setup info is surely needed. But one of the goals of hotplug is you insert the device and it "just works". Won't that be awesome?? ;-)
It _is_ awesome ... just needs more work and a few 2.4.0 patches! :-)
Quoted 3 lines
And, I
remember reading that the latest modutils had some mechanism to pass config info, but I haven't looked further..
That's module configuration data, not device configuration data.
It's provided with the "load new module" code paths, and won't help much with subsequent "similar new device" processing. Two distinct problems, in my book.
- Dave
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · David Brownell
andrew.grover wrote
Quoted 3 lines
And, I
remember reading that the latest modutils had some mechanism to pass config info, but I haven't looked further..That's module configuration data, not device configuration data.
It can be either. The new mechanism allows for persistent module data, i.e. data values that are saved and restored across unload and reload, even across reboot. Modutils just saves and restores the data, it is up to the module to decide what to do with it. The obvious use is for user settings in media drivers; volume, balance, TV tuner settings etc.
Does persistent data make sense for hotuplugging devices? It depends on the device and the driver. Even if you use persistent data, the driver has to cope with the case of no data. There is no data for the initial load and when the saved data is not available, for whatever reason.
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
And, I
remember reading that the latest modutils had some mechanism to pass config info, but I haven't looked further..That's module configuration data, not device configuration data.
It can be either.
Hmm ... is there some simple example module on the web, doing both? I probably wouldn't have seen a notice, and haven't had time to do more than glance at the persistence patch in the modutils FTP area.
Was the output format text, or binary? Tools could be easier if they could rely on text.
It'd be nice if Linux had a better solution than distro-specific config files to hold device configuration data, and I could see the module persistence stuff evolving into that. It'd sure help make hotplug policy software be more portable if it could rely on all hotpluggable drivers (network, media, ...) using such a scheme.
- Dave
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · David Brownell
Hmm ... is there some simple example module on the web, doing both? I probably wouldn't have seen a notice, and haven't had time to do more than glance at the persistence patch in the modutils FTP area.
No module currently uses persistent data. I tested it with some dummy module code and released the patch. It is up to coders to decide how they use persistent data.
Quoted 2 lines
Was the output format text, or binary? Tools could be easier if they could rely on text.
man insmod, man rmmod, man modules.conf. All text. Persistent data behaves as if you specified the saved values on the insmod command line. The order is values from modules.conf, then saved persistent data, then insmod options. modules.conf is default values, persistent data is what you set the values to after loading, insmod is override for this load.
_______________________________________________
Linux-hotplug-devel mailing list
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Can we continue this discussion? It seems there are important questions left unanswered here.
Quoted 7 lines · Keith Owens
Quoted 7 lines
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
And, I remember reading that the latest modutils had some mechanism to pass config info, but I haven't looked further..
That's module configuration data, not device configuration data.
It can be either.
Quoted 7 lines
Quoted 3 lines
Hmm ... is there some simple example module on the web, doing both? I probably wouldn't have seen a notice, and haven't had time to do more than glance at the persistence patch in the modutils FTP area.
No module currently uses persistent data. I tested it with some dummy module code and released the patch. It is up to coders to decide how they use persistent data.
So, are we going to attempt to use the persistent module data for any Hotplug related development? Might this be helpful for giving some more consistent mapping of a device node to a physical device resource (e.g., /dev/eth0 -> the 3c575 with a particular set of device characteristics -- memory ranges, IRQ, DMA, etc)>
Quoted 15 lines
Quoted 2 lines
Was the output format text, or binary? Tools could be easier if they could rely on text.
man insmod, man rmmod, man modules.conf. All text. Persistent data behaves as if you specified the saved values on the insmod command line. The order is values from modules.conf, then saved persistent data, then insmod options. modules.conf is default values, persistent data is what you set the values to after loading, insmod is override for this load.
Quoted 5 lines
It'd be nice if Linux had a better solution than distro-specific config files to hold device configuration data, and I could see the module persistence stuff evolving into that. It'd sure help make hotplug policy software be more portable if it could rely on all hotpluggable drivers (network, media, ...) using such a scheme.
Has anyone begun using this data, yet?
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · Miles Lane
So, are we going to attempt to use the persistent module data for any Hotplug related development? Might this be helpful for giving some more consistent mapping of a device node to a physical device resource (e.g.,
/dev/eth0-> the 3c575 with a particular set of device characteristics -- memory ranges, IRQ, DMA, etc)>
I would be very wary of doing anything like that. Persistent data is a good fit for user controlled settings like volume and TV tuner values, where the worst case is a wrong volume or the wrong TV channel at start up.
If you use it for critical data such as IRQ then the worst case is the module does not load. It will confuse users when the data becomes obsolete and the module fails to load. It is not at all obvious where the insmod data is coming from.
One option does make sense to me. Use persistent data and rmmod -e to extract the persistent data to a file. Because rmmod -e does not remove the module (it only extracts the data), hotplug can use this mechanism as a way to extract data from the module and save it. Then the next hotplug load can decide if it wants to use the existing data or not, erasing the saved persistent data before issuing modprobe.
Alternatively hotplug can try to load the module twice, once leaving the persistent data alone, the second time it renames the saved data file. If one works, issue rmmod -e. If neither work, reinstate the persistent data file.
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel