From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Date: Fri, 05 Oct 2001 08:09:16 +0000 Subject: Re: Unloading drivers, start-up, shut-down and some clean-ups Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org > Hello everybody. I have the 2001_04_24 release of the hotplug scripts. > I figured it would be good to be able to automatically unload drivers > too so I did some work on the subject. Unfortunately, it _wasn't_ as > simple as implementing the "remove" event in the policy agents and so > that makes it a _lot_ of work on the subject. :-) It was waiting for volunteers ... we seem to have a few now! :) Presumably you'll provide a version against the current release? > My idea is to put the functonality of the ".rc" boot scripts in the > ".agent" scripts and have a central subsystem which triggers all others > (via devices of it) at startup and shutdown -- creating a hierarchy this > way. This means adding "start" and "stop" events and getting rid of > "/etc/hotplug/*.rc" scripts. The "rc" scripts were most handy for addressing the "coldplug" case, supporting subsystem-specific startup/shutdown. I'm sure you noticed there was a bunch of USB-specific stuff crying out for better homes. > An example is that a PCI device (the host > controller) is what "enables" the USB subsystem (or a part of it in the > case of multiple controlers). So it goes for all other cases as long as > the hotplug scripts are dealing only with hardware devices. This way the > subsystems will be "started" and "stopped" in an order which is more > appropriate than the current lexical order. Right. I forget why I never implemented that; likely it was just a lack of time to refactor things. There should certainly be scripts that make the USB subsystem start up when PCI hotplugs a USB controller. > My suggestion is also to have driver-specific "*.agent" (instead of just > "*" scripts:-)) scripts which will be called _in place_ of (and not in > addition to) modprobe (of course, they will call modprobe themselves if > necessary). > - This makes it possible for scripts to do their stuff before and/or > after "modprobe"ing. > - It also eliminates the need for a blacklist (you (or a package) can > simply add empty agents) If there's no such agent, there needs to be a default behavior. Most driver developers should never need to write those scripts, they certainly would view such a requirement as a bug. And the default behavior for network drivers needs to be a bit sensitive to what distro it's running on. It'd be nasty to need to have N distro's worth of scripts for M drivers = NxM... But otherwise a "*.agent" that's more flexible seems like a fine update. > - It completes the previous hierarchical design which I was talking > about. "uhci.agent" for example can "start" the USB subsystem when "added" . Except that there still needs to be some common place for generic USB setup, shared by all the host controllers (uhci, ohci, ehci, and sometimes non-pci ones). And as a USB developer I do want to be able to start and stop the USB subsystem by itself... > - The driver-specific *.agent files can be enumerated very simply (with > this glob). > - The driver-specific policy agents can have their own homes and invite > friends and relatives as well... :-) I mean that each driver-specific > agent can have its own driver-specific subdirectory (just like each > subsystem-specific agent can have its own subsystem-specific subdirectory). Also good. > - Aside the previous, each driver (and this is the most useful part) can > have its own .usbmap (or .pcimap or similar) in the subsystem-specific > directory. This *.usbmap (as an example) file should be parsed as well > by usbmodules. This makes usb.handmap, usb.usermap and similar files > unnecessary. I'd say it mostly moves them around, rather than making them become unnecessary. Generalizing is good. > Another thing is that the individual policy agents should be separated > from each other (/etc/hotplug/hotplug.functions is ugly :-)) and thus > should have very few common parts. That's because future hotplug agents > might not be only (or at all) for (un)loading kernel modules for > hardware devices and they just can't ignore any common functions (like > driver-loading functions or so) that are given to them. Now, that may > sound bad since it means duplicating a couple of lines of script but I'm > playing safe :-)... That's something I'll disagree with -- duplicating lines of code is something I've usually found to be more dangerous than having one master copy. Bugs and features need to stay in sync. > Here's a file layout: > - Anything matching /etc/hotplug* is hotplug specific > - Anything matching /etc/hotplug/xxx* is xxx-subsystem-specific. > - Anything matching /etc/hotplug/xxx/yyy* is yyy-driver-specific. As it is today -- except /etc/hotplug/ is always a directory, there are no other /etc/hotplug* files. > Here's a uniform naming scheme: > - If * corresponds to nothing then it's a directory. > - If * corresponds to ".agent" then it's a script that processes hotplug > requests. > - If * corresponds to ".conf" then it's sourced from the corresponding > .agent script and related ones. Sounds reasonable. Would the "*conf" files be where distro-specific magic happens? That's a big issue; it'd be good to have nice clean places to hang customization for Debian/RedHat/SuSE/etc and their config policies. - Dave _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel