usb.rc script

usb.rc script

[Chmouel Boudjnah]

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 :

--- usb.rc.chmou	Wed Jan 17 07:15:02 2001
+++ usb.rc	Wed Jan 17 11:14:36 2001
@@ -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
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: usb.rc script

[David Brownell]

Chmouel,

Your first comment applies to a different script:

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

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.

> and could break things..

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:

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

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.


> 3- Same for the interfaces, you load the interfaces when is not Admin
> level configurable

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.


>     (sometime when usb-(uhci|ohci) load it could freeze
> the box.

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


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

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.


> Nerveless here is a small patch that bring some RH/MDK things, add the
> action/sucess/failure process and inform the subsys system :
> 
> --- usb.rc.chmou Wed Jan 17 07:15:02 2001
> +++ usb.rc Wed Jan 17 11:14:36 2001
> @@ -30,6 +30,7 @@
>      # e.g. USBD_ENABLEúlse but STATIC_MODULE_LIST has your devices
>  fi
>  
> +. /etc/rc.d/init.d/functions

How much of a RedHat-ish dependency is this, though?  Right now the only
one I know about is the /etc/rc.d/init.d/hotplug script, which uses
chkconfig ... this patch would make much more stuff depend on running
a RedHat-derived distro, maybe stranding users of other distros.


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

There are cases where things will still be running though.

For example, usermode programs (daemons etc) using usbdevfs
aren't guaranteed to have exited, so usbcore will still be
loaded and it's inappropriate to report "success".


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

But this file is for the USB subsystem, not for hotplugging
as a whole ... PCI and network hotplugging aren't affected
by this particular script, and neither will other subsystems
as they handle hotplugging.

I think you mean /var/lock/subsys ... will those exist on
distros that aren't derived from RedHat?  Seems like this
should be in the /etc/rc.d/init.d/hotplug script instead.

- Dave





_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel