udev - udev

udev
Deweloper(zy) Greg Kroah-Hartman i Kay Sievers
Pierwsze wydanie listopad 2003 ; 17 lat temu ( 2003-11 )
Wersja stabilna 249 (07.07.2021 ; 3 miesiące temu ) [±] ( 2021-07-07 )
Magazyn
Napisane w C
System operacyjny Jądro Linuksa
Rodzaj Węzeł urządzenia
Licencja GPLv2
Strona internetowa Oficjalna strona internetowa

udev (przestrzeń użytkownika /dev) to menedżer urządzeń dla jądra Linux . Jako następca devfsd i hotplug, udev zarządza głównie węzłami urządzeń w katalogu /dev . Jednocześnie udev obsługuje również wszystkie zdarzenia związane z przestrzenią użytkownika zgłaszane podczas dodawania lub usuwania urządzeń sprzętowych z systemu, w tym ładowanie oprogramowania układowego zgodnie z wymaganiami niektórych urządzeń.

Racjonalne uzasadnienie

Jest to system operacyjny „s kernel , który jest odpowiedzialny za dostarczanie abstrakcyjny interfejs sprzętu z resztą oprogramowania. Jako jądro monolityczne The kernel robi dokładnie to, a sterowniki są częścią jądra Linuksa, które stanowią ponad połowę jego kodu źródłowego. Dostęp do sprzętu można uzyskać poprzez wywołania systemowe lub przez ich węzły urządzeń .

Aby móc radzić sobie z urządzeniami peryferyjnymi, które obsługują hotplug w sposób przyjazny dla użytkownika, część obsługi wszystkich tych urządzeń sprzętowych obsługujących hotplug została przekazana z jądra do demona działającego w przestrzeni użytkownika. Uruchamianie w przestrzeni użytkownika służy do celów bezpieczeństwa i stabilności.

Projekt

Sterowniki urządzeń są częścią jądra Linux, w którym ich podstawowe funkcje obejmują wykrywanie urządzeń, wykrywanie zmian stanu urządzeń i podobne funkcje sprzętowe niskiego poziomu. Po załadowaniu sterownika urządzenia do pamięci z jądra, wykryte zdarzenia są wysyłane do demona udevd w przestrzeni użytkownika. To menedżer urządzeń, udevd , wyłapuje wszystkie te zdarzenia, a następnie decyduje, co będzie dalej. W tym celu udevd ma bardzo obszerny zestaw plików konfiguracyjnych, które administrator komputera może dostosować do swoich potrzeb.

  • W przypadku podłączenia nowego urządzenia pamięci masowej przez USB, udevd jest powiadamiane przez jądro i samo powiadamia demona udisksd. Ten demon mógł następnie zamontować systemy plików.
  • W przypadku podłączenia nowego kabla Ethernet do karty sieciowej Ethernet, udevd jest powiadamiane przez jądro i samo powiadamia demona NetworkManagera. Demon menedżera sieci może uruchomić klienta dhclient dla tej karty sieciowej lub skonfigurować zgodnie z ręczną konfiguracją.

Złożoność takiego postępowania zmusza autorów aplikacji do ponownego zaimplementowania logiki obsługi sprzętu. Niektóre urządzenia sprzętowe wymagają również uprzywilejowanych programów pomocniczych, aby przygotować je do użycia. Muszą one być często wywoływane w sposób, który może być niewygodny do wyrażenia za pomocą modelu uprawnień Unix (na przykład, pozwalając użytkownikom na dołączanie do sieci bezprzewodowych tylko wtedy, gdy są zalogowani do konsoli wideo). Autorzy aplikacji wykorzystują pliki binarne setuid lub uruchamiają demony usług, aby zapewnić własną kontrolę dostępu i separację uprawnień, potencjalnie wprowadzając za każdym razem luki w zabezpieczeniach.

HAL został stworzony, aby sobie z tym poradzić, ale obecnie jest przestarzały w większości dystrybucji Linuksa.

Przegląd

