linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: general hotplug/udev questions
Date: Fri, 19 Aug 2005 17:18:46 +0000	[thread overview]
Message-ID: <20050819171846.GA22030@vrfy.org> (raw)
In-Reply-To: <1124394814.4483.46.camel@rich>

On Fri, Aug 19, 2005 at 10:11:16AM -0700, Greg KH wrote:
> On Fri, Aug 19, 2005 at 06:56:47PM +0200, Kay Sievers wrote:
> > On Fri, Aug 19, 2005 at 09:47:59AM -0700, Greg KH wrote:
> > > On Fri, Aug 19, 2005 at 10:33:02PM +0600, Alexander E. Patrakov wrote:
> > > > Greg KH wrote:
> > > > 
> > > > >On Fri, Aug 19, 2005 at 03:09:59PM +0600, Alexander E. Patrakov wrote:
> > > > > 
> > > > >
> > > > >>Do I understand correctly that the "crawl through sysfs" approach means 
> > > > >>bus-specific conversion between sysfs contents (e.g the fact that 
> > > > >>/sys/bus/usb/devices/1-1/idProduct contains "4002" here) and environment 
> > > > >>variables (in this case, PRODUCT=...)?
> > > > >>   
> > > > >>
> > > > >
> > > > >Yes, but it's a world easier now that we have added the 'modalias' sysfs
> > > > >files so we don't have to reconstruct anything.  All we care about at
> > > > >coldplug time is loading the modules and creating existing device nodes.
> > > > > 
> > > > >
> > > > Sorry, no. We should also care about providing some hook for packages 
> > > > like SANE and gPhoto2 to chown/chmod pseudofiles in /proc/bus/usb. This 
> > > > requires perfect reconstruction of at least $PRODUCT and $DEVICE.
> > > 
> > > Like Kay said, /proc/bus/usb/???/ is now dead.  We have sane device nodes for
> > > those usbfs files now that udev can manipulate the permissions for
> > > properly.  Run the latest -mm trees to see this.
> > > 
> > > Kay, you have a libusb patch to support this, right?  Care to share it?
> > 
> > It requires this crazy udev rule:
> >   SUBSYSTEM="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev} B=$${X%%%%.*} D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK+="%c"
> 
> Ugh.  Is there any way we can change the kernel name of the class device
> to make this easier to handle?  Hm, probably not, unless I get subclass
> devices working real soon...

Not that I know. We could add regex support to udev to solve that
in-process. :)

> And do we need/want to care about the leading 0's like usbfs had?

Works fine without, but adding it with the shell should be easy, just
makes the rule a bit longer. :)

> > ###
> > Patch against libusb, to prepare for the upcoming changes in
> > the Linux usb core, which will create real device nodes in /dev
> > with udev. The following rule:
> >   SUBSYSTEM="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev} B=$${X%%%%.*} D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK="%c"
> > 
> > creates a similar structure in /dev as usbfs creates in /proc to
> > be picked up by libusb.
> > 
> > I've removed the fallback to /sys/bus/usb cause this is completely
> > wrong and can and will never work and /dev/usb is used differently
> > and will also not provide access to the raw usb devices.
> > 
> > Signed-off-by: Kay Sievers <kay.sievers@suse.de>
> > ---
> > 
> > diff -u -r1.73 linux.c
> > --- linux.c	1 Mar 2005 19:36:42 -0000	1.73
> > +++ linux.c	9 Aug 2005 00:06:43 -0000
> > @@ -636,11 +636,8 @@
> >      if (check_usb_vfs("/proc/bus/usb")) {
> >        strncpy(usb_path, "/proc/bus/usb", sizeof(usb_path) - 1);
> >        usb_path[sizeof(usb_path) - 1] = 0;
> > -    } else if (check_usb_vfs("/sys/bus/usb")) { /* 2.6 Kernel with sysfs */
> > -      strncpy(usb_path, "/sys/bus/usb", sizeof(usb_path) -1);
> > -      usb_path[sizeof(usb_path) - 1] = 0;
> > -    } else if (check_usb_vfs("/dev/usb")) {
> > -      strncpy(usb_path, "/dev/usb", sizeof(usb_path) - 1);
> > +    } else if (check_usb_vfs("/dev/bus/usb")) {
> > +      strncpy(usb_path, "/dev/bus/usb", sizeof(usb_path) -1);
> >        usb_path[sizeof(usb_path) - 1] = 0;
> >      } else
> >        usb_path[0] = 0;	/* No path, no USB support */
> 
> 
> Hm, why was libusb checking for sysfs stuff in the first place?  It
> couldn't do anything with those files, right?

No, it doesn't make sense. Seems someone was a bit confused about sysfs
and thought /proc/bus will move to /sys/bus :)

Kay


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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

  parent reply	other threads:[~2005-08-19 17:18 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-18 19:53 general hotplug/udev questions rich turner
2005-08-18 20:14 ` Greg KH
2005-08-18 20:49 ` Kay Sievers
2005-08-19  9:09 ` Alexander E. Patrakov
2005-08-19 11:10 ` Marco d'Itri
2005-08-19 16:23 ` Greg KH
2005-08-19 16:33 ` Alexander E. Patrakov
2005-08-19 16:35 ` Kay Sievers
2005-08-19 16:38 ` Marco d'Itri
2005-08-19 16:47 ` Greg KH
2005-08-19 16:56 ` Kay Sievers
2005-08-19 17:11 ` Greg KH
2005-08-19 17:18 ` Kay Sievers [this message]
2005-08-21  7:16 ` Alexander E. Patrakov
2005-08-24 19:43 ` 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=20050819171846.GA22030@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).