Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Aurelien Jarno]

On Wed, Jan 25, 2006 at 09:37:09PM +0100, Linus Walleij wrote:
> Having fun making packages for Fedora we have run into a coordination 
> issue between udev and libusb.
> 
> As you know libusb programs (like SANE custom USB backends or my own pet 
> libnjb) use raw device nodes with no kernel drivers attached to them. A 
> suitable udev rule found in this mail:
> 
> http://sourceforge.net/mailarchive/message.php?msg_id\x12695893
> 
> looks like this:
> 
> SUBSYSTEM="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev} 
> B=$${X%%%%.*}
> D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK="%c"
> 
> has been applied to most distributions set of default rules. (Well Debian 
> and Fedora atleast, I guess SuSE too.)

Wrong! Debian uses the following rule:

# usbfs-like devices
SUBSYSTEM="usb_device",	PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", \
				NAME="%c"

with the following patch to libusb to open /dev/bus/usb prior to
/proc/bus/usb:

--- libusb-0.1.11.orig/linux.c
+++ libusb-0.1.11/linux.c
@@ -633,14 +633,11 @@
   }
 
   if (!usb_path[0]) {
-    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);
+    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 if (check_usb_vfs("/dev/usb")) {
-      strncpy(usb_path, "/dev/usb", sizeof(usb_path) - 1);
+    } else 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
       usb_path[0] = 0;	/* No path, no USB support */



> This rule creates a dynamic device hierarchy belowe /dev/bus/usb similar 
> to the good 'ol /proc/bus/usb and everyone is happy. Libusb was patched 
> to support this device hierarchy. But wait. We found an inconsistency: 
> that script will create hex-named nodes:
> 
>   /dev/bus/usb/01AB1/01BCF

On Debian, the names are in the form /dev/bus/usb/002/004, ie the same
format as in /proc/bus/usb.
 
> But we need a clear rationale:
> 
> * How shall /dev/bus/usb subdirs and device files be named?

As those names are exported to the application (via usb_bus.dirname and 
usb_device.filename), they should be named exactly the same way as in 
/proc/bus/usb to keep the compatibility. Otherwise, it would break some
applications.

Debian have used the /dev/bus/usb/%%i/%%i format (ie something like
/dev/bus/usb/2/4), and it brokes some applications like openct.

> * If they shall be all decimal figures, change all rules accordingly and
>   libusb will work fine as it is.

IMHO, this is the way to go.

> * If they shall be hex, make the above suggested change to libusb.

In such case, the API of libusb should be changed to also export the
full name of the device node, so that application can use them directly
instead of using usb_bus.dirname and usb_device.filename).

Bye,
Aurelien

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Linus Walleij]

On Thu, 26 Jan 2006, Aurelien Jarno wrote:

> Wrong! Debian uses the following rule:

Ah you already found the problem. Mea culpa...

Then this other thing:

> with the following patch to libusb to open /dev/bus/usb prior to
> /proc/bus/usb:
>
> --- libusb-0.1.11.orig/linux.c
> +++ libusb-0.1.11/linux.c
> @@ -633,14 +633,11 @@
>   }
>
>   if (!usb_path[0]) {
> -    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);
> +    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 if (check_usb_vfs("/dev/usb")) {
> -      strncpy(usb_path, "/dev/usb", sizeof(usb_path) - 1);
> +    } else 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
>       usb_path[0] = 0;	/* No path, no USB support */
>
> (...)
>
> On Debian, the names are in the form /dev/bus/usb/002/004, ie the same
> format as in /proc/bus/usb.

This is good and seems to be the current rationale. Kay also use 
/dev/bus/usb.

Could this patch be applied to libusb so we confirm this choice of using 
/dev/bus/usb instead of just /dev/usb as the source says right now?

Linus


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Johannes Erdfelt]

