W takim razie, co dokładnie było nie tak z grupą plików statycznych /dev? Najwyraźniej jest wystarczająco niezadowalający, aby programiści wymyślili to koło 3 razy teraz ( devfs-> udev + HAL-> udev), a teraz najwyraźniej wchodzi również w program Grand Unified Init, więc cztery razy.

Pamiętam, kiedy po raz pierwszy zacząłem używać Linuksa wiele lat temu, dziwiąc się, że pomimo twierdzenia, że ​​„wszystko jest plikiem”, nie ma go /dev/eth0(to później miało sens, ponieważ nie jest to urządzenie typu char lub block - chociaż typ urządzenia „pakietowego” byłoby interesujące ...). Biorąc to pod uwagę, dlaczego program obsługujący drzewo plików char i block urządzeń jest również odpowiedzialny za urządzenia sieciowe? Widziałem niejasne odniesienia do „elastyczności”, ale co to dodaje do tego, powiedzmy, ifconfig (8) po prostu patrząc /proc/net/dev? Wiem na przykład, NetworkManager nie będzie w najbliższym czasie w sieci ani w OpenBSD, ponieważ zależy od tego udev, o czym żaden zespół nie chce pisać; co ja nie/devktóre są już ujawnione na wiele sposobów przez jądro (i żaden z nich nie jest /dev!).

Czy to tylko z powodu hotplugging? Czy były problemy z jądrem, które tylko słuchało fizycznych magistrali i ładowało odpowiednie moduły w komunikacie „dodane urządzenie”? A może, Boże, nie robi tego faktyczny administrator? Pamiętam, jak na początku 2000 roku moje serwery czasami inicjalizowały swoje karty sieciowe w nieoczekiwanej kolejności, i przypuszczam, że sensowne jest, aby decyzje dotyczące nazewnictwa były podejmowane w obszarze użytkownika (chociaż wtedy nie było to strasznie trudne do naprawienia), ale to wygląda jak młot karalucha. (A może ten problem dotyczy przypadków użycia Nie myślę o wiele trudniejszych niż serwery lub komputery stacjonarne, które są moim doświadczeniem.)

Tak więc, jasno wyrażając moje pytanie: jakie problemy faktycznie rozwiązuje udev i dlaczego devfs, HAL i / lub zwykły stary plik nie rozwiązał ich? Czy jest jakiś szczególny powód, dla którego wiele różnych rzeczy (hotplugging, ogólne zarządzanie urządzeniami, zarządzanie urządzeniami sieciowymi, nazewnictwo urządzeń, priorytet sterowników itp.) Ma być jednym programem?

Dwie kolejne rzeczy: przejście Linuksa na korporację i inne duże serwery ujawniało zakłócenia statyczne /dev. Zaawansowana technologia, zarówno wśród konsumentów, jak i przedsiębiorstw, ujawniała static / dev jako żart. [Ta odpowiedź wypełnia większą część historii, nie szczególnie dlaczego devfs zastąpiono udev].

Wyczerpanie dużej i małej liczby miejsc

/devpliki są identyfikowane w jądrze przez ich główne i podrzędne numery. Jądro nigdy tak naprawdę nie troszczyło się o nazwę (i możesz na przykład mv /dev/sda /dev/disk-1nadal działać, ale oczywiście programy nie wiedziałyby, gdzie ją znaleźć).

W przypadku ustawienia statycznego /devmusisz przypisać numer główny / pomocniczy dla każdego potencjalnego urządzenia, które mogłoby istnieć. Liczby te muszą być unikalne na całym świecie, ponieważ są wysyłane w ramach dystrybucji, a nie tworzone na żądanie. Problem polega na tym, że każda z nich to liczby 8-bitowe - zakres wynosi 0–255.

Początkowo na przykład Linux zaczynał się od 8,0 sda, 8,1 sda1, 8,16 sdb itp. Ale ludzie ciągle dodawali coraz więcej dysków do maszyn, szczególnie gdy rozważamy takie rzeczy jak Fibre Channel. W pewnym momencie dodano więcej liczb 65–71 dla większej liczby dysków. Później numery główne 128–135. A jednak ludzie wciąż chcieli więcej dysków ...

Pojawiły się formaty tablic partycji, takie jak GPT, obsługujące więcej partycji na dysk. I oczywiście inne urządzenia jadły przez przestrzeń numeryczną: różne kontrolery RAID, logiczne zarządzanie woluminami itp.

Wynik końcowy można zobaczyć na liście urządzeń LANANA Linux . Jeśli spojrzysz na listę 2.6 (jedyną, która wciąż tam jest), wiele blokowych liczb głównych przez 200 (maks .: 255) - jest używanych. Oczywiście liczby by się skończyły.

Zmiana na większą liczbę nie była łatwa. Zmienia ABI jądra. W zależności od systemu plików zmienia układ na dysku. Ale oczywiście większość z tych urządzeń nie istniała w żadnym systemie, nawet na tym, na którym brakowało dysków SCSI, zapewne było mnóstwo wolnych rzeczy - prawdopodobnie nie potrzebował dysku twardego IBM XT, na przykład.

Dzięki dynamice /devdystrybucja nie musi wysyłać numerów urządzeń. Nie muszą już być globalnie wyjątkowe. Nie muszą nawet być wyjątkowe w obuwiu.

Nazwy urządzeń były nieprzewidywalne

