From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Wed, 17 Jan 2001 16:42:58 +0000 Subject: Re: usb.rc script Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org 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,=20 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 : >=20 > --- 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=FAlse but STATIC_MODULE_LIST has your devices > fi > =20 > +. /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 @@ > =20 > rmmod usbcore >/dev/null 2>&1 > =20 > + 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