On Wed, Jan 25, 2006, Linus Walleij <triad@df.lth.se> wrote:
> Having fun making packages for Fedora we have run into a coordination 
> issue between udev and libusb.
> 
> As you know libusb programs (like SANE custom USB backends or my own pet 
> libnjb) use raw device nodes with no kernel drivers attached to them. A 
> suitable udev rule found in this mail:
> 
> http://sourceforge.net/mailarchive/message.php?msg_id\x12695893
> 
> looks like this:
> 
> SUBSYSTEM="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev} 
> B=$${X%%%%.*}
> D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK="%c"
> 
> has been applied to most distributions set of default rules. (Well Debian 
> and Fedora atleast, I guess SuSE too.)
> 
> This rule creates a dynamic device hierarchy belowe /dev/bus/usb similar 
> to the good 'ol /proc/bus/usb and everyone is happy. Libusb was patched 
> to support this device hierarchy. But wait. We found an inconsistency: 
> that script will create hex-named nodes:
> 
>   /dev/bus/usb/01AB1/01BCF
> 
> However libusb has this code in linux.c row 336 or so:
> 
>   if (!strchr("0123456789", entry->d_name[strlen(entry->d_name) - 1]))
> 
> Of course it could be fixed with a patch:
> 
>   if (!strchr("0123456789ABCDEF", entry->d_name[strlen(entry->d_name) - 1]))
> 
> But we need a clear rationale:
> 
> * How shall /dev/bus/usb subdirs and device files be named?
> 
> * If they shall be all decimal figures, change all rules accordingly and
>   libusb will work fine as it is.
> 
> * If they shall be hex, make the above suggested change to libusb.

Coming in late to this thread and I see that the node has been changed
from hexadecimal to decimal.

I want to understand the reason for these device nodes since they seem
to duplicate the nodes found in /proc/bus/usb. Is this just part of the
long term plans to remove usbdevfs?

JE



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Kay Sievers]

On Thu, Jan 26, 2006 at 06:08:11PM -0800, Johannes Erdfelt wrote:
> On Wed, Jan 25, 2006, Linus Walleij <triad@df.lth.se> wrote:
> > Having fun making packages for Fedora we have run into a coordination 
> > issue between udev and libusb.
> > 
> > As you know libusb programs (like SANE custom USB backends or my own pet 
> > libnjb) use raw device nodes with no kernel drivers attached to them. A 
> > suitable udev rule found in this mail:
> > 
> > http://sourceforge.net/mailarchive/message.php?msg_id\x12695893
> > 
> > looks like this:
> > 
> > SUBSYSTEM="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev} 
> > B=$${X%%%%.*}
> > D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK="%c"
> > 
> > has been applied to most distributions set of default rules. (Well Debian 
> > and Fedora atleast, I guess SuSE too.)
> > 
> > This rule creates a dynamic device hierarchy belowe /dev/bus/usb similar 
> > to the good 'ol /proc/bus/usb and everyone is happy. Libusb was patched 
> > to support this device hierarchy. But wait. We found an inconsistency: 
> > that script will create hex-named nodes:
> > 
> >   /dev/bus/usb/01AB1/01BCF
> > 
> > However libusb has this code in linux.c row 336 or so:
> > 
> >   if (!strchr("0123456789", entry->d_name[strlen(entry->d_name) - 1]))
> > 
> > Of course it could be fixed with a patch:
> > 
> >   if (!strchr("0123456789ABCDEF", entry->d_name[strlen(entry->d_name) - 1]))
> > 
> > But we need a clear rationale:
> > 
> > * How shall /dev/bus/usb subdirs and device files be named?
> > 
> > * If they shall be all decimal figures, change all rules accordingly and
> >   libusb will work fine as it is.
> > 
> > * If they shall be hex, make the above suggested change to libusb.
> 
> Coming in late to this thread and I see that the node has been changed
> from hexadecimal to decimal.

Well, they never have been hex. I expect its a "bug" in some shell, I've
never seen this or can reproduce it, even with the old version of the rule
that seems to produce this for some people.

> I want to understand the reason for these device nodes since they seem
> to duplicate the nodes found in /proc/bus/usb. Is this just part of the
> long term plans to remove usbdevfs?

Yes, we want to leave /proc with all stuff that isn't process related.
And as all the major distros depend on udev and have /dev on tmpfs, having
usb devices in /proc makes no sense anymore.

We also want the option to apply access control lists to device nodes,
to allow a set of users (fast-user-switching) access to a device and
this would not work with /proc files, which can only have primary
ownership.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Greg KH]

On Thu, Jan 26, 2006 at 06:08:11PM -0800, Johannes Erdfelt wrote:
> 
> Coming in late to this thread and I see that the node has been changed
> from hexadecimal to decimal.

It should have always been in decimal, as that is what usbfs does.

> I want to understand the reason for these device nodes since they seem
> to duplicate the nodes found in /proc/bus/usb. Is this just part of the
> long term plans to remove usbdevfs?

