From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: udev doesn't know about devices further up the tree.
Date: Fri, 16 Jun 2006 08:57:10 +0000 [thread overview]
Message-ID: <1150448230.3243.9.camel@pim.off.vrfy.org> (raw)
In-Reply-To: <20060616080501.GG26715@paranoidfreak.co.uk>
On Fri, 2006-06-16 at 09:50 +0100, Simon Huggins wrote:
> On Fri, Jun 16, 2006 at 10:35:33AM +0200, Kay Sievers wrote:
> > On Fri, 2006-06-16 at 09:05 +0100, Simon Huggins wrote:
> > > I wrote my first udev rule the other day.
> > > It reads:
> > > KERNEL="sd*", PROGRAM="/home/huggie/bin/camera %k", SYMLINK+="%c"
> > > where bin/camera does:
> > > DEV=$1
> > > DISK=`echo $DEV|sed -e 's/.*\(sd.\).*/\1/;'`
> > > udevinfo -a -p /block/$DISK/$DEV|grep manuf|grep PENTAX >/dev/null 2>&1 && \
> > > echo camera && exit 0
> > > i.e. basically if the usb device (or any device because I'm not that
> > > fussy) above the block device is made by PENTAX then echo camera
> > > otherwise I just echo $DEV back again.
> > > But it strikes me as a bug that I have to spawn out of udevd to run
> > > udevinfo in order to just name the device based on what it is.
> > > Why aren't SYSFS attributes from higher up the device path available
> > > somehow when writing rules?
> > Adding a single SYSFS attribute:
> > SYSFS{vendor}="PENTAX"
> > or
> > SYSFS{manufacturer}="PENTAX"
>
> > should do it and will try to find the value on all devices up the chain,
> > but you can't mix SYSFS, BUS or ID values from different devices.
>
> Hmm, ok it's working now. I must have fucked up the rule somehow
> originally sorry for wasting your time.
>
> Can I suggest that the part in
> http://www.reactivated.net/writing_udev_rules.html
> which says:
>
> This is to demonstrate that you generally can not mix-and-match
> attributes from different sections of the udevinfo output - your
> rule will not work.
>
> be reworded or removed then. I'm not quite sure what it should say - I
> just failed and then read more of the docs and came across this and
> thought that what I was trying was never going to work.
>
> I now have:
> KERNEL="sd*", SUBSYSTEM="block", SYSFS{manufacturer}="PENTAX",
> SYMLINK+="camera"
> which appears to work fine yet the block and the PENTAX are indeed in
> different sections of the udevinfo output.
Right, I means, you can't mix attributes of different parent devices.
The attributes for the device itself, which "block" belongs to, will
always match. Say:
SYSFS{vendor}="PENTAX", SYSFS{manufacturer}="PENTAX"
would not match, even when both single keys are matching.
Kay
_______________________________________________
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
prev parent reply other threads:[~2006-06-16 8:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-16 8:05 udev doesn't know about devices further up the tree Simon Huggins
2006-06-16 8:35 ` Kay Sievers
2006-06-16 8:50 ` Simon Huggins
2006-06-16 8:57 ` Kay Sievers [this message]
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=1150448230.3243.9.camel@pim.off.vrfy.org \
--to=kay.sievers@vrfy.org \
--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).