udev został wprowadzony wraz z kernelem 2.6 i wspiera dynamiczne zarządzanie zawartością /dev. Poprzednia implementacja /dev - devfs jest nie jest aktualnie polecana i wygląda na to że udev będzie (jest) jego następcą. Sama próba porównanie udev vs. defs jest delikatnym tematem dyskusji, także powinieneś przeczytać http://kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs nim do niej przystąpisz :-)
Przez lata, urządzenia dla których mogłeś używać reguł zmieniały się tak jak one same. We współczesnym systemie, udev dostarcza przemyślanego nazewnictwa dla urządzeń typu out-of-the-box, eliminując tym samym potrzebę tworzenia oddzielnych reguł dla każdego z nich. Mimo to, niektórzy użytkownicy, mogą nadal potrzebować możliwości dokładniejszej personifikacji tego aspektu systemu.
Zakładam że, masz poprawnie zainstalowany i uruchomiony udev, wraz z domyślną konfiguracją. Przeważnie to wszystko konfiguruje standardowo Twój Linux podczas instalacji. Dla pewności - nie poruszam tutaj wszystkich aspektów tworzenia reguł, gdyż moim celem jest zaprezentowanie Ci najważniejszych kwestii. Dokładniejsze informacje na ten temat znajdziesz na stronie manuala udev. ( # man udev )
Prezentowane są tutaj przykłady mają na celu tylko zilustrowanie koncepcji. Część z nich jest całkowicie fikcyjna, dlatego też nie cała składnia jest opisana w tekście. Polecam więc najpierw dokładną jej analizę by wszystko zrozumieć.
W typowym systemie opartym na Linuksie, katalog /dev jest używany do magazynowania pliko-podobnych węzłów (ang. node), które odnoszą się do pewnych urządzeń w systemie. Każdy węzeł kieruje do części sytemu / urządzenia które może lecz *nie musi* istnieć. Aplikacje użytkownika używają tych węzłów do komunikacji ze sprzętem, np. serwer X, "nasłuchuje" /dev/input/mice by móc powiązać ruch myszą użytkownika z ruchem wskaźnika na ekranie.
Pierwotnie /dev był zapełniony węzłami do wszystkich urządzeń które mogły pojawić sie w systemie, dlatego jego rozmiar był ogromny. devfs wprowadził wraz ze sobą, zarówno podejście bardziej "manageable" - /dev zwiera jedynie sprzęt który jest podłączony do systemu - jak i inne funkcjonalności. Niestety system generował problemy, których nie można było łatwo naprawić.
udev jest "nowym kierunkiem" w zarządzaniu /dev. Został stworzony by rozwiązać problemowe kwestie poprzednich implementacji / i wprowadzić śmiałe perspektywy. [niech mi ktoś powie co to znaczy 'and provide a robust path forward' - tłum.] /. Żeby tworzenie nazw węzłów w /dev odpowiadało urządzeniom, które są w systemie, udev opiera się na informacjach dostarczonych przez sysfs i regułach stworzonych przez użytkownika. W tej publikacji skupię się na tych ostatnich.
sysfs jest systemem który został wprowadzony wraz z jądrami 2.6. Jest zarządzany przez kernel,i dostarcza podstawowych informacji o urządzeniach obecnie podpiętych do systemu. udev może używać tych danych do tworzenia węzłów które będą zgodne z twoim sprzętem. sysfs jest montowany w /sys i może być przeglądany.
reguły udev są elastyczne i bardzo potężne. Niżej jest parę przykładów, które pokazują co można dzięki nim osiągnąć.
Tworzone tutaj reguły nie nadają się do zastosowania jeżeli nie ma węzła odpowiadającego danemu urządzeniu. Nawet jeśli nie będą poprawne, udev może stworzyć węzeł z domyślną nazwą dostarczoną przez kernel.
Trzymanie się stałego nazewnictwa węzłów daje kilka korzyści. Zakładam, że przykładowo masz dwa urządzenia z pamięcią flash USB - cyfrową aparat i dysk flash. Tym urządzeniom zwykle przydzielane są węzły /dev/sda i /devs/sdb, a dokładniej, wszystko zależy porządku w jakim były one podłączane. To może być powodem problemów, dla użytkowników, którzy chcieliby by były one reprezentowane przez /dev/camera i /dev/flashdisk
udev dostarcza stałego nazewnictwa dla urządzeń typu "out-of-box". To jest bardzo użyteczna cecha, i w wielu przypadkach oznacza że twoja podróż w tym momencie się kończy - nie musisz pisać żadnych reguł.
# ls -lR /dev/disk
Te polecenie działa dla wszelkich "magazynowych" typów (dyski, pamięci flash etc. Na przykład udev stworzył /dev/disk/by-id/scsi-SATA_ST3120827AS_4MS1NDXZ-part3 który jest symlinkiem do mojej głównej partycji, także dzięki niemu pojawia się /dev/disk/by-id/usb Prolific_Technology_Inc._USB_Mass_Storage_Device-part1 kiedy podłączam mojego pendrive'a.
Kiedy wymagana jest decyzja jak nazwać urządzenie i jakie dodatkowe akcje wykonać, udev czyta pliki reguł. Znajdują się one w /etc/udev/rules.d/ a wszystkie muszą mieć końcówkę .rules.
Domyślnie reguły udev są przechowywane w /etc/udev/rules.d/50-udev.rules, ale nie powinieneś wpisywać do niego własnych. Pliki w /etc/udev/rules.d/ są wczytywane w kolejności alfabetycznej, a ta kolejność jest bardzo ważna. Ogólnie zapewne chcesz, aby Twoje własne reguły były wczytywane przed tymi domyślnymi, więc proponuję, abyś utworzył plik /etc/udev/rules.d/ 10-local.rules i wpisywał je do niego.
W pliku .rules, linie zaczynające się od # są uznawane jako komentarze. Każda nie pusta linia jest regułą.
Urządzenie może odpowiadać więcej niż jednej regule. To jest jedna z zalet, np. możemy napisać dwie reguły, z których każda będzie odnosiła sie do tego samego urządzenia, oraz definiowała jego dodatkową nazwę. Obydwie "nazwy" zostaną stworzone, nawet jeśli reguły będą w oddzielnych plikach. Ważne jest by zrozumieć, że udev nie przerywa procesu, kiedy znajdzie pasującą regułę, - kontynuuje szukanie i próbuje stosować każdą która odnosi się do tego urządzenia.
Każda reguła jest skonstruowana z serii par klucz-wartość, które odseparowane są przecinkami.
KERNEL=="hdb", NAME="moj_dysk"
Reguła powyżej zawiera jeden "match key" (KERNEL) i jeden assignment key (NAME). Struktura kluczy i ich ustawień będzie opisana później. Najważniejsza jest wiadomość - iż match key odnosi się do wartości przez "equality operator" - == - podwójny znak równości, podczas gdy assignment key przez "assignment operator" - = - pojedynczy znak równości.
match keys są używane do identyfikacji urządzenia do którego odnosi się reguła, Gdy wszystkie klucze odpowiadają urządzeniu, reguła jest stosowana, a wszelkie akcje (zadania) assignment key są wywoływane. Każda reguła powinna składać sie z przynajmniej jednego match key i jednego assignment key
udev dostarcza kilka różnych match key, które mogą być użyte do dokładnego określenia urządzenia. Oto część najpopularniejszych, inne znajdziesz w manualu.
Po tym jak użyjesz match key do sprecyzowania urządzenia, udev, daje Ci kontrole nad tym co ma się stać później przez asortyment assignment key'ów. Po pełną listę tych ostatnich odsyłam do manuala. Najważniejsze prezentuję niżej:
udev tworzy jeden węzeł dla jednego urządzenia. Jeżeli chciałbyś stworzyć więcej odniesień, powinieneś użyć SYMLINK. Z tym ostatnim, możesz utrzymać listę symlinków, i każdy z nich będzie odnosił się do prawdziwego węzła. Do zarządzania tymi linkami, musimy wprowadzić nowy operator - += . Możesz dołączyć kilkanaście symlinków to listy przez oddzielanie ich spacją.
KERNEL=="hdb", NAME="moj_dysk"
Ta reguła mówi "Znajdź urządzenie nazwane przez kernel jako hdb, i zamiast nazywania go hdb, nazwij węzeł "moj_dysk". Pojawi się on w /dev/moj_dysk.
Z kolei ta mówi: znajdź urządzenie nazwane przez kernel jako hdb I którego sterownikiem jest ide-disk. Nazwij węzeł domyślną nazwą i stwórz symlink do niego o nazwie mojdysk. Nie zdefiniowaliśmy nazwy urządzenia, więc udev użyje domyślnejKERNEL=="hdb", DRIVER=="ide-disk", SYMLINK+="mojdysk"
KERNEL=="hdc", SYMLINK+="cdrom cdrom0"
Ta reguła tworzy dwa symlinki /dev/cdrom i /dev/cdrom0 które odnoszą się do /dev/hdc. Znowu, brak NAME, więc zostaje użyta domyślna nazwa z kernela
match key wprowadzają jak dotąd tylko wsparcie dla wyszukiwania. W rzeczywistości potrzebujemy większej kontroli chcemy identyfikować urządzenia w oparciu o zaawansowane ustawienia takie jak kody producenta, kody produktów, ich serie, rozmiary, liczbę partycji etc.
Większość sterowników dostarcza takie informacje do sysfs, i udev pozwala nam włączyć sysfs-matching do naszych reguł używając klucza SYSFS z nieco inną konstrukcją.
KERNEL=="sda", SYSFS{model}=="ST3120827AS", SYMLINK+="my_hard_disk"
SUBSYSTEM=="block", SYSFS{size}=="234441648", SYMLINK+="my_disk"
BUS=="usb", SYSFS{manufacturer}=="OLYMPUS", SYSFS{product}=="X250,D560Z,C350Z", SYMLINK+="cameraMamy tutaj przykłady reguł które wyszukują informacje z sysfs. Bardziej szczegółowe informacje, które pomogą Ci pisać reguły oparte na atrybutach sysfs.
Kiedy piszesz reguły, które będą opisywały podobne urządzenia, przydadzą Ci się operatory umożliwiające zamianę tekstu . Możesz je prosto zawrzeć w zadaniu swojej reguły (wartości assignment key), i udev wywoła je.
Najpopularniejsze operatory to %k i %n. Operator %k oceni jaką nazwę nadać na podstawie danych kernel'a - np. sda3 dla urządzenia. Operator %n szacuje numer dla urządzenia np. numer partycji.
udev także dostarcza także kilka innych operatorów podstawień, dla bardziej zaawansowanych zadań - jak zwykle odsyłam do manuala. Istnieje także inna składnia tych operatorów - jest to $kernel i $number. Z tego też powodu, jeżeli chcesz wyszukać $ musisz napisać $$, a dla %, %% .
Oto przykład zastosowania tych operatorówKERNEL=="mice", NAME="input/%k" KERNEL=="loop0", NAME="loop/%n", SYMLINK+="%k"
Pierwsza reguła zapewnia, że węzły myszy pojawią się wyłącznie w /dev/input (standardowo jest to /dev/mice). Druga reguła, mówi, że węzeł urządzenia loop0 zostanie stworzony w /dev/loop/0, ale udev ma jeszcze stworzyć symlink /dev/loop0.
Używanie tych reguł stoi pod znakiem zapytania, jeżeli przepiszemy je bez użycia operatorów podstawień. Prawdziwa potęga tych ostatnich zostanie ujawniona w następnej sekcji.Tak jak i dopasowywanie łańcuchów, udev zezwala do używania shellowych wzorców. Wpierane są trzy rodzaje:
Oto kilka przykładów które zawierają powyższe wzorce. Zauważ użycie operatorów postawień.
KERNEL=="fd[0-9]*", NAME="floppy/%n", SYMLINK+="%k" KERNEL=="hiddev*", NAME="usb/%k"
Pierwsza reguła dopasowuje wszystkie napędy dyskietek i zapewnie że ich węzły są tworzone w /dev/floppy a także udev ma stworzyć symlinki do nich używając standardowych nazw. Druga reguła mówi, iż urządzenia hiddev będą prezentowane tylko w /dev/usb.
Koncepcja używania informacji z sysfs, pokrótce została wcześniej wyjaśniona. Żeby pisać reguły oparte na tych informacjach musisz najpierw znać nazwy atrybutów i ich obecne wartości.
sysfs jest aktualnie bardzo prostą strukturę. Jest ona logicznie podzielona na katalogi. Każdy z nich zawiera "pliki" (atrybuty), a te z kolei pojedyncze wartości.
Symlinki które są tam obecne, mogą odnosić się do innych części drzewa. Przykładowo w moim systemie katalog /sys/block/sda jest ścieżką do mojego dysku. Jest on także powiązany symlinkiem z kontrolerem przez /sys/block/sda/device a także ze sterownikiem w /sys/block/sda/device/driver/
Kiedy tworzysz reguły oparte na tych informacja, musisz po prostu odwoływać się do plików w tej ścieżce. Dla przykładu - chcę odczytać rozmiar swojego dysku, w tym celu wykonuję:
# cat /sys/block/sda/size 234441648
W regule, użyję w tym celu składni SYSFS{size}=="234441648" do zidentyfikowania tego dysku.
udev zezwala na zdefiniowanie dodatkowych zadań dla reguł, których celem jest kontrola tego kto jest właścicielem węzła lub też jaka grupa może z niego korzystać.
GROUP pozwala zdefiniować, która grupa posiada ten węzeł. Oto w przykład, w którym tylko członkowie grupy video będą mogli korzystać z frambuffer'a
KERNEL=="fb[0-9]*", NAME="fb/%n", SYMLINK+="%k", GROUP="video"
OWNER może być nieco mniej użyteczny, pozwala określić który użytkownik będzie właścicielem węzła. Załóżmy np. że tylko John powinien mieć dostęp do stacji dyskietek
KERNEL=="fd[0-9]*", OWNER="john"
udev standardowo tworzy węzły z uprawnieniami 0660 (odczyt / zapis dla właściciela i grupy). Jeżeli chcesz to zmienić, musisz skorzystać z MODE. W tym przykładzie każdy może odczytać / zapisać dane do inotify:
KERNEL=="inotify", NAME="misc/%k", SYMLINK+="%k", MODE="0666"
W pewnych sytuacjach, zachodzi potrzeba uzyskania większej elastyczności niż tej którą standardowo zapewnia udev. W tym przypadku, musisz zlecić udev uruchomienie zewnętrznego programu, a dane ze standardowego wyjścia posłużą do nazwania węzła.
Aby skorzystać z tej możliwości, musisz w opcji PROGRAM określić bezpośrednią ścieżkę do programu (bez żadnych parametrów), a później użyć operatora %c w NAME/SYMLINK.
Te przykłady odnoszą się do fikcyjnego programu /bin/device_namer. Przyjmuje on jeden argument którym jest nazwa urządzenia podana przez kernel. Opierając się na tej informacji program zwraca zwykły stumień stdout podzielony na kilka partii. Każda z nich to jedno słowo, a oddzielone są one od siebie spacją.
W pierwszym przykładzie zakładamy, że device_namer zwraca partie, a każda z nich posłuży do stworzenia symlinka do urządzenia zawartego w zapytaniu.
KERNEL=="hda", PROGRAM="/bin/device_namer %k", SYMLINK+="%c"
Kolejny przykład zakłada że device_namer zwraca dwie części - pierwsza jest nazwą urządzenia, a druga, nazwą dodatkowego symlinka. W tym momencie musimy wporawdzić oprator %c{N}, który zwraca N-tą parię danych.
KERNEL=="hda", PROGRAM="/bin/device_namer %k", NAME="%c{1}", SYMLINK+="%c{2}"Teraz przyjmijmy, że device_namer zwraca, w pierwszej części nazwę urządzenia, a każda następna partia posłuży że utworzenie symlinka do tego urządzenia. Musimy tutaj z korzystać z %c{N+}, który odnosi się kolejno do N, N+1, N+2 ... części danych, dopóki nie otrzyma EOT.
KERNEL=="hda", PROGRAM="/bin/device_namer %k", NAME="%c{1}", SYMLINK+="%c{2+}"Z tych danych możemy skorzystać nie tylko w NAME i SYMLINK. Przykład poniżej, korzysta z fikcyjnego programu do określenia która grupa powinna mieć dostęp do urządzenia.
KERNEL=="hda", PROGRAM="/bin/who_owns_device %k", GROUP="%c"
Jest jeszcze inna przyczyna pisanie reguł - uruchamianie programów kiedy jakieś urządzenie jest podłączane lub odłączane. Przykładowo, możesz np. uruchamiać skrypt który automatycznie pobierze wszystkie zdjęcia z twojego aparatu na dysk kiedy jest on podłączony.
Nie możesz tego mylić z opcją PROGRAM opisywaną wcześniej. Jest ona używana do uruchamiania programów które tworzą nazwy urządzeń (i oczywiście nie powinny niczego innego robić poza tym ) Kiedy są one wywoływane, węzeł nie jest jeszcze stworzony, więc działanie urządzenia nie jest jeszcze możliwe.
Funkcjonalność wspomniana tutaj, umożliwia tobie uruchomienie aplikacji po tym jak węzeł jest już na swoim miejscu, program ten uruchamiany jest wraz z danym urządzeniem. Nie wolno jednak uruchamiać ich na dłuższy czas, gdyż udev wstrzymuje swoje działanie gdy one działają.
Oto przykład użycia RUN:
KERNEL=="sdb", RUN+="/usr/bin/my_program"
Kiedy /usr/bin/my_program zostaje uruchomiony, część środowiska udev jest dostępna w postaci zmiennych, zawierają one klucze takie jak SUBSYSTEM. Możesz użyć zmiennej ACTION do wykrycia czy urządzenie zostało właśnie podłączone czy też odłączone. Przyjmuje ona wartości (odpowiednio) "add" lub "remove".
udev dostarcza klucz ENV dla zmiennych które mogą zostać użyte przy dopasowywaniu, lub przy zadaniach. W przypadku zadań, możesz ustawić zmienna które wykorzystasz później. Możesz także użyć ich w zewnętrznych programach wywoływanych sposobami wspomnianymi wcześniej. Przykładowa reguła która tworzy zmienną pokazana jest niżej:
KERNEL=="fd0", SYMLINK+="floppy", ENV{some_var}="value"W przypadku dopasowywania, musisz jedynie ustawić zmienną na podaną wartość jeżeli reguła ma być wykonana.
KERNEL=="fd0", ENV{an_env_var}=="yes", SYMLINK+="floppy"Ta reguła stworzy /dev/fd0 jedynie w przypadku gdy wartość an_env_var będzie równa "yes". Zauważ że środowisko w którym działa udev nie jest takie same jak te do którego ma dostęp użytkownik w konsoli.
Oto opcje które mogą być ustawione w OPTIONS:
Kiedy włączam swoją drukarkę, jest jej przydzielany węzeł /dev/lp0. Nie usatysfakcjonowany tą nazwą postanowiłem użyć udevinfo w celu ułatwiena sobie napisania reguły która udostępni te urządzenie pod inną.
# udevinfo -a -p $(udevinfo -q path -n /dev/lp0)
looking at the device chain at '/sys/devices/pci0000:00/0000:00:02.1/usb3/3-3':
BUS=="usb"
SYSFS{manufacturer}=="EPSON"
SYSFS{product}=="USB Printer"
SYSFS{serial}=="L72010011070626380"Na podstawie powyższych danym stworzyłem coś takiego:
BUS=="usb", SYSFS{serial}=="L72010011070626380", SYMLINK+="epson_680"Mój aparat identyfikuje siebie jako dodatkowy dysk podłączony przez magistralę USB, używając SCSI. Aby dostać się do zdjęć, muszę zamontować urządzenie i przekopiować zdjęcia na mój dysk.
Nie wszystkie aparaty działają w ten sposób: część znich nie identyfikuje się jako dodatkowy dysk, tak jak te wspierane przez gphoto2.
Przeważnie problemy z aparatami cyfrowymi, dotyczą tego iż one same identyfikują się jako dysk z jedną partycją - w tym przypadku /dev/sdb z /dev/sdb1. Węzeł sdb jest bezużyteczny, ale sdb już nie - jest to właśnie te urządzenie które chcę zamontować. W tym momencie mamy problem ponieważ, wszelkie przydatne wartości atrybutów które udevinfo zwraca dla /dev/sdb1 są identyczne z tymi dla /dev/sdb. W rezultacie, Twoja reguła prawdopodobnie dopasuje fizyczny dysk (sdb) jak i jego partycję (sdb1), a przecież chcemy uniknąć wykrywania tego pierwszego. Z tego też powodu musi być ona nieco inna.
Aby to osiągnąć, musisz sobie uświadomić, jakie są różnice między sdb i sdb1. Nie szukając daleko - różnią się nazwą. Więc możemy użyć wzorca by tą nazwę wykryć.
# udevinfo -a -p $(udevinfo -q path -n /dev/sdb1)
looking at device '/devices/pci0000:00/0000:00:02.0/usb2/2-1/2-1:1.0/host6/target6:0:0/6:0:0:0':
ID=="6:0:0:0"
BUS=="scsi"
DRIVER=="sd"
SYSFS{rev}=="1.00"
SYSFS{model}=="X250,D560Z,C350Z"
SYSFS{vendor}=="OLYMPUS "
SYSFS{scsi_level}=="3"
SYSFS{type}=="0"Reguła:
KERNEL=="sd?1", BUS=="scsi", SYSFS{model}=="X250,D560Z,C350Z", SYMLINK+="camera"Dysk USB jest bardzo podobny do tego w aparacie opisywanym wcześniej, jednak wzorce sięróżnią. W przypadku aparatu, wspomniałem że nie jestem zainteresowany węzłem sdb - jest on potrzeby tylko do partycjonowania (np. z fdiskiem), więc niby dlaczego chciałbym tworzyć partycje w aparacie?!
Ale oczywiście w przypadku dysku 100GB, jest to zupełnie zrozumiałe że chcę mieć odpowiedni podział. W związku z tym, skorzystamy z udev'owego zastępowania łańcuchów ( string substitutions )
BUS=="usb", KERNEL=="sd*", SYSFS{product}=="USB 2.0 Storage Device", NAME="%k", SYMLINK+="usbhd%n"Ta reguła stworzy symlinki:
Czytniki kart (CompactFlash, SmartMedia, etc), są przykładem jeszcze innej grupy urządzeń USB, które z kolei wymają innego podejścia.
Te urządzenia, nie informują komputera o zmianie nośnika. Więc, jeśli podłączysz urządzenie bez karty, a następnie je włączysz, komputer nie zareaguje, a nie będziesz miał np. węzła sdb1 nośnika.
Istnieje tylko jedno rozwiązanie - skorzystać z opcji all_partitions która stworzy 16 węzłów partycji tego urządzenia.
BUS=="usb", SYSFS{product}=="USB 2.0 CompactFlash Reader", SYMLINK+="cfrdr%n", OPTIONS+="all_partitions"Teraz będziez miał węzły cfrdr, cfrdr1, cfrdr2, cfrdr3, ..., cfrdr15
Posiadam dwa napędy, czytnik DVD (hdc), i nagrywarkę dvd (hdd). Nie spodziewam się zmian w kwestii podłączeń i nazw więc nie będę tego ruszał do czasu aktualizacji systemu. Jednakże, część osób, chciałaby, aby węzły były nazwane dla wygody np. /dev/dvd.
Tak jak już pewnie się domyślasz reguły będą podobne. Oto przykład dla mojego systemu
BUS=="ide", KERNEL=="hdc", SYMLINK+="dvd", GROUP="cdrom" BUS=="ide", KERNEL=="hdd", SYMLINK+="dvdrw", GROUP="cdrom"
Pomimo tego że odnosimy się do nich przez nazwy, węzły nie są z nimi tak samo jak we wcześniejszych przykładach "skojarzone". Ale pomimo tego, pisanie reguł wygląda identycznie
Najbardziej sensownym rozwiązaniem jest dopasowywanie adresu MAC twojej sieciówki, ponieważ jest on unikalny. Jednakże. upewnij się że używasz dokładnie tego adresu który pokazuje udevinfo, ponieważ reguła może nie działać.
# udevinfo -a -p /sys/class/net/eth0
looking at class device '/sys/class/net/eth0':
SYSFS{address}=="00:52:8b:d5:04:48"Przykład:
KERNEL=="eth*", SYSFS{address}=="00:52:8b:d5:04:48", NAME="lan"Załóżmy, że pracujesz na najnowszym kernelu, ze wsparciem inotify. udev automatycznie monitoruje katalog reguł i odrazu ozwierciedla zmiany tam dokomnywane.
Jednak mimo to, udev nie będzie automatycznie sprawdzał wszystkich urządzeń i realizował od nowa naszych reguł od razu. Przykładowo, jezeli stworzysz regułe która ma na celu dodanie symlinka dla twojego aparatu, kiedy jest on podłoczny, nie powinieneś się spodziewać że natychmiast ten symlink się pojawi.
Aby tak się stało , musisz ponownie podłączyć urządzenie, lub w przypadku urządzeń "non removable" uruchomić udevtrigger.
Jeżeli twój kernel nie wspiera inotidfy, nowe reguły nie będą wykrywane automatycznie. W tej sytuacji musisz uruchomić udevcontrol reload_rules po każdej edycji, aby zmiany odniosły skutek.
Jeżeli znasz scieżkę do urządzenia w sysfs, możesz użyć udevtest do pokazania działań które może podjąć udev. To może pomóc Ci w namierzaniu błędów. Np. załóżmy że chce naprawić reguła która działana /sys/class/sound/dsp.
Zauważ że prefix /sys został pominięcty przy wpisywaniu go wraz z udevtest, ponieważ ten ostatni operuje bezpośrednio na ścieżce do urządzenia. Zwróć uwagę na to że te narzędzie służy jedynie do testowania / naprawiania, nie tworzy ono żadnych węzłów pomimo tego co sugeruje nam wyjście!# udevtest /class/sound/dsp main: looking at device '/class/sound/dsp' from subsystem 'sound' udev_rules_get_name: add symlink 'dsp' udev_rules_get_name: rule applied, 'dsp' becomes 'sound/dsp' udev_device_event: device '/class/sound/dsp' already known, remove possible symlinks udev_node_add: creating device node '/dev/sound/dsp', major = '14', minor = '3', mode = '0660', uid = '0', gid = '18' udev_node_add: creating symlink '/dev/dsp' to 'sound/dsp'
W oryginale ten został napisany przez Daniela Drake'a
<dan@reactivated.net>
Jeżeli szukasz pomocy, powiniene? wysłać emaila na listę linux-hotplug: linux-hotplug-devel@lists.sourceforge.net.
Copyright (C) 2003-2006 Daniel Drake. This document is licensed under the GNU General Public License, Version 2.
Tłumaczenie wykonał Radosław Gierwiało
<gierwialo@gmail.com>
Najnowsza wersja tłumaczenia zawsze dostępna pod adresem:
http://radoslaw.gierwialo.com/publikuje/tworzenie_regul_udev.html
Oryginał dostępny pod: http://www.reactivated.net/writing_udev_rules.html