They duplicate those nodes identically.  But now we can use udev and pam
and other tools to properly set the permissions and acls on the nodes.
Much easier than doing it through usbfs mount permissions, which only
work for all usbfs devices.

If you look at the suse kernel, it disables the creation of those files
in usbfs completly, relying on these device nodes instead.

Hope this helps explain things.

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Johannes Erdfelt]

On Fri, Jan 27, 2006, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Thu, Jan 26, 2006 at 06:08:11PM -0800, Johannes Erdfelt wrote:
> > I want to understand the reason for these device nodes since they seem
> > to duplicate the nodes found in /proc/bus/usb. Is this just part of the
> > long term plans to remove usbdevfs?
> 
> Yes, we want to leave /proc with all stuff that isn't process related.
> And as all the major distros depend on udev and have /dev on tmpfs, having
> usb devices in /proc makes no sense anymore.
> 
> We also want the option to apply access control lists to device nodes,
> to allow a set of users (fast-user-switching) access to a device and
> this would not work with /proc files, which can only have primary
> ownership.

Ahh, sounds great. I've checked in the change to CVS. It will only check
/dev/bus/usb and /proc/bus/usb now, in that order.

I haven't seen any of the conversations about this, but what will happen
to /proc/bus/usb/devices?

Unrelated, but I may make a 0.1.12 release sometime soon because there
have been a surprising amount of changes since 0.1.11 was released.

JE



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Kay Sievers]

On Thu, Jan 26, 2006 at 06:26:15PM -0800, Johannes Erdfelt wrote:
> On Fri, Jan 27, 2006, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > On Thu, Jan 26, 2006 at 06:08:11PM -0800, Johannes Erdfelt wrote:
> > > I want to understand the reason for these device nodes since they seem
> > > to duplicate the nodes found in /proc/bus/usb. Is this just part of the
> > > long term plans to remove usbdevfs?
> > 
> > Yes, we want to leave /proc with all stuff that isn't process related.
> > And as all the major distros depend on udev and have /dev on tmpfs, having
> > usb devices in /proc makes no sense anymore.
> > 
> > We also want the option to apply access control lists to device nodes,
> > to allow a set of users (fast-user-switching) access to a device and
> > this would not work with /proc files, which can only have primary
> > ownership.
> 
> Ahh, sounds great. I've checked in the change to CVS. It will only check
> /dev/bus/usb and /proc/bus/usb now, in that order.

Sounds good.

> I haven't seen any of the conversations about this,

There are no real discussions about. It just "happened" as I stumbled
across the lack of ACL support while thinking about a possible successor
for Red Hat's pam_console and SUSE's resmgr, that should become a common
service for granting access rights on Linux instead of the distro
specific mess we currently fighting against.

> but what will happen to /proc/bus/usb/devices?

It needs to be mounted to be active, so the option to use it is still there.
For SUSE we just leave it enabled in the kernel for now but don't mount it.
So users that depend on the /proc nodes, for whatever reason, can just mount
it and get the old behavior.

Our libusb patch first looks for /proc, but the other way around like you
checked into CVS is fine too, cause it's just one udev rule that need to be
commented out then to switch the behavior.

After a while we will know what needs to be fixed and then when we can remove
usbdevfs entirely from the kernel.

> Unrelated, but I may make a 0.1.12 release sometime soon because there
> have been a surprising amount of changes since 0.1.11 was released.

Nice. Thanks!

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Greg KH]

On Fri, Jan 27, 2006 at 04:01:43AM +0100, Kay Sievers wrote:
> 
> After a while we will know what needs to be fixed and then when we can remove
> usbdevfs entirely from the kernel.

Well no, code behind the base usbfs code is what still controls these
/dev nodes, be them accessed through the usbfs file, or through the /dev
node, so that stuff can't be deleted.  No matter how much some of us
hate that interface :)

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Charles Lepple]

On 1/26/06, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Thu, Jan 26, 2006 at 06:26:15PM -0800, Johannes Erdfelt wrote:
> > but what will happen to /proc/bus/usb/devices?
>
> It needs to be mounted to be active, so the option to use it is still there.
> For SUSE we just leave it enabled in the kernel for now but don't mount it.
> So users that depend on the /proc nodes, for whatever reason, can just mount
> it and get the old behavior.

Is there a plan for a successor to /proc/bus/usb/devices (that file
itself, not the /proc/bus/usb/012/345 nodes)?

