Based on the path, the device is attached to (roughly, starting from the end) configuration 1 (:1.0) of the device attached to port number 4 of device 1-5, connected to USB controller 1 (usb1), connected to the PCI bus. While interesting, this directory path doesn't do us very much good, since it's dependent on how the hardware is physically connected to the computer.
Fortunately, Sysfs also provides a large number of symlinks, for easy access to devices without having to know which PCI and USB ports they are connected to. In /sys/class there is a directory for each different class of device. My /sys/class directory looks like this:
Deleted "My /sys/class directory looks like this:" which then followed with no actual information.
Based on the path, the device is attached to (roughly, starting from the end) configuration 1 (:1.0) of the device attached to port number 4 of device 1-5, connected to USB controller 1 (usb1), connected to the PCI bus. While interesting, this directory path doesn't do us very much good, since it's dependent on how the hardware is physically connected to the computer.
Fortunately, Sysfs also provides a large number of symlinks, for easy access to devices without having to know which PCI and USB ports they are connected to. In /sys/class there is a directory for each different class of device. My /sys/class directory looks like this:
Based on the path, the device is attached to (roughly, starting from the end) configuration 1 (:1.0) of the device attached to port number 4 of device 1-5, connected to USB controller 1 (usb1), connected to the PCI bus. While interesting, this directory path doesn't do us very much good, since it's dependent on how the hardware is physically connected to the computer.
Fortunately, Sysfs also provides a large number of symlinks, for easy access to devices without having to know which PCI and USB ports they are connected to. In /sys/class there is a directory for each different class of device.
The files in /dev are actual devices files which UDEV creates at bootrun time. The directory /sys/class is exported by the kernel at bootrun time, exposing the hierarchy of the hardware through sysfs.
The files in /dev are actual devices files which UDEV creates at boot time. The directory /sys/class is exported by the kernel at boot time, exposing the hierarchy of the hardware through sysfs.
The files in /dev are actual devices files which UDEV creates at run time. The directory /sys/class is exported by the kernel at run time, exposing the hierarchy of the hardware through sysfs.
Usage?
In general you use rules in /etc/udev/rules.d to augment your system. Rules can be constructed to run scripts when various hardware is present.
Once a system is up you can write scripts to work against either /dev or /sys, and it really comes down to personal preferences, but I would usually try and work against /sys and make use of tools such as udevadm to query UDEV for locations of various system resources.
$ udevadm info -a -p $(udevadm info -q path -n /dev/sda) | head -15 Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the udev rules key format. A rule to match, can be composed by the attributes of the device and the attributes from one single parent device. looking at device '/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda': KERNEL=="sda" SUBSYSTEM=="block" DRIVER=="" ATTR{ro}=="0" ATTR{size}=="976773168" ATTR{stat}==" 6951659 2950164 183733008 41904530 16928577 18806302 597365181 580435555 0 138442293 622621324" ATTR{range}=="16" ... Usage?
In general you use rules in /etc/udev/rules.d to augment your system. Rules can be constructed to run scripts when various hardware is present.
Once a system is up you can write scripts to work against either /dev or /sys, and it really comes down to personal preferences, but I would usually try and work against /sys and make use of tools such as udevadm to query UDEV for locations of various system resources.
$ udevadm info -a -p $(udevadm info -q path -n /dev/sda) | head -15 Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the udev rules key format. A rule to match, can be composed by the attributes of the device and the attributes from one single parent device. looking at device '/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda': KERNEL=="sda" SUBSYSTEM=="block" DRIVER=="" ATTR{ro}=="0" ATTR{size}=="976773168" ATTR{stat}==" 6951659 2950164 183733008 41904530 16928577 18806302 597365181 580435555 0 138442293 622621324" ATTR{range}=="16" ...