W przeciwieństwie do tradycyjnych systemów Unix , 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 dla urządzeń faktycznie obecnych w systemie. Chociaż devfs zapewniały podobną funkcjonalność, Greg Kroah-Hartman przytoczył kilka powodów, dla których preferował udev nad devfs:

  • udev obsługuje trwałe nazewnictwo urządzeń, które nie zależy na przykład od kolejności podłączania urządzeń 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.
  • udev wykonuje się całkowicie w przestrzeni użytkownika , w przeciwieństwie do przestrzeni jądra devfs . Jedną z konsekwencji jest to, że udev przeniósł politykę nazewnictwa z jądra i może uruchamiać dowolne programy, aby skomponować nazwę urządzenia z właściwości urządzenia, zanim węzeł zostanie utworzony; tam cały proces jest również przerywany i przebiega z niższym priorytetem.

Całość podzielona jest na trzy części:

  • Biblioteka libudev, która umożliwia dostęp do informacji o urządzeniu; został włączony do pakietu oprogramowania systemd 183.
  • Demon przestrzeni użytkownika udevd, który zarządza wirtualnym /dev .
  • Administracyjne narzędzie wiersza polecenia udevadm do diagnostyki.

System otrzymuje wywołania z jądra przez gniazdo netlink . Wcześniejsze wersje wykorzystywały hotplug , dodając w tym celu link do siebie w /etc/hotplug.d/default .

Operacja

udev został włączony do systemud 183

udev to ogólny menedżer urządzeń działający jako demon w systemie Linux i nasłuchujący (poprzez gniazdo netlink ) uevents, które jądro wysyła po zainicjowaniu nowego urządzenia lub usunięciu urządzenia z systemu. Pakiet udev zawiera obszerny zestaw reguł, które odpowiadają eksportowanym wartościom zdarzenia i właściwościom wykrytego urządzenia. Pasująca reguła prawdopodobnie nazwie i utworzy węzeł urządzenia oraz uruchomi skonfigurowane programy w celu skonfigurowania i skonfigurowania urządzenia.

Reguły udev mogą być zgodne we właściwościach, takich jak podsystem jądra, nazwa urządzenia jądra, fizyczna lokalizacja urządzenia lub właściwości, takie jak numer seryjny urządzenia. Reguły mogą również żądać informacji od programów zewnętrznych, aby nazwać urządzenie lub określić niestandardową nazwę, która będzie zawsze taka sama, niezależnie od kolejności, w jakiej urządzenia są wykrywane przez system.

W przeszłości powszechnym sposobem używania udev w systemach Linux było umożliwienie mu wysyłania zdarzeń przez gniazdo do HAL , który wykonywałby dalsze działania specyficzne dla urządzenia. Na przykład, HAL powiadamia inne oprogramowanie działające w systemie, że przybył nowy sprzęt, wysyłając wiadomość rozgłoszeniową w systemie D-Bus IPC do wszystkich zainteresowanych procesów . W ten sposób komputery stacjonarne, takie jak GNOME lub K Desktop Environment 3, mogą uruchomić przeglądarkę plików, aby przeglądać systemy plików nowo podłączonych dysków flash USB i kart SD .

W połowie 2011 r. HAL był przestarzały w większości dystrybucji Linuksa, a także w środowiskach graficznych KDE, GNOME i Xfce . Funkcjonalność wcześniej zawarta w HAL została zintegrowana z samym udev lub przeniesiona do oddzielnego oprogramowania, takiego jak udisks i upower .

  • udev zapewnia dostęp niskiego poziomu do drzewa urządzeń linux. Umożliwia programom wyliczanie urządzeń i ich właściwości oraz otrzymywanie powiadomień, gdy urządzenia pojawiają się i odchodzą.
  • dbus to platforma umożliwiająca programom komunikowanie się ze sobą w sposób bezpieczny, niezawodny i za pomocą wysokopoziomowego zorientowanego obiektowo interfejsu programistycznego.
  • udisks (wcześniej znany jako DeviceKit-disks) to demon, który znajduje się na szczycie libudev i innych interfejsów jądra i zapewnia interfejs wysokiego poziomu dla urządzeń pamięci masowej i jest dostępny przez dbus dla aplikacji.
  • upower (wcześniej znany jako DeviceKit-power) to demon, który znajduje się na szczycie libudev i innych interfejsów jądra i zapewnia interfejs wysokiego poziomu do zarządzania energią i jest dostępny przez dbus dla aplikacji.
  • NetworkManager to demon, który znajduje się na szczycie libudev i innych interfejsów jądra (oraz kilku innych demonów) i zapewnia interfejs wysokiego poziomu do konfiguracji i konfiguracji sieci oraz jest dostępny dla aplikacji przez dbus.