If I am not mistaken, the 'devices' file allows ordinary users to
fetch the manufacturer, product and serial strings - without needing
to open the individual device nodes in read-write mode, and issue
requests to fetch those particular string descriptors.

--
- Charles Lepple


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Kay Sievers]

On Thu, Jan 26, 2006 at 07:17:07PM -0800, Greg KH wrote:
> On Fri, Jan 27, 2006 at 04:01:43AM +0100, Kay Sievers wrote:
> > 
> > After a while we will know what needs to be fixed and then when we can remove
> > usbdevfs entirely from the kernel.
> 
> Well no, code behind the base usbfs code is what still controls these
> /dev nodes, be them accessed through the usbfs file, or through the /dev
> node, so that stuff can't be deleted.  No matter how much some of us
> hate that interface :)

Well, CONFIG_USB_DEVICEFS can go at some point and no file will remain
in /proc. And if I remember correctly drivers/usb/core/{inode.c,devices.c}
are not needed for the /dev nodes to be functional, right?

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Kay Sievers]

On Thu, Jan 26, 2006 at 10:38:13PM -0500, Charles Lepple wrote:
> On 1/26/06, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > On Thu, Jan 26, 2006 at 06:26:15PM -0800, Johannes Erdfelt wrote:
> > > but what will happen to /proc/bus/usb/devices?
> >
> > It needs to be mounted to be active, so the option to use it is still there.
> > For SUSE we just leave it enabled in the kernel for now but don't mount it.
> > So users that depend on the /proc nodes, for whatever reason, can just mount
> > it and get the old behavior.
> 
> Is there a plan for a successor to /proc/bus/usb/devices (that file
> itself, not the /proc/bus/usb/012/345 nodes)?
> 
> If I am not mistaken, the 'devices' file allows ordinary users to
> fetch the manufacturer, product and serial strings - without needing
> to open the individual device nodes in read-write mode, and issue
> requests to fetch those particular string descriptors.

These informations are all available in sysfs.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 27 January 2006 06:38, Charles Lepple wrote:
> Is there a plan for a successor to /proc/bus/usb/devices (that file
> itself, not the /proc/bus/usb/012/345 nodes)?
>
> If I am not mistaken, the 'devices' file allows ordinary users to
> fetch the manufacturer, product and serial strings - without needing
> to open the individual device nodes in read-write mode, and issue
> requests to fetch those particular string descriptors.
>

Does sysfs miss any information contained in /proc/bus/usb/devices?

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD2ZsmR6LMutpd94wRAt8DAJ9b/4U+aeRYnbrlJ58oJV85o2H9vgCgwth7
3FvEOIx+M4OCp7mY04rf/Jg=m5Uo
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 27 January 2006 05:25, Greg KH wrote:
> > I want to understand the reason for these device nodes since they seem
> > to duplicate the nodes found in /proc/bus/usb. Is this just part of the
> > long term plans to remove usbdevfs?
>
> They duplicate those nodes identically.  But now we can use udev and pam
> and other tools to properly set the permissions and acls on the nodes.
> Much easier than doing it through usbfs mount permissions, which only
> work for all usbfs devices.
>

Does Mandrake have patched kernel procfs?

{pts/1}% LC_ALL=C ll /proc/bus/usb/001
total 0
- -rw-rw----  1 bor usb 43 Jan 27 06:40 001

they have been PAM-controlled as long as I remember. Not that I advocate 
keeping them (I do not care as long as higher-level tools work), just 
curious.

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD2ZvzR6LMutpd94wRApEfAJ0Xlt05i1yFrfOOowHkIXV6Lb5J8wCeL4iy
yKdFwRCgkiqIUJ61wCycOv4=oexA
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Kay Sievers]

On Fri, Jan 27, 2006 at 07:05:06AM +0300, Andrey Borzenkov wrote:
> On Friday 27 January 2006 05:25, Greg KH wrote:
> > > I want to understand the reason for these device nodes since they seem
> > > to duplicate the nodes found in /proc/bus/usb. Is this just part of the
> > > long term plans to remove usbdevfs?
> >
> > They duplicate those nodes identically.  But now we can use udev and pam
> > and other tools to properly set the permissions and acls on the nodes.
> > Much easier than doing it through usbfs mount permissions, which only
> > work for all usbfs devices.
> >
> 
> Does Mandrake have patched kernel procfs?
> 
> {pts/1}% LC_ALL=C ll /proc/bus/usb/001
> total 0
> -rw-rw----  1 bor usb 43 Jan 27 06:40 001
> 
> they have been PAM-controlled as long as I remember. Not that I advocate 
> keeping them (I do not care as long as higher-level tools work), just 
> curious.

