From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stamatis Mitrofanis Date: Sat, 29 Dec 2001 01:37:22 +0000 Subject: Re: Is there a bug in hotplug.functions w/ ${TYPE}.usermap? 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 Heath Elwayne Petersen wrote: >I have been trying to use linux-hotplug to run a script when a device is >recognized. However, I have been running into a problem. It seams that >there may be an error in the hotplug.functions load_drivers function. >... >If this is the case, the error is that the find command does not return a >false return code when it fails to find the file. Therefore, the modprobe will always >be tried, and the following code, which attempts to execute >/etc/hotplug/$TYPE/$MODULE will never be executed. > To be honest, I find that load_driver part of the code ugly alltogether. More on that below... >OUTPUT OF: diff hotplug.functions.orig hotplug.functions >---- Cut Here ---- >128c128,129 >< elif find $MODULE_DIR -name $MODULE.o >/dev/null 2>&1 && >--- > >> elif find $MODULE_DIR -name $MODULE.o 2>&1 \ >> | grep -q . >/dev/null 2>&1 && >> >---- Cut Here ---- > Firstly, that `find' line is checking that belongs in modprobe. It's modprobe's job to see if a (abstract) "driver" is available. modprobe has aliases, null/none drivers etc. so it's high-level. If we're looking for a "module file" we sould be using insmod. The _command_ insmod. Even if it's the same executable as modprobe, it has different semantics. load_modules is ugly because: - code is not very unreadable (at least one error went unnoticed) - it has many story-telling FIXMEs in it for very long (so, it may have a bad architecture) It's the agent's job to map requests to drivers and modutil's job to load kernel modules. Using a load_driver function between these two is bad because it complicates things. Why is the requirement for either *modules or the function *_map_modules from load_driver when the mapping can be done by the agent (possibly by calling its helper program)? The agent can simply call modprobe which is definitely high-level-enough. modprobe itself checks whether a driver is already loaded. For agents that don't map drivers or don't work with kernel drivers at all (net, printer, xfree86) load_modules is of no use. For driver-specific processing it is (much) better to use scripts as /etc/hotplug/usb/xxx.agent . They should be called in place of (and not in addition to) modprobe so that there can be greater flexibility. (the agent script delegates to a driver script) I am working with David Brownell for a series of patches that will ease things in this area. I had already solved the problem by the time the previous message was posted! _______________________________________________ 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