Pliki w /devto rzeczywiste pliki urządzeń, które UDEV tworzy w czasie wykonywania. Katalog /sys/classjest eksportowany przez jądro w czasie wykonywania, odsłaniając hierarchię sprzętu sysfs.
Z samouczka libudev i Sysfs
fragment
W systemach Unix i podobnych do Unixa dostęp do urządzeń można uzyskać za pomocą specjalnych plików (zwanych także plikami urządzeń lub węzłami) znajdujących się w katalogu / dev. Pliki te są odczytywane i zapisywane tak jak zwykłe pliki, ale zamiast zapisywać i odczytywać dane na dysku, komunikują się bezpośrednio ze sterownikiem jądra, który następnie komunikuje się ze sprzętem. Istnieje wiele zasobów online bardziej szczegółowo opisujących pliki / dev. Tradycyjnie te specjalne pliki zostały utworzone w czasie instalacji przez dystrybucję za pomocą polecenia mknod. W ostatnich latach systemy Linux zaczęły używać udev do zarządzania tymi plikami / dev w czasie wykonywania. Na przykład udev utworzy węzły po wykryciu urządzeń i usunie je po usunięciu urządzeń (w tym urządzeń typu hotplug w czasie wykonywania). Tą drogą,
kolejny fragment
Katalogi w Sysfs zawierają heirarchię urządzeń, ponieważ są one podłączone do komputera. Na przykład na moim komputerze urządzenie hidraw0 znajduje się pod:
/sys/devices/pci0000:00/0000:00:12.2/usb1/1-5/1-5.4/1-5.4:1.0/0003:04D8:003F.0001/hidraw/hidraw0
Na podstawie ścieżki urządzenie jest podłączone (z grubsza, zaczynając od końca) do konfiguracji 1 (: 1.0) urządzenia podłączonego do portu nr 4 urządzenia 1-5, podłączonego do kontrolera USB 1 (usb1), podłączonego do Magistrala PCI. Chociaż ta ścieżka katalogu jest interesująca, nie robi nam wiele dobrego, ponieważ zależy od tego, jak sprzęt jest fizycznie podłączony do komputera.
Na szczęście Sysfs zapewnia także dużą liczbę dowiązań symbolicznych, umożliwiając łatwy dostęp do urządzeń bez konieczności wiedzieć, do których portów PCI i USB są one podłączone. W katalogu / sys / class znajduje się katalog dla każdej innej klasy urządzenia.
Stosowanie?
Zasadniczo używasz reguł, /etc/udev/rules.daby ulepszyć swój system. Reguły można konstruować tak, aby uruchamiały skrypty, gdy obecny jest inny sprzęt.
Kiedy system jest gotowy można pisać skrypty do pracy wbrew albo /devalbo /sys, a tak naprawdę sprowadza się do osobistych preferencji, ale ja zwykle spróbować pracy przed /sysi korzystać z narzędzi, takich jak udevadmna udev zapytań dla lokalizacji różnych zasobów systemowych.
$ 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"
...