Sure, primary ownership works as usual. We meant Access Control Lists,
for multiple users at the same time, which are nice if you use
fast-user-switching or have multi-head setups.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Greg KH]

On Fri, Jan 27, 2006 at 07:05:06AM +0300, Andrey Borzenkov wrote:
> On Friday 27 January 2006 05:25, Greg KH wrote:
> > > I want to understand the reason for these device nodes since they seem
> > > to duplicate the nodes found in /proc/bus/usb. Is this just part of the
> > > long term plans to remove usbdevfs?
> >
> > They duplicate those nodes identically.  But now we can use udev and pam
> > and other tools to properly set the permissions and acls on the nodes.
> > Much easier than doing it through usbfs mount permissions, which only
> > work for all usbfs devices.
> >
> 
> Does Mandrake have patched kernel procfs?
> 
> {pts/1}% LC_ALL=C ll /proc/bus/usb/001
> total 0
> -rw-rw----  1 bor usb 43 Jan 27 06:40 001
> 
> they have been PAM-controlled as long as I remember. Not that I advocate 
> keeping them (I do not care as long as higher-level tools work), just 
> curious.

Like I said above, "acls" are what we want too...

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Greg KH]

On Fri, Jan 27, 2006 at 04:51:31AM +0100, Kay Sievers wrote:
> On Thu, Jan 26, 2006 at 07:17:07PM -0800, Greg KH wrote:
> > On Fri, Jan 27, 2006 at 04:01:43AM +0100, Kay Sievers wrote:
> > > 
> > > After a while we will know what needs to be fixed and then when we can remove
> > > usbdevfs entirely from the kernel.
> > 
> > Well no, code behind the base usbfs code is what still controls these
> > /dev nodes, be them accessed through the usbfs file, or through the /dev
> > node, so that stuff can't be deleted.  No matter how much some of us
> > hate that interface :)
> 
> Well, CONFIG_USB_DEVICEFS can go at some point and no file will remain
> in /proc.

Yes, that's because you already changed the Makefile :)

> And if I remember correctly drivers/usb/core/{inode.c,devices.c} are
> not needed for the /dev nodes to be functional, right?

Yes, that is correct.  But the real nasty usbfs logic that everyone
hates is the devio.c file.  inode.c and devices.c are dirt simple now,
and don't take up much space, or have people cursing their $DIETY when
they have to go track down an issue in them...

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Greg KH]

On Fri, Jan 27, 2006 at 07:01:41AM +0300, Andrey Borzenkov wrote:
> On Friday 27 January 2006 06:38, Charles Lepple wrote:
> > Is there a plan for a successor to /proc/bus/usb/devices (that file
> > itself, not the /proc/bus/usb/012/345 nodes)?
> >
> > If I am not mistaken, the 'devices' file allows ordinary users to
> > fetch the manufacturer, product and serial strings - without needing
> > to open the individual device nodes in read-write mode, and issue
> > requests to fetch those particular string descriptors.
> >
> 
> Does sysfs miss any information contained in /proc/bus/usb/devices?

Yes it does, configurations that are not enabled.  I need to just add a
flag to 'lsusb' to provide this "condensed" information dump that the
devices file provides and then we will be able to drop it successfully.

Although it will be a long time before it happens, as there are some odd
userspace programs out there that parse this file to get information
(print drivers included...)

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Linus Walleij]

On Thu, 26 Jan 2006, Johannes Erdfelt wrote:

> Ahh, sounds great. I've checked in the change to CVS. It will only check
> /dev/bus/usb and /proc/bus/usb now, in that order.

Thanks Johannes!

Linus


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Olivier Blin]

Kay Sievers <kay.sievers@vrfy.org> writes:

> On Fri, Jan 27, 2006 at 07:05:06AM +0300, Andrey Borzenkov wrote:
>> On Friday 27 January 2006 05:25, Greg KH wrote:
>> > > I want to understand the reason for these device nodes since they seem
>> > > to duplicate the nodes found in /proc/bus/usb. Is this just part of the
>> > > long term plans to remove usbdevfs?
>> >
>> > They duplicate those nodes identically.  But now we can use udev and pam
>> > and other tools to properly set the permissions and acls on the nodes.
>> > Much easier than doing it through usbfs mount permissions, which only
>> > work for all usbfs devices.
>> >
>> 
>> Does Mandrake have patched kernel procfs?

