Any ETA on getting the PCI hardware detection event replaying added?

Hi,

It seems like concensus has been reached about the general requirements for handling the detection of PCI/Cardbus devices which are already plugged in at boot time (this is the problem where exec_usermodehelper + /sbin/hotplug can't handle device detection and module insertion early in the boot sequence). I'm wondering if anyone is currently working on implementing this.

Miles

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

There's a bit in CVS right now, relying on versions of Adam Richter's "pcimodules". The USB analogue will require usbdevfs and "usbmodules" ... that's for the quick solution using off-the-shelf components.

There's an issue there: how to get the related programs properly up-to-date. "pcimodules" is a patch to "pciutils" now (I'd like a change in it, details below), and the current "usbutils" release is missing the modutils 2.4.2 support patch. I don't see getting rid of the need for hotplug awareness in such utilities, unless more data shows up in /proc and it gets easier to parse without C code.

- Dave

p.s. "pcimodules" changes I'd like to see:
- "-s pci_slot_name" ... one function at a time. On big systems, the current version might touch hundreds of PCI busses (said LKML recently)
- "--version" ... so scripts can defend against versions that are old or buggy
- "--if-unbound" (or somesuch) ... don't bother saying anything if the function has a driver already. (/proc/bus/pci/devices has that info.)

----- Original Message -----
From: "Miles Lane" <[email protected]>
To: <[email protected]>
Sent: Saturday, February 03, 2001 3:53 PM
Subject: Any ETA on getting the PCI hardware detection event replaying added?

_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

OK now the stuff in CVS is interesting for both USB and PCI ...

... so I include Adam's "pcimodules" patch, against "pciutils 2.1.8" (the latest)

... also attached is a patch against "usbutils-0.7" that merges the two previous patches, updates the manpage for "usbmodules", and says it's version "0.7hotplug". Use "configure --prefix /usr" so it installs where the hotplug utilities will see it, and (a) normal hotplugging will use "usbmodules" if usbdevfs is available, also
(b) it'll fake USB hotplug events.

I'd expect rough edges; for example, bringing up a network interface (present at boot time and not hotplugged) went very slowly, unclear why.

- Dave

diff -u usbutils-0.7/configure usbutils/configure
@@ -781,7 +781,7 @@
 
 PACKAGE=usbutils
 
-VERSION=0.7
+VERSION=0.7hotplug
 
 if test "`cd $srcdir && pwd`" != "`pwd`" && test -f $srcdir/config.status; then
   { echo "configure: error: source directory already configured; run "make distclean" there first" 1>&2; exit 1; }

diff -u usbutils-0.7/usbmodules.h usbutils/usbmodules.h
@@ -1,7 +1,19 @@
 /* Declaring the usb_device_id fields as unsigned int simplifies
    the sscanf call. */
 
+#define USB_MATCH_VENDOR		0x0001
+#define USB_MATCH_PRODUCT		0x0002
+#define USB_MATCH_DEV_LO		0x0004
+#define USB_MATCH_DEV_HI		0x0008
+#define USB_MATCH_DEV_CLASS		0x0010
+#define USB_MATCH_DEV_SUBCLASS		0x0020
+#define USB_MATCH_DEV_PROTOCOL		0x0040
+#define USB_MATCH_INT_CLASS		0x0080
+#define USB_MATCH_INT_SUBCLASS		0x0100
+#define USB_MATCH_INT_PROTOCOL		0x0200
+
 struct usbmap_entry {
+	unsigned int		match_flags;
 	/*
 	 * vendor/product codes are checked, if vendor is nonzero
 	 * Range is for device revision (bcdDevice), inclusive;