From: Dave Hansen <haveblue@us.ibm.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: getting udev to work with USB combo drive
Date: Thu, 12 Feb 2004 05:45:41 +0000 [thread overview]
Message-ID: <1076564740.1221.256.camel@nighthawk> (raw)
In-Reply-To: <1076210508.1262.1332.camel@nighthawk>
On Wed, 2004-02-11 at 17:38, Greg KH wrote:
> On Sat, Feb 07, 2004 at 07:22:04PM -0800, Dave Hansen wrote:
> > I have a pretty stupid USB combo device that doesn't like to report very
> > detailed information about itself (For Google's sake, the drive is a
> > Vosonic X's Drive Pro VP-300):
> > SYSFS_vendor="USB "
> > SYSFS_model="USB "
> > SYSFS_rev="1.00"
> >
> > Despite that, SYSFS_serial looked good, so I decided to use it for
> > udev. The device has an internal hard disk, and 3 media slots, so I
> > laid out 3 entries like this:
> > SYSFS_serial="0123", ID="*:0", NAME="xdrive/disk%n"
> > SYSFS_serial="0123", ID="*:1", NAME="xdrive/cf%n"
> > SYSFS_serial="0123", ID="*:2", NAME="xdrive/sm%n"
> > SYSFS_serial="0123", ID="*:3", NAME="xdrive/xd%n"
> >
> > But, these rules never matched. The wildcard in the ID= field appears
> > to be ignored. Is that a bug?
>
> As Pat showed, this was never checked. With his patch, it should be
> now. Will that give you enough to match properly without needing your
> script?
It still doesn't work, but I don't think it's because of the wildcard
any more. I can actually see that rule match in the debug output.
How important is the order in which you specify your 'FOO="bar",' rules
in udev.rules? Don't you have to start with the specifications that are
lowest in the tree and work up from there? The "goto try_parent" is a
pop off the stack, and you don't ever get back down to the children.
Maybe I just missed this until now.
Also, I think I'm getting some garbage in the SYSFS_serial variable.
When I get down to the match_rule() area for SYSFS_serial="...", I get
some output in the debug log like this:
compare_sysfs_attribute: compare attribute 'serial' value '0A4110002CEA'
with 'HXOLL0012202323480'
But, I have no idea where HXOLL0012202323480 came from.
'grep -r HXOLL0012202323480 /sys' comes up with nothing.
Any ideas? Is that some memory garbage from somewhere?
--dave
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&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
next prev parent reply other threads:[~2004-02-12 5:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-08 3:22 getting udev to work with USB combo drive Dave Hansen
2004-02-12 1:38 ` Greg KH
2004-02-12 5:45 ` Dave Hansen [this message]
2004-02-12 17:45 ` Greg KH
2004-02-12 18:04 ` Dave Hansen
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=1076564740.1221.256.camel@nighthawk \
--to=haveblue@us.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.