Not AFAIK, and we don't need that to modify owners in /proc
See our list of patches here:
https://cvs.mandriva.com/svn/mdv/cooker/kernel-2.6/current/PATCHES/patches/

>> they have been PAM-controlled as long as I remember. Not that I advocate 
>> keeping them (I do not care as long as higher-level tools work), just 
>> curious.
>
> Sure, primary ownership works as usual. We meant Access Control Lists,
> for multiple users at the same time, which are nice if you use
> fast-user-switching or have multi-head setups.

Couldn't we use dynamic groups instead of ACLs?
This would avoid running a tool to update ACLs at each device "add",
and require group updates only at user login/logout.

By the way, some pointers about the ACLs on tmpfs solution:
http://vrfy.org/log/pam_console.html
http://lkml.org/lkml/2006/1/8/231

-- 
Olivier Blin - Mandriva



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[David Zeuthen]

On Fri, 2006-01-27 at 12:56 +0100, Olivier Blin wrote:
> Couldn't we use dynamic groups instead of ACLs?
> This would avoid running a tool to update ACLs at each device "add",
> and require group updates only at user login/logout.

Sure you can, but many agree that it's fundamentally insecure - once
member of a group, always member of a group...

    David



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Olivier Blin]

David Zeuthen <david@fubar.dk> writes:

> On Fri, 2006-01-27 at 12:56 +0100, Olivier Blin wrote:
>> Couldn't we use dynamic groups instead of ACLs?
>> This would avoid running a tool to update ACLs at each device "add",
>> and require group updates only at user login/logout.
>
> Sure you can, but many agree that it's fundamentally insecure - once
> member of a group, always member of a group...

Not if members of the groups are updated at user login/logout, what's
the problem with that?

-- 
Olivier Blin - Mandriva



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Darren Salt]

I demand that Kay Sievers may or may not have written...

[snip]
> Yes, we want to leave /proc with all stuff that isn't process related.

s/with all/without any/, surely...

[snip]
-- 
| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk
| Debian,     | Northumberland | s zap,tartarus,org
| RISC OS     | Toon Army      | @
|   Kill all extremists!

It is better to be deceived by a friend than to suspect him.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Bill Nottingham]

Olivier Blin (oblin@mandriva.com) said: 
> David Zeuthen <david@fubar.dk> writes:
> 
> > On Fri, 2006-01-27 at 12:56 +0100, Olivier Blin wrote:
> >> Couldn't we use dynamic groups instead of ACLs?
> >> This would avoid running a tool to update ACLs at each device "add",
> >> and require group updates only at user login/logout.
> >
> > Sure you can, but many agree that it's fundamentally insecure - once
> > member of a group, always member of a group...
> 
> Not if members of the groups are updated at user login/logout, what's
> the problem with that?

Log in, added to group, copy shell, add setgid bit...

Bill


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Johannes Erdfelt]

On Fri, Jan 27, 2006, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Thu, Jan 26, 2006 at 10:38:13PM -0500, Charles Lepple wrote:
> > Is there a plan for a successor to /proc/bus/usb/devices (that file
> > itself, not the /proc/bus/usb/012/345 nodes)?
> > 
> > If I am not mistaken, the 'devices' file allows ordinary users to
> > fetch the manufacturer, product and serial strings - without needing
> > to open the individual device nodes in read-write mode, and issue
> > requests to fetch those particular string descriptors.
> 
> These informations are all available in sysfs.

In libusb 1.0, we open /proc/bus/usb/devices and poll on the fd to get
informed when the bus state changes (device plugged in or disconnected).

Is there a replacement in sysfs?

JE



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Linus Walleij]

On Fri, 27 Jan 2006, Johannes Erdfelt wrote:

> In libusb 1.0, we open /proc/bus/usb/devices and poll on the fd to get
> informed when the bus state changes (device plugged in or disconnected).
>
> Is there a replacement in sysfs?

Intuitively I would say that linux.c should be rewritten to make use of 
inotify where available, i.e. register a callback for events in 
/dev/bus/usb (/proc/bus/usb) and act on these callbacks instead of 
polling.

Does any of the kernel guys know if this is a good way to go?

Perhaps there is an even smarter way.

Linus


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Johannes Erdfelt]

