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 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).