USB: remove CONFIG_USB_DEVICEFS

RFC PATCH In review Greg Kroah-Hartman 6 participants 16 messages Apr 26, 2012 – May 28, 2012

Subsystems (3)

Media (V4L/DVB) USB Staging

lore

Share & tools

lore

Greg Kroah-Hartman

author maintainer

2012-04-26 00:15 UTC #0 lore raw

RFC PATCH 1/1 USB: remove CONFIG_USB_DEVICEFS

This option has been deprecated for many years now, and no userspace tools use it anymore, so it should be safe to finally remove it.

Reported-by Kay Sievers <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
Anyone object to me queuing this up for the 3.5 kernel release?

 drivers/staging/media/go7007/go7007.txt |    1 -
 drivers/usb/core/Kconfig                |   29 --
 drivers/usb/core/Makefile               |    1 -
 drivers/usb/core/devio.c                |   11 -
 drivers/usb/core/driver.c               |   21 +-
 drivers/usb/core/inode.c                |  748 -------------------------------
 drivers/usb/core/usb.c                  |    6 -
 include/linux/usb.h                     |    7 -
 include/linux/usb/hcd.h                 |   23 -
 9 files changed, 2 insertions(+), 845 deletions(-)

drivers/staging/media/go7007/go7007.txt +0 -1

index 9db1f39..fcb3e23 100644
@@ -87,7 +87,6 @@ kernel as built-in or modules:
 	CONFIG_SOUND             - Sound card support
 	CONFIG_SND               - Advanced Linux Sound Architecture
 	CONFIG_USB               - Support for Host-side USB
-	CONFIG_USB_DEVICEFS      - USB device filesystem
 	CONFIG_USB_EHCI_HCD      - EHCI HCD (USB 2.0) support
 
 Additionally, to use the example application, the following options need to

drivers/usb/core/Kconfig +0 ~~-29~~

index 18d02e3..751031e 100644
@@ -27,35 +27,6 @@ config USB_ANNOUNCE_NEW_DEVICES
 comment "Miscellaneous USB options"
 	depends on USB
 
-config USB_DEVICEFS
-	bool "USB device filesystem (DEPRECATED)"
-	depends on USB
-	---help---
-	  If you say Y here (and to "/proc file system support" in the "File
-	  systems" section, above), you will get a file /proc/bus/usb/devices
-	  which lists the devices currently connected to your USB bus or
-	  busses, and for every connected device a file named
-	  "/proc/bus/usb/xxx/yyy", where xxx is the bus number and yyy the
-	  device number; the latter files can be used by user space programs
-	  to talk directly to the device. These files are "virtual", meaning
-	  they are generated on the fly and not stored on the hard drive.
-
-	  You may need to mount the usbfs file system to see the files, use
-	  mount -t usbfs none /proc/bus/usb
-
-	  For the format of the various /proc/bus/usb/ files, please read
-	  <file:Documentation/usb/proc_usb_info.txt>.
-
-	  Modern Linux systems do not use this.
-
-	  Usbfs entries are files and not character devices; usbfs can't
-	  handle Access Control Lists (ACL) which are the default way to
-	  grant access to USB devices for untrusted users of a desktop
-	  system.
-
-	  The usbfs functionality is replaced by real device-nodes managed by
-	  udev.  These nodes lived in /dev/bus/usb and are used by libusb.
-
 config USB_DEVICE_CLASS
 	bool "USB device class-devices (DEPRECATED)"
 	depends on USB

drivers/usb/core/Makefile +0 -1

index 507a4e1..c4ea846 100644
@@ -9,6 +9,5 @@ usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o
 usbcore-y += devio.o notify.o generic.o quirks.o devices.o
 
 usbcore-$(CONFIG_PCI)		+= hcd-pci.o
-usbcore-$(CONFIG_USB_DEVICEFS)	+= inode.o
 
 obj-$(CONFIG_USB)		+= usbcore.o

drivers/usb/core/devio.c +0 ~~-11~~

index 8df4b76..90db6e2 100644
@@ -727,17 +727,6 @@ static int usbdev_open(struct inode *inode, struct file *file)
 	if (imajor(inode) == USB_DEVICE_MAJOR)
 		dev = usbdev_lookup_by_devt(inode->i_rdev);
 
-#ifdef CONFIG_USB_DEVICEFS
-	/* procfs file */
-	if (!dev) {
-		dev = inode->i_private;
-		if (dev && dev->usbfs_dentry &&
-					dev->usbfs_dentry->d_inode == inode)
-			usb_get_dev(dev);
-		else
-			dev = NULL;
-	}
-#endif
 	mutex_unlock(&usbfs_mutex);
 
 	if (!dev)

drivers/usb/core/driver.c +2 ~~-19~~

index 9a56635..112a7ae 100644
@@ -726,16 +726,6 @@ static int usb_uevent(struct device *dev, struct kobj_uevent_env *env)
 		return -ENODEV;
 	}
 