On Fri, Jan 27, 2006, Linus Walleij <triad@df.lth.se> wrote:
> On Fri, 27 Jan 2006, Johannes Erdfelt wrote:
> 
> >In libusb 1.0, we open /proc/bus/usb/devices and poll on the fd to get
> >informed when the bus state changes (device plugged in or disconnected).
> >
> >Is there a replacement in sysfs?
> 
> Intuitively I would say that linux.c should be rewritten to make use of 
> inotify where available, i.e. register a callback for events in 
> /dev/bus/usb (/proc/bus/usb) and act on these callbacks instead of 
> polling.

I guess I would need to register in each bus directory too. I guess this
would work.

> Does any of the kernel guys know if this is a good way to go?
> 
> Perhaps there is an even smarter way.

dbus and/or HAL?

JE



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Greg KH]

On Fri, Jan 27, 2006 at 11:29:57AM -0800, Johannes Erdfelt wrote:
> On Fri, Jan 27, 2006, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > On Thu, Jan 26, 2006 at 10:38:13PM -0500, Charles Lepple wrote:
> > > Is there a plan for a successor to /proc/bus/usb/devices (that file
> > > itself, not the /proc/bus/usb/012/345 nodes)?
> > > 
> > > If I am not mistaken, the 'devices' file allows ordinary users to
> > > fetch the manufacturer, product and serial strings - without needing
> > > to open the individual device nodes in read-write mode, and issue
> > > requests to fetch those particular string descriptors.
> > 
> > These informations are all available in sysfs.
> 
> In libusb 1.0, we open /proc/bus/usb/devices and poll on the fd to get
> informed when the bus state changes (device plugged in or disconnected).
> 
> Is there a replacement in sysfs?

Get called by udev or HAL when a device is added or removed.

If you use HAL, you can just set up a simple dbus notifier for this.

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Greg KH]

On Fri, Jan 27, 2006 at 07:05:06AM +0300, Andrey Borzenkov wrote:
> On Friday 27 January 2006 05:25, Greg KH wrote:
> > > I want to understand the reason for these device nodes since they seem
> > > to duplicate the nodes found in /proc/bus/usb. Is this just part of the
> > > long term plans to remove usbdevfs?
> >
> > They duplicate those nodes identically.  But now we can use udev and pam
> > and other tools to properly set the permissions and acls on the nodes.
> > Much easier than doing it through usbfs mount permissions, which only
> > work for all usbfs devices.
> >
> 
> Does Mandrake have patched kernel procfs?
> 
> {pts/1}% LC_ALL=C ll /proc/bus/usb/001

/proc/bus/usb is not procfs, it's usbfs mounted at that location.

Hope this helps explain things.

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Johannes Erdfelt]

On Fri, Jan 27, 2006, Linus Walleij <triad@df.lth.se> wrote:
> On Fri, 27 Jan 2006, Johannes Erdfelt wrote:
> >In libusb 1.0, we open /proc/bus/usb/devices and poll on the fd to get
> >informed when the bus state changes (device plugged in or disconnected).
> >
> >Is there a replacement in sysfs?
> 
> Intuitively I would say that linux.c should be rewritten to make use of 
> inotify where available, i.e. register a callback for events in 
> /dev/bus/usb (/proc/bus/usb) and act on these callbacks instead of 
> polling.
> 
> Does any of the kernel guys know if this is a good way to go?
> 
> Perhaps there is an even smarter way.

I'm working on implementing inotify support into libusb 1.0 right now.
Greg KH had suggested tighter integration into dbus, but I don't want to
bring in that dependency if it's not necessary.

JE



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Greg KH]

On Mon, Feb 06, 2006 at 03:29:41PM -0800, Johannes Erdfelt wrote:
> On Fri, Jan 27, 2006, Linus Walleij <triad@df.lth.se> wrote:
> > On Fri, 27 Jan 2006, Johannes Erdfelt wrote:
> > >In libusb 1.0, we open /proc/bus/usb/devices and poll on the fd to get
> > >informed when the bus state changes (device plugged in or disconnected).
> > >
> > >Is there a replacement in sysfs?
> > 
> > Intuitively I would say that linux.c should be rewritten to make use of 
> > inotify where available, i.e. register a callback for events in 
> > /dev/bus/usb (/proc/bus/usb) and act on these callbacks instead of 
> > polling.
> > 
> > Does any of the kernel guys know if this is a good way to go?
> > 
> > Perhaps there is an even smarter way.
> 
> I'm working on implementing inotify support into libusb 1.0 right now.

