linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: Possible udev bug and some questions
Date: Thu, 25 Dec 2003 00:19:14 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-107231182612324@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-107230596809166@msgid-missing>

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_id\x1278&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

  reply	other threads:[~2003-12-25  0:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-24 22:25 Possible udev bug and some questions Martin Schlemmer
2003-12-25  0:19 ` Greg KH [this message]
2003-12-25  0:30 ` Greg KH
2003-12-25 10:06 ` Kay Sievers
2003-12-25 18:59 ` Martin Schlemmer
2003-12-25 19:32 ` Kay Sievers
2003-12-25 20:00 ` Kay Sievers
2003-12-25 21:04 ` Kay Sievers
2003-12-25 21:26 ` Kay Sievers
2003-12-25 22:58 ` Kay Sievers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-hotplug-107231182612324@msgid-missing \
    --to=greg@kroah.com \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).