Kiedyś przypisywanie numeru do wszystkiego było naprawdę łatwe. Tablica miała dwa kanały IDE; każdy kanał IDE obsługiwał jeden master i jeden slave. Możesz przypisać w kolejności kanałów oraz w kolejności master-then-slave. hdaStaje się więc pierwszym kanałem, mistrzu; hdbpierwszy kanał, slave; hdcdrugi kanał, master; itp. Były przewidywalne i stabilne. Mogą ulec zmianie, jeśli dodasz nowy dysk lub go usuniesz, ale przy braku zmiany sprzętu były statyczne.

Możesz włożyć /dev/hda1swój /etc/fstabi mieć pewność, że będzie działał, przynajmniej w przypadku braku zmian sprzętowych.

IDE tak działało. Nic po tym nie robi.

SATA wydaje się prosta: jeden port, jeden dysk. Ale nie tak; pozwala na pomnożenie portów. I pozwala na wymianę. Mimo braku zmian sprzętowych nadal można nadal działać mapowanie.

USB jest znacznie gorszy. To nie tylko pozwala na hot swap, jest to typowe. Ludzie cały czas podłączają dyski flash USB. Ponadto, sondowanie może zająć trochę czasu - i może się zmieniać, kiedy tylko ma na to ochotę (np. Po włączeniu lub wyłączeniu trybu pamięci USB w telefonie). Firewire jest podobny. Z żadną z nich nie możesz naprawdę stworzyć stabilnego mapowania.

Dyski podłączone do sieci nie mają żadnej właściwej kolejności portów. Jądro używa tylko tej kolejności, w jakiej się pojawiły. To samo z woluminami logicznymi.

Poszukiwanie prędkości rozruchu również pogorszyło sytuację. Początkowo jądro chętnie siedziało i czekało dość długo na, na przykład, na zainicjowanie wszystkich urządzeń USB. Aby w pełni sondować wszystkie magistrale SCSI itp. Sondy te zostały przekształcone w zadania w tle; boot nie będzie już na nich czekać. Urządzenia są dodawane po zakończeniu sond.

Więc jądro zostało, mniej więcej, „w jakiejkolwiek kolejności się pojawią”. Oznaczało to, że wiele rodzajów urządzeń może i zmieniało kolejność przy każdym rozruchu - to, co było przy jednym rozruchu, /dev/sdbbyło przy innym rozruchu /dev/sdc. To sprawia, że ​​pomysł statyczny /devjest żartem.

Podsumowanie

Kiedy weźmiesz kombinację statyczności za /devcoraz bardziej bez znaczenia z powodu nieprzewidywalnych zamówień sond urządzeń i kontynuujesz przydzielanie statycznych liczb głównych / drugorzędnych, co prowadzi do znacznej pracy, aby się nie wyczerpać, staje się jasne, dlaczego programiści Linuksa zdecydowali się przejść na dynamikę /dev.

Dobre pytanie.

W pewnym sensie ten argument można odwrócić: ponieważ jądro 2.6.13 wprowadziło nową wersję uevent, musiało się zdarzyć, devfsże trzeba będzie ponownie napisać, aby skorzystać z nowych funkcji interfejsu. W pewnym sensie pytaniem powinno być, dlaczego zmiana jądra.

Jednak biorąc to pod uwagę, twoje pytanie znajduje się w artykule w Wikipedii :

W przeciwieństwie do tradycyjnych systemów uniksowych, w których węzły urządzeń w katalogu / dev były statycznym zestawem plików, menedżer urządzeń udev w systemie Linux dynamicznie udostępnia tylko węzły urządzeń faktycznie obecnych w systemie. Chociaż devfs zapewniały podobną funkcjonalność, Greg Kroah-Hartman przytoczył wiele powodów, dla których wolałby implementację niż devfs:

1) udev obsługuje trwałe nazywanie urządzeń, które nie zależy na przykład od kolejności, w jakiej urządzenia są podłączone do systemu. Domyślna konfiguracja udev zapewnia trwałe nazwy urządzeń pamięci masowej. Każdy dysk twardy jest rozpoznawany po unikalnym identyfikatorze systemu plików, nazwie dysku i fizycznej lokalizacji na sprzęcie, do którego jest podłączony.

2) udev działa całkowicie w przestrzeni użytkownika, w przeciwieństwie do przestrzeni jądra devfs. Jedną konsekwencją jest to, że udev przeniósł strategię nazewnictwa z jądra i może uruchamiać dowolne programy, aby skomponować nazwę urządzenia z właściwości urządzenia, przed utworzeniem węzła; tam cały proces jest również przerywany i przebiega z niższym priorytetem.

Powinienem chyba dodać, że dzięki udev race conditionunika się możliwości , która w zasadzie podważała nazewnictwo urządzeń w devfs i hotplug. Innymi słowy: w devfs nie było sposobu, aby zapewnić, że twój lewy port ethernetowy zostanie wywołany, eth0a jego skrajny eth1prawy, co utrudni (jako czysty przykład) konfigurację routerów (jeden port do WAN, jeden port do LAN) wprowadzić w życie.

Przyjęcie schematu nazewnictwa dysków opartego na GUID to kolejna zaleta, a przeniesienie całego procesu do przestrzeni użytkownika jest jeszcze większe: czy przeszukałeś tę stronę, aby zobaczyć, ile osób pisze własne reguły udev?

Jako prosty przykład korzyści wynikających z posiadania udev w przestrzeni użytkownika, sprawdź to lub inne pytanie , zarówno na tej samej stronie.