udev odbiera komunikaty z jądra i przekazuje je do demonów podsystemu, takich jak Network Manager. Aplikacje komunikują się z Network Managerem przez D-Bus.

HAL jest przestarzały i używany tylko przez starszy kod. Ubuntu 10.04 dostarczane bez HAL. Początkowo planowano zastąpienie niektórych aspektów HAL nowym demonem DeviceKit, ale w marcu 2009 r. DeviceKit został przestarzały na rzecz dodania tego samego kodu do udev jako pakietu: udev-extras, a niektóre funkcje zostały teraz przeniesione do właściwego udev.

Historia

udev został wprowadzony w Linuksie 2.5 . Jądro Linuksa w wersji 2.6.13 wprowadziło lub zaktualizowało nową wersję interfejsu uevent . System używający nowej wersji udev nie uruchomi się z jądrami starszymi niż 2.6.13, chyba że udev jest wyłączone, a do dostępu do urządzenia używany jest tradycyjny katalog /dev .

W kwietniu 2012 r. baza kodu udev została połączona z drzewem źródeł systemd , czyniąc systemd 183 pierwszą wersją zawierającą udev. W październiku 2012 r. Linus Torvalds skrytykował podejście Kay Sievers do konserwacji i naprawy błędów związanych z ładowaniem oprogramowania układowego , stwierdzając:

Tak, robienie tego w jądrze jest „bardziej niezawodne”. Ale nie graj w gry i przestań kłamać. Jest bardziej solidny, ponieważ mamy opiekunów, którzy się tym przejmują, i ponieważ wiemy, że regresje nie są czymś, z czym możemy grać szybko i luźno. W przypadku przerwy coś, a nie wiemy, co prawo fix do tego pęknięcia jest taka, że powróci rzeczy, który wybuchł. Więc tak, zdecydowanie lepiej zrobić to w jądrze. Nie dlatego, że ładowanie oprogramowania układowego nie może być wykonane w przestrzeni użytkownika. Ale po prostu dlatego, że konserwacja udev od czasu, gdy Greg zrezygnował, pogorszyła się.

W 2012 roku projekt Gentoo Linux stworzył rozwidlenie bazy kodu udev systemd, aby uniknąć zależności od architektury systemd. Powstały widelec nazywa się eudev i udostępnia funkcjonalność udev bez systemd. Deklarowanym celem projektu jest utrzymanie eudev niezależnego od jakiejkolwiek dystrybucji Linuksa lub systemu init . Projekt Gentoo opisuje eudev w następujący sposób:

eudev to rozwidlenie systemd-udev, którego celem jest uzyskanie lepszej kompatybilności z istniejącym oprogramowaniem, takim jak OpenRC i Upstart , starszymi jądrami, różnymi łańcuchami narzędzi i wszystkim innym wymaganym przez użytkowników i różne dystrybucje.

29 maja 2014 wsparcie dla ładowania oprogramowania układowego przez udev zostało usunięte z systemd, ponieważ zdecydowano, że ładowanie oprogramowania układowego jest zadaniem jądra. Dwa dni później Lennart Poettering zasugerował odłożenie tej łatki do czasu,kdbus zacznie być używany przez udev; W tamtym momencie plan zakładał przełączenie udev na używanie kdbus jako podstawowego systemu przesyłania wiadomości i pozbycie się transportu opartego na netlinku z przestrzeni użytkownika do przestrzeni użytkownika.

Autorski

udev został opracowany przez Grega Kroah-Hartmana i Kay Sievers , z dużą pomocą m.in. Dana Stekloffa .

Bibliografia

Zewnętrzne linki