usb.rc script

Hi,

Some comments on the script :

1- Calling all the rc scripts of /etc/hotplug/*.rc from /etc/init.d/hotplug is not really standard, and could break things..

2- Why it needs STATIC_MODULE, it couldn't be detected ?

3- Same for the interfaces, you load the interfaces when is not Admin level configurable (sometime when usb-(uhci|ohci) load it could freeze the box.

4- The rmmod in force is not really nice also...

Nerveless here is a small patch that bring some RH/MDK things, add the action/sucess/failure process and inform the subsys system :

@@ -30,6 +30,7 @@
     # e.g. USBD_ENABLEúlse but STATIC_MODULE_LIST has your devices
 fi
 
+. /etc/rc.d/init.d/functions
 
 MOUSE_MODULES="mousedev input"
 

@@ -49,10 +50,13 @@
 
 # FIXME -- "manual configuration" sysadmin mode isn't supported yet
 
+    echo -n "Starting USB interfaces: "
+
     modprobe -q usb-ohci >/dev/null 2>&1
     # modprobe -q usb-uhci >/dev/null 2>&1 || modprobe -q uhci >/dev/null 2>&1
     modprobe -q uhci >/dev/null 2>&1 || modprobe -q usb-uhci >/dev/null 2>&1
 
+
     if [ -d /proc/bus/usb ]; then
 	if grep -q "[	 ]/proc/bus/usb[	 ]" /etc/fstab
 	then

@@ -67,13 +71,14 @@
 	if [ $COUNT -le 2 ]; then
 	    umount /proc/bus/usb
 	    rmmod usbcore >/dev/null 2>&1
+	    failure ; echo
 	    return 1
 	fi
-
     # if USB is fully modular and yet can clean up,
     # we know init failed without needing usbdevfs
     elif rmmod usbcore >/dev/null 2>&1
     then
+	failure ; echo
 	return 1
     fi
 

@@ -88,12 +93,16 @@
 	modprobe $MODULE
     done
 
+    success ; echo
+
     # we did everything we could ...
     return 0
 }
 
 maybe_stop_usb ()
 {
+    echo -n "Unloading USB interfaces: "
+
     # call this multiple times if you had to take down components of the
     # USB subsystem by hand; it cleans up whatever can
     # be cleaned up, letting the system quiesce further.

@@ -125,6 +134,8 @@
 
     rmmod usbcore >/dev/null 2>&1
 
+    success ; echo
+
     # we did everything we could ...
     return 0;
 }

@@ -133,9 +144,11 @@
 case "$1" in
   start)
 	maybe_start_usb
+	touch /var/log/subsys/hotplug
         ;;
   stop)
 	maybe_stop_usb
+	rm -f /var/log/subsys/hotplug
         ;;
   status)
 	echo USB Status for kernel:  `uname -srm`

MandrakeSoft Inc                     http://www.chmouel.org
                      --Chmouel

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

Chmouel,

Your first comment applies to a different script:

That's there to ensure that every hotpluggable subsystem can be sure it's properly initialized. That same sort of structure is used with runlevel-specific services; so it's very standard.

The thing I dislike about using "chkconfig" style hooks into system booting is that hotplug init shouldn't really have anything to
do with runlevel changes. Hardware on a hotpluggable bus will
be there regardless of system runlevel; so it should always be usable. If you know of a cleaner (and distro-independent!) way to get it all initted (and have it stay that way), I'd like to hear about it.

What would break, how? And why wouldn't that be a bug in that hotpluggable subsystem (to be fixed!), rather than a structural problem?

Your other points relate specifically to the "usb.rc", used to bring USB up/down:

Right. STATIC_MODULE_LIST is for cases where a sysadmin wants some modules in place -- like the X11_MOUSE_HACK, needed to let at least some versions of X11 use /dev/input/mice for USB mice.

I don't use that a lot lately; /dev/input/mice stopped working for my PS/2 mice several kernels back, so I can't.

You mean the host controller drivers (HCDs), I take it?

That's stuff I'd rather see driven by PCI hotplugging, for what it's worth. USB initialization should ideally be triggered by which host controllers are present (OHCI, UHCI, EHCI), with "usb.rc start" getting called after one of those HCDs is loaded ... rather than calling "rc.usb start" in expectation that some HCD is there.

Those would be unreported/unfixed bugs in USB host controller drivers. I've never seen such things except when when I use expermental patches. (Like some 2.3.x kernels ... ;-)

Sort of essential to bring down USB so new modules can be installed and used, though. If you have a clean solution that doesn't involve MSFT-style rebooting, I'd like to hear about it.