mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kyle Moffett <mrmacman_g4@mac.com>
To: Greg KH <greg@kroah.com>
Cc: Patrick Mochel <mochel@digitalimplant.org>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] Updates to sysfs_create_subdir()
Date: Tue, 29 Nov 2005 01:41:01 -0500	[thread overview]
Message-ID: <B43BE39F-16A2-4BFE-A6AA-0F4439780F1C@mac.com> (raw)
In-Reply-To: <20051129054411.GB11013@kroah.com>

On Nov 29, 2005, at 00:44, Greg KH wrote:
> On Mon, Nov 28, 2005 at 08:10:36PM -0500, Kyle Moffett wrote:
>> If the kernel gets this, then udev needs to allow attributes with  
>> more generic paths too.  It would be nice if I could use this  
>> [Pulled from the sample udev output halfway down this page: http:// 
>> www.reactivated.net/writing_udev_rules.html#identify-sysfs].
>>
>> BUS="scsi", SYSFS{../../../manufacturer}="Tekom Technologies,  
>> Inc", NAME="my_camera"
>
> Why can't you do this today?  Have you tried it?

Hmm, no, I don't suppose I have.  I guess I was taking the udev docs  
and other similar pages at their word that you couldn't match things  
in multiple subdirs.  *tries*  Interesting; it appears to work, but  
it would be nice if it was documented somewhere; this is _really_  
handy for certain devices with partial or missing udev support.  (I  
can specify the 3rd proprietary tape drive in the changer even if the  
drives themselves don't have any useful SCSI info attached to them.)   
Thanks for pointing this out!

I do have one question, though.  Is there any way to access the  
"DEVICE" or "SUBSYSTEM" values of those parent sysfs nodes?  I can  
see that those are symlinks in sysfs to other sysfs dirs, so there's  
no real way to match them with SYSFS{*}, but I'm hoping that perhaps  
they could be extended to accept a path in {} brackets much as SYSFS 
{} does.  Thanks for the help!  And btw, here are the rules I've  
worked out for my PowerBook (I frequently tinker with the MAC address  
when doing odd networking hackery, so it's not so useful for matching  
purposes):

## The built-in ethernet
SUBSYSTEM="net", SYSFS{device/devspec}="/pci@f4000000/ethernet@f",  
NAME="net_eth"
## The built-in firewire (via eth1394)
SUBSYSTEM="net", SYSFS{device/../devspec}="/pci@f4000000/firewire@e",  
NAME="net_fw"

Cheers,
Kyle Moffett

--
Unix was not designed to stop people from doing stupid things,  
because that would also stop them from doing clever things.
   -- Doug Gwyn



  reply	other threads:[~2005-11-29  6:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-23 21:56 Patrick Mochel
2005-11-28 20:49 ` Greg KH
2005-11-29  1:10   ` Kyle Moffett
2005-11-29  5:44     ` Greg KH
2005-11-29  6:41       ` Kyle Moffett [this message]
2005-11-29  6:55         ` Greg KH
2005-11-30 17:05   ` Patrick Mochel
2005-11-30 22:11     ` Greg KH
2005-12-05  6:24     ` Maneesh Soni
2005-12-19 19:08       ` Patrick Mochel

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=B43BE39F-16A2-4BFE-A6AA-0F4439780F1C@mac.com \
    --to=mrmacman_g4@mac.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@digitalimplant.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

all inboxes | Powered by JetHome®