Find scsi device ids under Linux?
Please take my previous comment about how to ask good questions seriously! Drop the «hi» and «thanks», make sure the first few lines or the question introduce the question instead of being meta data so that the home page summaries are useful, and always show what attempts you have made to solve problems yourself. I answered this question by copy and pasting a bit of it into google and copy and pasting a bit from the result summaries back to you (after checking it in my terminal).
SCSI ID is not precisely defined thing, reference this discussion yarchive.net/comp/linux/scsi_ids.html
3 Answers 3
I don’t have /proc/scsi/scsi on my system with 2.6.39.1 kernel. I would use ‘lsscsi’ command:
~> lsscsi -v [0:0:0:0] disk ATA ST3500418AS CC38 /dev/sda dir: /sys/bus/scsi/devices/0:0:0:0 [/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0] [1:0:0:0] disk ATA WDC WD2500KS-00M 02.0 /dev/sdb dir: /sys/bus/scsi/devices/1:0:0:0 [/sys/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0] 2.6.38.6 here and I do have it. I wonder if there is a kernel config option for providing that interface. The reference I found to using that proc entry was as old as the hills. Also my distro doesn’t have lsscsi by default although I see there is an optional package for it.
@MatthiasUrlichs does exist for me on 5.18.6-zen1-1-zen . Perhaps you kernel has some setting disabled that creates that dir.
You can use the links in /dev/disk/by-id :
[root@krxl02cn05 by-id]# pwd /dev/disk/by-id [root@krxl02cn05 by-id]# ls -rtl total 0 lrwxrwxrwx 1 root root 9 Feb 12 01:40 scsi-3600605b005d8655019aa31faf0812bae -> ../../sda lrwxrwxrwx 1 root root 10 Feb 12 01:40 scsi-3600605b005d8655019aa31faf0812bae-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Feb 12 01:40 scsi-3600605b005d8655019aa31faf0812bae-part1 -> ../../sda1 lrwxrwxrwx 1 root root 9 Feb 12 01:50 scsi-3600144f09a214698000054db88550008 -> ../../sdd lrwxrwxrwx 1 root root 9 Feb 12 01:50 scsi-3600144f09a214698000054db88460007 -> ../../sdc lrwxrwxrwx 1 root root 9 Feb 12 01:50 scsi-3600144f09a214698000054db88260006 -> ../../sdb lrwxrwxrwx 1 root root 10 Feb 12 01:54 scsi-3600144f09a214698000054db88260006-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 15 Feb 12 04:56 scsi-3600144f09a214698000054db88460007-part1 -> ../../asm-disk1 lrwxrwxrwx 1 root root 15 Feb 12 04:59 scsi-3600144f09a214698000054db88550008-part1 -> ../../asm-disk2 So, the scsi id of /dev/sdc is 3600144f09a214698000054db88460007
INTRODUCTION
Devices on the PCI bus are identified by a combination of a vendor ID (assigned by the PCI SIG) and device ID (assigned by the vendor). Both IDs are 16-bit integers and the device itself provides no translation to a human-readable string.
In addition to the vendor and device, devices also report several other identifiers:
- Device class and subclass (two 8-bit numbers)
- Programming interface (8-bit number, meaning specific for the subclass)
- Subsystem, which identifies the assembly in which the device is contained. A typical example is an Ethernet add-in card: the device is the Ethernet controller chip, while the card plays the role of the subsystem. Subsystems have their vendor ID (from the same namespace as device vendors) and subsystem ID. Generally, the meaning of the subsystem ID depends on the device, but there are cases in which a single subsystem ID is used for many devices — e.g., laptop motherboards. The PCI utilities use the pci.ids file to translate all these numeric IDs to strings.
KEEPING THE LIST UP-TO-DATE
The pci.ids file is generated from the PCI ID database, which is maintained at https://pci-ids.ucw.cz/. If you find any IDs missing from the list, please contribute them to the database.
You can use the update-pciids command to download the current version of the list.
Alternatively, you can use lspci -q to query the database online.
FILE FORMAT
The pci.ids file is a text file in plain ASCII, interpreted line by line. Lines starting with the hash sign are treated as comments are ignored. Comments regarding a specific entry are written immediately before the entry.
Vendor entries start with a 4-digit hexadecimal vendor ID, followed by one or more spaces, and the name of the vendor extending to the end of the line.
Device entries are placed below the vendor entry. Each device entry consists of a single TAB character, a 4-digit hexadecimal device ID, followed by one or more spaces, and the name of the device extending to the end of the line.
Subsystem entries are placed below the device entry. They start with two TAB characters, a 4-digit hexadecimal vendor ID (which must be defined elsewhere in the list), a single space, a 4-digit hexadecimal subsystem ID, one or more spaces, and the name of the subsystem extending to the end of the line.
Class entries consist of «C», one space, 2-digit hexadecimal class ID, one or more spaces, and the name of the class. Subclasses are placed below the corresponding class, indented by a single TAB, followed by a 2-digit hexadecimal subclass ID, one or more spaces, and the name of the subclass. Programming interfaces are below the subclass, indented by two TABs, followed by a 2-digit hexadecimal prog-if ID, one or more spaces, and the name.
There can be device-independent subsystem IDs, although the web interface of the database does not support them yet. They start with a subsystem vendor line consisting of «S», one space, and a 4-digit hexadecimal vendor ID (which must correspond to an already listed vendor). Subsystems follow on subsequent lines, each indented by one TAB, followed by a 4-digit hexadecimal subsystem ID, one or more spaces, and the name of the subsystem.
To ensure extensibility of the format, lines starting with an unrecognized letter followed by a single space are ignored and so are all following TAB-indented lines.
FILES
SEE ALSO
AUTHOR
The PCI Utilities are maintained by Martin Mares .
Package name: core/pciutils Version: 3.10.0-1 Upstream: https://mj.ucw.cz/sw/pciutils/ Licenses: GPL2 Manuals: /listing/core/pciutils/ Table of contents
Powered by archmanweb, using mandoc for the conversion of manual pages.
The website is available under the terms of the GPL-3.0 license, except for the contents of the manual pages, which have their own license specified in the corresponding Arch Linux package.
How to get USB vendor and product info programmatically on Linux?
Now I want to get the full strings that are associated with the vendor and product ids. I found that the file /usr/share/misc/usb.ids contains the information that I’m looking for:
13b1 Linksys 000b WUSB11 v4.0 802.11b Adapter 000d WUSB54G Wireless Adapter 0011 WUSB54GP v4.0 802.11g Adapter 0018 USB200M 10/100 Ethernet Adapter 001a HU200TS Wireless Adapter 001e WUSBF54G 802.11bg 0020 WUSB54GC 802.11g Adapter [ralink rt73] 0023 WUSB54GR 0024 WUSBF54G v1.1 802.11bg However, it’s not clear to me how I should retrieve this data in my application. Is there an API available or should I just parse the file? If I choose to parse it, then is /usr/share/misc/usb.ids always going to be the correct location?
Here’s the most recent version: linux-usb.org/usb.ids and the interface for submitting them: linux-usb.org/usb-ids.html
On Android, my C program uses libusbhost which provides callbacks for device insertion/removal. All device descriptors are made available by the lib.
5 Answers 5
lsusb command queries information about currently plugged USB devices. You can use its -d option to query a certain vendor/product (but it seems to work only for currently plugged devices):
$ lsusb -d 0e21:0750 Bus 001 Device 005: ID 0e21:0750 Cowon Systems, Inc. You can show information for all devices:
$ lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 004: ID 0421:01c7 Nokia Mobile Phones Bus 001 Device 003: ID 0bda:8187 Realtek Semiconductor Corp. RTL8187 Wireless Adapter Bus 001 Device 005: ID 0e21:0750 Cowon Systems, Inc. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 002: ID 046d:c01b Logitech, Inc. MX310 Optical Mouse Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub You can also make it be verbose ( lsusb -v ) and printing a lot of stuff.
Note that when accessing information about the system in Linux OS, it’s much preferred to do it via shell commands (such as lsusb ) than to directly parse the system files these commands access.
@Stacked, yes (for C), but that depends on a language you develop in. But either way you’ll be reading something from a stream, and calling lsusb -d . via popen seems to require less keystrokes than parsing the whole file with descriptions.
Haven’t tried this myself, but libudev’s udev_device_get_property_value should be it; it is used in pulseaudio’s udev-util.c as udev_device_get_property_value(card, «ID_VENDOR_FROM_DATABASE»)) .
Here is a small example I just put together, based on udev-util.c — note that I’ve used an Arduino Duemillanove with FTDI FT232 chip, whose udev path I find using udevadm (see comments in code below), and then I hardcoded it in the below program, udevl.c :
// sudo apt-get install libudev-dev // build with: gcc -o udevl -ludev -Wall -g udevl.c #include #include int main( int argc, char **argv ) < const char *v; char t[256]; struct udev *udev; struct udev_device *card = NULL; if (!(udev = udev_new())) < fprintf(stderr, "Failed to allocate udev context.\n"); return -1; >// $ lsusb | grep FT232 // Bus 002 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC // $ udevadm info --name=/dev/ttyUSB0 --attribute-walk | grep "looking at device" // looking at device '/devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0/ttyUSB0/tty/ttyUSB0' // (that one is under /sys) // hardcode that path below: // udev_get_sys_path(udev) for me: '/sys' sprintf(t, "%s/devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0/ttyUSB0/tty/ttyUSB0", udev_get_sys_path(udev)); fprintf(stdout, " path: %s\n", t); card = udev_device_new_from_syspath(udev, t); fprintf(stdout, " udev_device: 0x%08X\n", (unsigned int)card); if ((v = udev_device_get_property_value(card, "ID_MODEL_FROM_DATABASE")) ) fprintf(stdout, "got ID_MODEL_FROM_DATABASE: %s\n", v); else fprintf(stdout, "failed getting ID_MODEL_FROM_DATABASE: %s\n", v); fprintf(stdout, "Done.\n"); if (card) udev_device_unref(card); if (udev) udev_unref(udev); return 0; > This program (with the Arduino attached) outputs:
$ ./udevl path: /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0/ttyUSB0/tty/ttyUSB0 udev_device: 0x09FBF080 got ID_MODEL_FROM_DATABASE: FT232 USB-Serial (UART) IC Done. . and «FT232 USB-Serial (UART) IC» is the right entry for VID:PID 0403:6001 in usb.ids.