From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Thu, 25 Dec 2003 00:19:14 +0000 Subject: Re: Possible udev bug and some questions 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 On Thu, Dec 25, 2003 at 12:25:22AM +0200, Martin Schlemmer wrote: > Hi > > I know its not good form to post so many issues in one, but I > am currently on dialup, and not for more than a few hours. Also > please CC me, as I am not on this list. > > 1) if you look at the following code in namedev.c (in > function do_callout()): > > -- > if (sysfs_device) { > dbg("dev->bus='%s' sysfs_device->bus='%s'", > dev->bus, sysfs_device->bus); > if (strcasecmp(dev->bus, sysfs_device->bus) !> 0) > continue; > > } > -- > > there is a slight problem - if sysfs_device = NULL, then the > 'strcasecmp(dev->bus, sysfs_device->bus) != 0' test will never > be evaluated, and result in the callout to run for all non-phisical (?) > devices. Ah, good catch. I've put a test in the udev-test.pl script to catch this bug, and added the following patch: --- a/namedev.c Wed Dec 24 16:09:18 2003 +++ b/namedev.c Wed Dec 24 16:09:18 2003 @@ -399,7 +399,10 @@ if (dev->type != CALLOUT) continue; - if (sysfs_device) { + if (dev->bus[0] != '\0') { + /* as the user specified a bus, we must match it up */ + if (!sysfs_device) + continue; dbg("dev->bus='%s' sysfs_device->bus='%s'", dev->bus, sysfs_device->bus); if (strcasecmp(dev->bus, sysfs_device->bus) != 0) continue; I also made the BUS key optional for the CALLOUT rule. If the BUS value is not present, then the CALLOUT rule is always called. Does this work for you? > 2) If I understand the udev manual correct, all 'methods' should have a > suitable 'key'. If I now look again at namedev.c, then whenever we > work with a non-phisical (?) (or not attached to a phisical bus?) > device, then non of the 'keys' used with 'methods' are available, as > get_sysfs_device() fails. Should any of the 'methods' then be run? > Or more to the code, should any of the do_* (do_callout, etc) functions > then be called for a device for which get_sysfs_device() failed? Yeah, I've been thinking about this too. There are a lot of devices in sysfs that do not have a "device" symlink right now (for one reason or another...) When the device symlink is present, we can get a lot more information about the device, and use it in udev. Right now, if we can not find a sysfs_device, we can still run most of the rules. LABEL works, CALLOUT now works, NUMBER makes no sense at all without a sysfs_device and does not work. Same thing for TOPOLOGY. Then REPLACE works too. So without that link, we do the best that we can. Is there something about the way devices without a sysfs_device works in udev today that you do not like (except for the above bug...) > 4) Is there any reason why only one 'method' (meaning only one of the > callouts I may have for ide devices - I may want to use both the > ide-devfs.sh and ide-devfs-compat.sh to have multiple symlinks for on > device ...) is done for each device and/or hotplug event (beside lack > of time to implement) ? Same for why only 'type' of 'method' is done > for each (if a CALLOUT is done, the rest is skipped) ? We stop comparing when we find the first rule that succeeds. Otherwise how are we going to handle "catchall rules"? I don't want to have to come up with a situation of weighting rules, and if more than one matches, determing what needs to be done (both, none, one, etc.) If you want to call two callout scripts, just make a new script that calls them both :) > 5) I use a devfs-less setup with udev, 2.6.0 kernel with most of the > sysfs patches from Greg, if not all, and a pre 2.3.3 glibc. Also > have devpts compiled in, and mounted to /dev/pts. I now have the > following 'w' output: Are you using udev to manage your /dev tree? 'w' works for me without using udev to manage my /dev tree. Try that to see if it's a udev issue or not. thanks, greg k-h ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click _______________________________________________ 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