-#ifdef	CONFIG_USB_DEVICEFS
-	/* If this is available, userspace programs can directly read
-	 * all the device descriptors we don't tell them about.  Or
-	 * act as usermode drivers.
-	 */
-	if (add_uevent_var(env, "DEVICE=/proc/bus/usb/%03d/%03d",
-			   usb_dev->bus->busnum, usb_dev->devnum))
-		return -ENOMEM;
-#endif
-
 	/* per-device configurations are common */
 	if (add_uevent_var(env, "PRODUCT=%x/%x/%x",
 			   le16_to_cpu(usb_dev->descriptor.idVendor),

@@ -788,15 +778,13 @@ int usb_register_device_driver(struct usb_device_driver *new_udriver,
 
 	retval = driver_register(&new_udriver->drvwrap.driver);
 
-	if (!retval) {
+	if (!retval)
 		pr_info("%s: registered new device driver %s\n",
 			usbcore_name, new_udriver->name);
-		usbfs_update_special();
-	} else {
+	else
 		printk(KERN_ERR "%s: error %d registering device "
 			"	driver %s\n",
 			usbcore_name, retval, new_udriver->name);
-	}
 
 	return retval;
 }

@@ -815,7 +803,6 @@ void usb_deregister_device_driver(struct usb_device_driver *udriver)
 			usbcore_name, udriver->name);
 
 	driver_unregister(&udriver->drvwrap.driver);
-	usbfs_update_special();
 }
 EXPORT_SYMBOL_GPL(usb_deregister_device_driver);

@@ -856,8 +843,6 @@ int usb_register_driver(struct usb_driver *new_driver, struct module *owner,
 	if (retval)
 		goto out;
 
-	usbfs_update_special();
-
 	retval = usb_create_newid_files(new_driver);
 	if (retval)
 		goto out_newid;

@@ -897,8 +882,6 @@ void usb_deregister(struct usb_driver *driver)
 	usb_remove_newid_files(driver);
 	driver_unregister(&driver->drvwrap.driver);
 	usb_free_dynids(driver);
-
-	usbfs_update_special();
 }
 EXPORT_SYMBOL_GPL(usb_deregister);

drivers/usb/core/inode.c deleted +0 ~~-748~~

748 lines not on this page · raw message

drivers/usb/core/usb.c +0 -6

index c74ba7b..0ce862b 100644
@@ -1030,9 +1030,6 @@ static int __init usb_init(void)
 	retval = usb_devio_init();
 	if (retval)
 		goto usb_devio_init_failed;
-	retval = usbfs_init();
-	if (retval)
-		goto fs_init_failed;
 	retval = usb_hub_init();
 	if (retval)
 		goto hub_init_failed;

@@ -1042,8 +1039,6 @@ static int __init usb_init(void)
 
 	usb_hub_cleanup();
 hub_init_failed:
-	usbfs_cleanup();
-fs_init_failed:
 	usb_devio_cleanup();
 usb_devio_init_failed:
 	usb_deregister(&usbfs_driver);

@@ -1070,7 +1065,6 @@ static void __exit usb_exit(void)
 
 	usb_deregister_device_driver(&usb_generic_driver);
 	usb_major_cleanup();