Does usbfs support inotify events?  For some reason I didn't think it
did, but I'm probably wrong...

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Johannes Erdfelt]

On Mon, Feb 06, 2006, Greg KH <greg@kroah.com> wrote:
> On Mon, Feb 06, 2006 at 03:29:41PM -0800, Johannes Erdfelt wrote:
> > I'm working on implementing inotify support into libusb 1.0 right now.
> 
> Does usbfs support inotify events?  For some reason I didn't think it
> did, but I'm probably wrong...

Well, it looks like it's trying to, but it's broken:

belushi:..otify-utils-0.25% ./inotify_test /proc/bus/usb/002
inotify device fd = 3
/proc/bus/usb/002 WD=1
read = 32
sizeof inotify_event = 16
pevent->len = 16
EVENT ON WD=1
DELETE (file) 0x00000200
FILENAME\x024

read = 32
sizeof inotify_event = 16
pevent->len = 16
EVENT ON WD=1
DELETE (file) 0x00000200
FILENAME\x025

That was an unplug followed by a replug. This was with my test Keyspan
serial device so there was a reset after the firmware was loaded. It
looks like we're only receiving DELETE events, and no CREATE ones.
It works correctly in /dev/bus/usb (which doesn't seem to create a
device node when it loads firmware):

belushi:..otify-utils-0.25% ./inotify_test /dev/bus/usb/2  
inotify device fd = 3
/dev/bus/usb/2 WD=1
read = 32
sizeof inotify_event = 16
pevent->len = 16
EVENT ON WD=1
DELETE (file) 0x00000200
FILENAME&

read = 32
sizeof inotify_event = 16
pevent->len = 16
EVENT ON WD=1
CREATE (file) 0x00000100
FILENAME(

I had planned on using the old method of polling on
/proc/bus/usb/devices for systems we use /proc/bus/usb anyway.

JE



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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

Re: [Libusb-devel] udev craze: need /dev/bus/usb rationale

[Greg KH]

On Mon, Feb 06, 2006 at 04:00:19PM -0800, Johannes Erdfelt wrote:
> On Mon, Feb 06, 2006, Greg KH <greg@kroah.com> wrote:
> > On Mon, Feb 06, 2006 at 03:29:41PM -0800, Johannes Erdfelt wrote:
> > > I'm working on implementing inotify support into libusb 1.0 right now.
> > 
> > Does usbfs support inotify events?  For some reason I didn't think it
> > did, but I'm probably wrong...
> 
> Well, it looks like it's trying to, but it's broken:
> 
> belushi:..otify-utils-0.25% ./inotify_test /proc/bus/usb/002
> inotify device fd = 3
> /proc/bus/usb/002 WD=1
> read = 32
> sizeof inotify_event = 16
> pevent->len = 16
> EVENT ON WD=1
> DELETE (file) 0x00000200
> FILENAME\x024
> 
> read = 32
> sizeof inotify_event = 16
> pevent->len = 16
> EVENT ON WD=1
> DELETE (file) 0x00000200
> FILENAME\x025
> 
> That was an unplug followed by a replug. This was with my test Keyspan
> serial device so there was a reset after the firmware was loaded. It
> looks like we're only receiving DELETE events, and no CREATE ones.
> It works correctly in /dev/bus/usb (which doesn't seem to create a
> device node when it loads firmware):

That's wierd that only the delete ones get sent and no others.

And the /dev/bus/usb stuff will always show up, as that is userspace
creating these files, not the kernel creating stuff underneath like the
usbfs files.

> belushi:..otify-utils-0.25% ./inotify_test /dev/bus/usb/2  
> inotify device fd = 3
> /dev/bus/usb/2 WD=1
> read = 32
> sizeof inotify_event = 16
> pevent->len = 16
> EVENT ON WD=1
> DELETE (file) 0x00000200
> FILENAME&
> 
> read = 32
> sizeof inotify_event = 16
> pevent->len = 16
> EVENT ON WD=1
> CREATE (file) 0x00000100
> FILENAME(
> 
> I had planned on using the old method of polling on
> /proc/bus/usb/devices for systems we use /proc/bus/usb anyway.

Maybe I should poke around and see how to get inotify working on libfs
based filesystems, I'm sure that sysfs could also use it...

thanks,

greg k-h


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
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