-	usbfs_cleanup();
 	usb_deregister(&usbfs_driver);
 	usb_devio_cleanup();
 	usb_hub_cleanup();

include/linux/usb.h +0 -7

index 45bc7a5..a63c5ba 100644
@@ -351,10 +351,6 @@ struct usb_bus {
 	int bandwidth_int_reqs;		/* number of Interrupt requests */
 	int bandwidth_isoc_reqs;	/* number of Isoc. requests */
 
-#ifdef CONFIG_USB_DEVICEFS
-	struct dentry *usbfs_dentry;	/* usbfs dentry entry for the bus */
-#endif
-
 #if defined(CONFIG_USB_MON) || defined(CONFIG_USB_MON_MODULE)
 	struct mon_bus *mon_bus;	/* non-null when associated */
 	int monitored;			/* non-zero when monitored */

@@ -496,9 +492,6 @@ struct usb_device {
 #ifdef CONFIG_USB_DEVICE_CLASS
 	struct device *usb_classdev;
 #endif
-#ifdef CONFIG_USB_DEVICEFS
-	struct dentry *usbfs_dentry;
-#endif
 
 	int maxchild;
 	struct usb_device **children;

include/linux/usb/hcd.h +0 ~~-23~~

index 5de4157..159a08a 100644
@@ -582,29 +582,6 @@ static inline void usb_hcd_resume_root_hub(struct usb_hcd *hcd)
 }
 #endif /* CONFIG_USB_SUSPEND */
 
-
-/*
- * USB device fs stuff
- */
-
-#ifdef CONFIG_USB_DEVICEFS
-
-/*
- * these are expected to be called from the USB core/hub thread
- * with the kernel lock held
- */
-extern void usbfs_update_special(void);
-extern int usbfs_init(void);
-extern void usbfs_cleanup(void);
-
-#else /* CONFIG_USB_DEVICEFS */
-
-static inline void usbfs_update_special(void) {}
-static inline int usbfs_init(void) { return 0; }
-static inline void usbfs_cleanup(void) { }
-
-#endif /* CONFIG_USB_DEVICEFS */
-
 /*-------------------------------------------------------------------------*/
 
 #if defined(CONFIG_USB_MON) || defined(CONFIG_USB_MON_MODULE)

Alan Stern

2012-04-26 15:06 UTC #1 lore raw

Quoted 8 lines · Greg Kroah-Hartman

This option has been deprecated for many years now, and no userspace tools use it anymore, so it should be safe to finally remove it.
Reported-by Kay Sievers <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
Anyone object to me queuing this up for the 3.5 kernel release?

I'm not sure about this. There are a few systems still floating around that don't use udev; on those systems /proc/bus/usb is the only way for user programs to control USB devices. Admittedly, I have no idea whether any such systems will be using 3.5 or later kernels...

Alan Stern

Greg Kroah-Hartman

author maintainer

2012-04-26 15:12 UTC #2 lore raw

Quoted 8 lines · Alan Stern

Quoted 6 lines · Greg Kroah-Hartman
This option has been deprecated for many years now, and no userspace tools use it anymore, so it should be safe to finally remove it.
Reported-by Kay Sievers <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>

Quoted 7 lines

Quoted 2 lines
---
Anyone object to me queuing this up for the 3.5 kernel release?
I'm not sure about this. There are a few systems still floating around that don't use udev; on those systems /proc/bus/usb is the only way for user programs to control USB devices. Admittedly, I have no idea whether any such systems will be using 3.5 or later kernels...

They don't have to use udev, they can use devtmpfs (which is what the majority of embedded systems use today), or they can just use static device nodes to get access to these devices, the char node is still present, we aren't getting rid of them at all.

thanks,

greg k-h

Jeff Chua

2012-05-24 15:55 UTC #3 lore raw

Quoted 16 lines · Greg Kroah-Hartman

Quoted 8 lines · Alan Stern
Quoted 6 lines · Greg Kroah-Hartman
This option has been deprecated for many years now, and no userspace tools use it anymore, so it should be safe to finally remove it.
Reported-by Kay Sievers <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
Quoted 6 lines
Quoted 1 line
Anyone object to me queuing this up for the 3.5 kernel release?
I'm not sure about this. There are a few systems still floating around that don't use udev; on those systems /proc/bus/usb is the only way for user programs to control USB devices. Admittedly, I have no idea whether any such systems will be using 3.5 or later kernels...

Quoted 4 lines

They don't have to use udev, they can use devtmpfs (which is what the majority of embedded systems use today), or they can just use static device nodes to get access to these devices, the char node is still present, we aren't getting rid of them at all.

Looks like vmware is breaking. Can't find any usb devices. I'm not using udev.

Jeff

Alan Cox

2012-05-24 15:59 UTC #4 lore raw

Quoted 18 lines · On Thu, 24 May 2012 23:55:16 +0800 Jeff Chua <[email protected]> wrote:

Quoted 16 lines · Greg Kroah-Hartman
Quoted 14 lines · Alan Stern
Quoted 7 lines · Greg Kroah-Hartman
This option has been deprecated for many years now, and no userspace tools use it anymore, so it should be safe to finally remove it.
Reported-by Kay Sievers <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
Anyone object to me queuing this up for the 3.5 kernel release?
I'm not sure about this. There are a few systems still floating around that don't use udev; on those systems /proc/bus/usb is the only way for user programs to control USB devices. Admittedly, I have no idea whether any such systems will be using 3.5 or later kernels...

Quoted 6 lines

Quoted 4 lines
They don't have to use udev, they can use devtmpfs (which is what the majority of embedded systems use today), or they can just use static device nodes to get access to these devices, the char node is still present, we aren't getting rid of them at all.
Looks like vmware is breaking. Can't find any usb devices. I'm not using udev.

Perhaps a WARN_ON_ONCE would be safer for a bit ?

Greg Kroah-Hartman

author maintainer

2012-05-24 21:52 UTC #5 lore raw

In reply to Jeff Chua

Quoted 18 lines · Jeff Chua

Quoted 16 lines · Greg Kroah-Hartman
Quoted 14 lines · Alan Stern
Quoted 7 lines · Greg Kroah-Hartman
This option has been deprecated for many years now, and no userspace tools use it anymore, so it should be safe to finally remove it.
Reported-by Kay Sievers <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
Anyone object to me queuing this up for the 3.5 kernel release?
I'm not sure about this. There are a few systems still floating around that don't use udev; on those systems /proc/bus/usb is the only way for user programs to control USB devices. Admittedly, I have no idea whether any such systems will be using 3.5 or later kernels...

Quoted 6 lines

Quoted 4 lines
They don't have to use udev, they can use devtmpfs (which is what the majority of embedded systems use today), or they can just use static device nodes to get access to these devices, the char node is still present, we aren't getting rid of them at all.
Looks like vmware is breaking. Can't find any usb devices. I'm not using udev.

vmware doesn't use usbfs, otherwise how would it be working on all of the systems out there that haven't mounted usbfs for years?

What exactly broke? What version of vmware are you using, and is the problem in the guest or host?

We delayed other usbfs changes for years due to vmware "issues", it wouldn't be the first time we've had to handle this :(

thanks,

greg k-h

Jeff Chua

2012-05-25 05:48 UTC #6 lore raw

Quoted 26 lines · Greg Kroah-Hartman

Quoted 18 lines · Jeff Chua
Quoted 16 lines · Greg Kroah-Hartman
Quoted 14 lines · Alan Stern
Quoted 7 lines · Greg Kroah-Hartman
This option has been deprecated for many years now, and no userspace tools use it anymore, so it should be safe to finally remove it.
Reported-by Kay Sievers <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
Anyone object to me queuing this up for the 3.5 kernel release?
I'm not sure about this. There are a few systems still floating around that don't use udev; on those systems /proc/bus/usb is the only way for user programs to control USB devices. Admittedly, I have no idea whether any such systems will be using 3.5 or later kernels...
Quoted 6 lines
Quoted 4 lines
They don't have to use udev, they can use devtmpfs (which is what the majority of embedded systems use today), or they can just use static device nodes to get access to these devices, the char node is still present, we aren't getting rid of them at all.
Looks like vmware is breaking. Can't find any usb devices. I'm not using udev.

Quoted 8 lines

vmware doesn't use usbfs, otherwise how would it be working on all of the systems out there that haven't mounted usbfs for years?
What exactly broke? What version of vmware are you using, and is the problem in the guest or host?
We delayed other usbfs changes for years due to vmware "issues", it wouldn't be the first time we've had to handle this :(

VMWare workstation 8.0.3

# vmware-usbarbitrator -f --info
DICT       product.buildNumber = 703057
DICT           product.version = 8.0.3
DICT workstation.product.version = 8.0.3
DICT              product.name = VMware Workstation
VMware USB Arbitration Service Version 8.4.19
USB: Unable to open "/proc/bus/usb/devices" (No such file or directory).
No USB enumerator!

If I revert back to git pull 3 years earlier, it works.

Thanks,
Jeff

Greg Kroah-Hartman

author maintainer

2012-05-25 06:01 UTC #7 lore raw

Quoted 40 lines · Jeff Chua

Quoted 26 lines · Greg Kroah-Hartman
Quoted 18 lines · Jeff Chua
Quoted 16 lines · Greg Kroah-Hartman
Quoted 14 lines · Alan Stern
Quoted 7 lines · Greg Kroah-Hartman
This option has been deprecated for many years now, and no userspace tools use it anymore, so it should be safe to finally remove it.
Reported-by Kay Sievers <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
Anyone object to me queuing this up for the 3.5 kernel release?
I'm not sure about this. There are a few systems still floating around that don't use udev; on those systems /proc/bus/usb is the only way for user programs to control USB devices. Admittedly, I have no idea whether any such systems will be using 3.5 or later kernels...
Quoted 6 lines
Quoted 4 lines
They don't have to use udev, they can use devtmpfs (which is what the majority of embedded systems use today), or they can just use static device nodes to get access to these devices, the char node is still present, we aren't getting rid of them at all.
Looks like vmware is breaking. Can't find any usb devices. I'm not using udev.
Quoted 8 lines
vmware doesn't use usbfs, otherwise how would it be working on all of the systems out there that haven't mounted usbfs for years?
What exactly broke? What version of vmware are you using, and is the problem in the guest or host?
We delayed other usbfs changes for years due to vmware "issues", it wouldn't be the first time we've had to handle this :(
VMWare workstation 8.0.3

Quoted 8 lines

# vmware-usbarbitrator -f --info
DICT       product.buildNumber = 703057
DICT           product.version = 8.0.3
DICT workstation.product.version = 8.0.3
DICT              product.name = VMware Workstation
VMware USB Arbitration Service Version 8.4.19
USB: Unable to open "/proc/bus/usb/devices" (No such file or directory).
No USB enumerator!

Ok, I have no idea what any of this means.

What host os are you using that does not have udev in it?

What client os are you using that wants access to the USB ports that is not working? Is this the latest version of vmware (hint, I have no idea what their version numbering is, you are going to have to look that up, but I know they have fixed stuff like this in their newer releases.)

What release of the host os are you running?

If you aren't using udev, what are you using for your static device nodes?

If you are using static device nodes, why don't you have the /dev/usb/ nodes on your system (i.e. why didn't your distro create them for you?)

Quoted 1 line

If I revert back to git pull 3 years earlier, it works.

A git pull of a 3 year old kernel? What are you talking about here?

totally confused,

greg k-h

Jeff Chua

2012-05-25 07:06 UTC #8 lore raw

Quoted 49 lines · Greg Kroah-Hartman

Quoted 40 lines · Jeff Chua
Quoted 26 lines · Greg Kroah-Hartman
Quoted 18 lines · Jeff Chua
Quoted 16 lines · Greg Kroah-Hartman
Quoted 14 lines · Alan Stern
Quoted 7 lines · Greg Kroah-Hartman
This option has been deprecated for many years now, and no userspace tools use it anymore, so it should be safe to finally remove it.
Reported-by Kay Sievers <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
Anyone object to me queuing this up for the 3.5 kernel release?
I'm not sure about this. There are a few systems still floating around that don't use udev; on those systems /proc/bus/usb is the only way for user programs to control USB devices. Admittedly, I have no idea whether any such systems will be using 3.5 or later kernels...
Quoted 6 lines
Quoted 4 lines
They don't have to use udev, they can use devtmpfs (which is what the majority of embedded systems use today), or they can just use static device nodes to get access to these devices, the char node is still present, we aren't getting rid of them at all.
Looks like vmware is breaking. Can't find any usb devices. I'm not using udev.
Quoted 8 lines
vmware doesn't use usbfs, otherwise how would it be working on all of the systems out there that haven't mounted usbfs for years?
What exactly broke? What version of vmware are you using, and is the problem in the guest or host?
We delayed other usbfs changes for years due to vmware "issues", it wouldn't be the first time we've had to handle this :(
VMWare workstation 8.0.3
Quoted 8 lines
# vmware-usbarbitrator -f --info
DICT       product.buildNumber = 703057
DICT           product.version = 8.0.3
DICT workstation.product.version = 8.0.3
DICT              product.name = VMware Workstation
VMware USB Arbitration Service Version 8.4.19
USB: Unable to open "/proc/bus/usb/devices" (No such file or directory).
No USB enumerator!

Quoted 1 line

Ok, I have no idea what any of this means.

I think the process "vmware-usbarbitrator" is trying to read proc/bus/usb/devices and can't find the file, so when I go to vmware, it can't find any usb devices.

Quoted 1 line

What host os are you using that does not have udev in it?

No udev. My own vanilla kernel.

Quoted 4 lines

What client os are you using that wants access to the USB ports that is not working? Is this the latest version of vmware (hint, I have no idea what their version numbering is, you are going to have to look that up, but I know they have fixed stuff like this in their newer releases.)

It's the latest vmware workstation 8.0.3. The vmware "Removable Devices" tab is not showing any USB devices.

Quoted 1 line

What release of the host os are you running?

Linux-3.4.0 with commit 07acfc2a9349a8ce45b236c2624dad452001966b.

Quoted 1 line

If you aren't using udev, what are you using for your static device nodes?

Usually, with /proc/bus/usb/devices present, vmware will just read from this file and I get to see the usb devices in vmware.

Quoted 2 lines

If you are using static device nodes, why don't you have the /dev/usb/ nodes on your system (i.e. why didn't your distro create them for you?)

Didn't check that as it was working just few days earlier:)

Quoted 2 lines

Quoted 1 line
If I revert back to git pull 3 years earlier, it works.
A git pull of a 3 year old kernel? What are you talking about here?

It should have been 3 days ago. Sorry! 3 linux days seems like 3 years in the human time:)

Thanks,
Jeff

Greg Kroah-Hartman

author maintainer

2012-05-25 07:16 UTC #9 lore raw

Quoted 51 lines · Jeff Chua

Quoted 49 lines · Greg Kroah-Hartman
Quoted 48 lines · Jeff Chua
Quoted 26 lines · Greg Kroah-Hartman
Quoted 18 lines · Jeff Chua
Quoted 16 lines · Greg Kroah-Hartman
Quoted 14 lines · Alan Stern
Quoted 7 lines · Greg Kroah-Hartman
This option has been deprecated for many years now, and no userspace tools use it anymore, so it should be safe to finally remove it.
Reported-by Kay Sievers <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
Anyone object to me queuing this up for the 3.5 kernel release?
I'm not sure about this. There are a few systems still floating around that don't use udev; on those systems /proc/bus/usb is the only way for user programs to control USB devices. Admittedly, I have no idea whether any such systems will be using 3.5 or later kernels...
Quoted 6 lines
Quoted 4 lines
They don't have to use udev, they can use devtmpfs (which is what the majority of embedded systems use today), or they can just use static device nodes to get access to these devices, the char node is still present, we aren't getting rid of them at all.
Looks like vmware is breaking. Can't find any usb devices. I'm not using udev.
Quoted 8 lines
vmware doesn't use usbfs, otherwise how would it be working on all of the systems out there that haven't mounted usbfs for years?
What exactly broke? What version of vmware are you using, and is the problem in the guest or host?
We delayed other usbfs changes for years due to vmware "issues", it wouldn't be the first time we've had to handle this :(
VMWare workstation 8.0.3
# vmware-usbarbitrator -f --info
DICT       product.buildNumber = 703057
DICT           product.version = 8.0.3
DICT workstation.product.version = 8.0.3
DICT              product.name = VMware Workstation
VMware USB Arbitration Service Version 8.4.19
USB: Unable to open "/proc/bus/usb/devices" (No such file or directory).
No USB enumerator!

Quoted 5 lines

Quoted 1 line
Ok, I have no idea what any of this means.
I think the process "vmware-usbarbitrator" is trying to read proc/bus/usb/devices and can't find the file, so when I go to vmware, it can't find any usb devices.

You are running this program where, in the host or guest?

Quoted 3 lines

Quoted 1 line
What host os are you using that does not have udev in it?
No udev. My own vanilla kernel.

What distro. Why no udev? What is managing your /dev/ tree? A distro package? A tarball? Something else?

Quoted 7 lines

Quoted 4 lines
What client os are you using that wants access to the USB ports that is not working? Is this the latest version of vmware (hint, I have no idea what their version numbering is, you are going to have to look that up, but I know they have fixed stuff like this in their newer releases.)
It's the latest vmware workstation 8.0.3. The vmware "Removable Devices" tab is not showing any USB devices.

For the host or guest?

Quoted 3 lines

Quoted 1 line
What release of the host os are you running?
Linux-3.4.0 with commit 07acfc2a9349a8ce45b236c2624dad452001966b.

No, sorry, what distro?

Quoted 4 lines

Quoted 1 line
If you aren't using udev, what are you using for your static device nodes?
Usually, with /proc/bus/usb/devices present, vmware will just read from this file and I get to see the usb devices in vmware.

That's nice, but it's been depreciated for many years now. vmware supports this to run on older systems that never changed. The usbfs code turned out to be wrong as it couldn't handle user permissions properly, which is why it has been removed.

Use /dev/usb/ device nodes intead. If you have a distro that has static device nodes, just add them to the package that has those nodes, and you should be fine. That will bring you into the mid 2000's as far as device nodes go, I'm amazed that this hasn't been noticed before now.

thanks,

greg k-h

Kay Sievers

2012-05-25 09:01 UTC #10 lore raw

Quoted 4 lines · Greg Kroah-Hartman

Quoted 2 lines · Jeff Chua
Quoted 2 lines
Quoted 2 lines
VMware USB Arbitration Service Version 8.4.19
USB: Unable to open "/proc/bus/usb/devices" (No such file or directory).

I think vmware tries to open the usual /dev/bus/usb/ nodes directly after it has tried the deprecated /proc nodes.

Udev would create the /dev/bus/ nodes.

Or the kernel would create them itself if:
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
is used.

Quoted 4 lines

Use /dev/usb/ device nodes instead. If you have a distro that has static device nodes, just add them to the package that has those nodes, and you should be fine. That will bring you into the mid 2000's as far as device nodes go, I'm amazed that this hasn't been noticed before now.

Many distros have disabled the USB_DEVICEFS option and there are usually no reports about problems any more.

But I guess the number of systems that want to run USB devices, and pass them along to virtualization, but have an unmanaged static /dev are close to one user these days. :)

Kay

Kay Sievers

2012-05-25 11:35 UTC #11 lore raw

Quoted 10 lines · Kay Sievers

Quoted 4 lines · Greg Kroah-Hartman
Quoted 2 lines · Jeff Chua
Quoted 2 lines
Quoted 2 lines
VMware USB Arbitration Service Version 8.4.19
USB: Unable to open "/proc/bus/usb/devices" (No such file or directory).
I think vmware tries to open the usual /dev/bus/usb/ nodes directly after it has tried the deprecated /proc nodes.

Quoted 6 lines

Udev would create the /dev/bus/ nodes.
Or the kernel would create them itself if:
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
is used.

Jeff,

if you still need to keep your static /dev setup, can you please try:

  $ mkdir /dev/bus
  $ mount -t devtmpfs none /dev/bus
  $ mount --bind /dev/bus/bus /dev/bus

This should replace the yucky usbfs nodes at /proc/bus/ with the usual /dev/bus/ kernel-managed device nodes. It tricks the usually used /dev devtmpfs, into just providing /dev/bus/ on top of your static /dev.

VMWare should pick up this directory, just like it works for all usual distro-like setups, and find the dynamically managed USB devices.

Kay

Jeff Chua

2012-05-25 13:31 UTC #12 lore raw

In reply to Kay Sievers

Quoted 22 lines · Kay Sievers

Quoted 4 lines · Greg Kroah-Hartman
Quoted 2 lines · Jeff Chua
Quoted 2 lines
Quoted 2 lines
VMware USB Arbitration Service Version 8.4.19
USB: Unable to open "/proc/bus/usb/devices" (No such file or directory).
I think vmware tries to open the usual /dev/bus/usb/ nodes directly after it has tried the deprecated /proc nodes.
Udev would create the /dev/bus/ nodes.
Or the kernel would create them itself if:
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
is used.
Quoted 4 lines
Use /dev/usb/ device nodes instead. If you have a distro that has static device nodes, just add them to the package that has those nodes, and you should be fine. That will bring you into the mid 2000's as far as device nodes go, I'm amazed that this hasn't been noticed before now.

Quoted 6 lines

Many distros have disabled the USB_DEVICEFS option and there are usually no reports about problems any more.
But I guess the number of systems that want to run USB devices, and pass them along to virtualization, but have an unmanaged static /dev are close to one user these days. :)

Yep, it's just me (the one), I guess. Configured kernel as suggested, and it's all working now.

Sorry, as for the distro, it's just bare minimum...but works wonderfully well.

Thanks again for all your help!

Jeff

Ezequiel Garcia

2012-05-28 12:37 UTC #13 lore raw

In reply to Greg Kroah-Hartman

Hi Greg,

Quoted 3 lines · Greg Kroah-Hartman

This option has been deprecated for many years now, and no userspace tools use it anymore, so it should be safe to finally remove it.

Does this mean usbview will be completely deprecated? Do you think is it possible to write an update for it?

It was a little more helpful for me than lsusb. (Is it just me?)

Thanks,
Ezequiel.

Greg Kroah-Hartman

author maintainer

2012-05-28 13:54 UTC #14 lore raw

Quoted 10 lines · Ezequiel Garcia

Hi Greg,
Quoted 3 lines · Greg Kroah-Hartman
This option has been deprecated for many years now, and no userspace tools use it anymore, so it should be safe to finally remove it.
Does this mean usbview will be completely deprecated? Do you think is it possible to write an update for it?

It works just fine if you point usbview at
/sys/kernel/debug/usb/devices, right?

Quoted 1 line

It was a little more helpful for me than lsusb. (Is it just me?)

I think so, I have not gotten any comments on that program in a very long time :)

thanks,

greg k-h

Ezequiel Garcia

2012-05-28 14:20 UTC #15 lore raw

Hi,

Quoted 9 lines · Greg Kroah-Hartman

Quoted 8 lines · Ezequiel Garcia
Hi Greg,
Quoted 3 lines · Greg Kroah-Hartman
This option has been deprecated for many years now, and no userspace tools use it anymore, so it should be safe to finally remove it.

Quoted 6 lines

Quoted 2 lines
Does this mean usbview will be completely deprecated? Do you think is it possible to write an update for it?
It works just fine if you point usbview at
/sys/kernel/debug/usb/devices, right?

Yes, it does.

Thanks,
Ezequiel.