Czy istnieją alternatywy dla używania `udev`?

Chociaż rozumiem wielkość udev i doceniam wysiłek programistów, po prostu zastanawiałem się, czy jest na to alternatywa.

Na przykład, wyobrażam sobie, że powinien istnieć sposób na stworzenie skryptu uruchamiania, który tworzy większość węzłów urządzeń, które w moim systemie (bez zmiany sprzętu) są w większości takie same.

Korzyść lub powód, dla którego chciałbym pominąć, udevbyłaby taka sama jak w przypadku pomijania dbus, a mianowicie zmniejszenie złożoności i zwiększenie moich zmian w celu bezpieczniejszego konfigurowania systemu.

Istnieją różne alternatywy udev. Pozornie Gentoo może używać czegoś zwanego mdev. Inną opcją byłaby próba użycia udevpoprzednika devfsd. Wreszcie zawsze możesz utworzyć wszystkie potrzebne pliki urządzeń mknod.

Zauważ, że w tym drugim przypadku nie ma potrzeby tworzenia wszystkiego podczas uruchamiania, ponieważ węzły można tworzyć na dysku, a nie w tymczasowym systemie plików, jak w przypadku innych opcji. Oczywiście tracisz elastyczność dynamicznego tworzenia plików urządzeń po podłączeniu nowego sprzętu (np. Pamięci USB). Uważam, że standardowym podejściem w tej erze było utworzenie każdego pliku urządzenia, pod którym można zasadnie potrzebować/dev (tj. Wielu plików urządzenia).

Oczywiście trudność w uzyskaniu któregokolwiek z tych podejść do pracy w nowoczesnej dystrybucji jest prawdopodobnie dość wysoka. Wiki Gentoo wspomina o trudnościach w mdevpracy ze środowiskiem graficznym (nie mówiąc już o Gentoo). Ostatnie devfsdwydanie to 2002, nie mam pojęcia, czy w ogóle będzie działać z nowoczesnymi jądrami. Ręczne tworzenie węzłów jest prawdopodobnie najbardziej opłacalnym podejściem, ale nawet wyłączenie udevmoże być wyzwaniem, szczególnie w przypadku korzystania z dystrybucji systemd( udevjest teraz częścią systemd, co sugeruje silną zależność).

Moja rada się trzyma udev;)

Nowoczesne jądra Linuksa obsługują devtmpfssystem plików ^{(nie mylić ze starożytnymi devfs)} , który dynamicznie tworzy wszystkie węzły urządzeń, gdy tylko jądro je odkryje. (W rzeczywistości najnowsze udevwersje tego wymagają ; przekonasz się, że udev nie tworzy już żadnych węzłów urządzeń, tylko dowiązania symboliczne).

Podobnie, ładowanie oprogramowania układowego zostało również przeniesione do jądra, więc jedyne pozostałe zadania, które udevwykonuje, to ładowanie modułu (zgodnie z modalizacjami) oraz stosowanie uprawnień urządzenia i innych reguł udev.

Teoretycznie w pełni monolityczne jądro powinno wystartować bez udev.

Jednak prawdziwym problemem jest to, co dzieje się później.

1. Sporo programów w przestrzeni użytkownika polega na udev utrzymaniu bazy danych urządzeń, dostępnej poprzez libudev. Podczas gdy wyliczanie urządzeń i nasłuchiwanie dodanych / usuniętych zdarzeń można wykonać bezpośrednio przy użyciu interfejsów jądra (sysfs i netlink), nadal pozostaniesz bez wszystkich metadanych, które zostały dołączone przez różne reguły udev.

2. udev zasady utrzymania również różne „uporczywe” dowiązania w /dev/disk/by-*, /dev/mapper, /dev/input/by-path, /dev/snd/by-path, i tak dalej. Na przykład, jeśli masz podłączone dwa dyski, nie ma gwarancji, że pierwszy będzie zawsze sdalub sdb, ale udev zapewnia, że ​​dowiązania symboliczne /dev/disk/by-uuidbędą nadal wskazywać właściwy.

3. Chociaż węzły urządzeń są teraz tworzone przez jądro i dlatego nie należy się tym przejmować, ważne jest, aby pamiętać, że niektóre typy urządzeń zaczęły używać dynamicznie przypisywanych liczb głównych / drugorzędnych, więc mimo że masz 10 /dev/fuse228 i/dev/hpet 229, będą one mają różne numery po każdym ponownym uruchomieniu, więc wymaganydevtmpfs jest albo program (w starszych systemach), który nasłuchuje uevents .

Wiele z tych rzeczy można łatwo zrobić za pomocą innych programów, takich jak mdevoczywiście. Chodzi mi o to, że /etc/MAKEDEVskrypt statyczny przestanie działać ...

Zasadniczo udev jest najmniej prawdopodobne, jeśli chodzi o złożoność rozruchu z twoich problemów.

Istnieje kilka alternatyw:

• Wystarczy mieć odpowiedni zestaw chmod , chown, lni tym podobnych poleceń w skrypcie, który jest uruchamiany jako część startowej.
• Użyj systemd-udevmenedżera plug-and-play, który jest częścią projektu systemowego.
• Użyj Gentooeudev , który jest rozwidleniem, systemd-udevz którego systemd znacznie się teraz rozszedł.
• Użyj Devuan'svdev , menedżera plug-and-play opracowanego przez Jude'a Nelsona, który jest częścią Devuan.
• Użyj mdev, co w przeciwieństwie do innej odpowiedzi nie jest rzeczą Gentoo. Wbudowany jest menedżer plug-and-play BusyBox .
• Użyj Bezszczęśliwegomdev który jest menedżerem plug-and-play opracowanym przez Dimitrisa Papastamosa.
• Użyj Laurent Bercotmdevd , który jest konfiguracją kompatybilną z BusyBox, mdevale obsługuje własną obsługę gniazd i nie rozumie protokołu LISTEN.

Wszystkie te, oprócz pierwszego, wymagają zestawu reguł opisujących sposób reagowania na zdarzenia powiadamiania jądra o urządzeniach. Oczywiście.

Istnieją również narzędzia, które przyjmą programy przeznaczone do nich /proc/sys/kernel/hotplug, takie jak dwa mdevs, i które dostosują je i serializują, słuchając gniazda netlink, a następnie uruchamiając te programy:

• Laurent Bercot jest stary s6-netlink-listeneris6-uevent-spawner
• netlink-datagram-socket-listen i plug-and-play-event-handlerz zestawu narzędzi nosh

udev? Najlepszą alternatywą jest z niego nie korzystać. A ucząc się, jak go nie używać, Linux i świat * NIX zaczną mieć bardziej logiczny sens.

Najlepszą długoterminową alternatywą jest użycie urządzeń statycznych (patrz uwaga). Jeśli masz sterownik, jądro Linuksa zarządza podłączaniem podczas pracy. Wolę nigdy nie udevd biegać.

dbus to inna sprawa. Spowalnia twój system, ale ciągle zmienia się świat ludzi skryptów. Tak więc wiele rzeczy, do których jesteś przyzwyczajony, jak przeglądarki internetowe lub aplikacje z backendami skryptów, muszą zostać naprawione (uruchomione lub przebudowane bez tych rzeczy lub zrzucone dla innej aplikacji).

Uwaga: jeśli podłączasz tylko dysk flash lub urządzenie DVD, użyj, dmesg|tailaby zobaczyć nazwę urządzenia, które chcesz zamontować. Uczenie się, kiedy urządzenie jest postacią lub urządzeniem blokowym, jest podstawową wiedzą systemową w świecie sprzętu komputerowego. W Linuksie jest to oprogramowanie typu open source, sprawdź to dużo na temat Linuksa, nie tylko wbudowanego . Jest to najlepszy sposób na szersze zrozumienie prostej logiki (nie filozofii) wszystkich * NIXów, takich jak Linux (Solaris, HPUX, AIX itp.).

Udev, dbus, gconf / dconf, systemd, gnome-shell, Gnome, Glib, mono i Fedora są przeznaczone dla osób z dużą ilością czasu, które nie mają dostępu do RTFM lub chcą automatycznie zaktualizowanej, naprawdę bystrej (wyglądającej), ale wolniejszej niż melasa, błędny, w połowie drogi Linux. (Naprawdę okropne miejsce, rozejrzyj się po Internecie w poszukiwaniu ton podobnych doświadczeń).

System uruchamia się następnie udevd. Ale twierdzi się, że udev jest konieczny, ponieważ will changeprzy ponownym uruchomieniu urządzenia drobne numery urządzeń . Raison d'etre Udev wydaje się zaprzeczać sobie na każdym kroku. A gdzie są pliki, zawsze wydaje się źle, bez względu na to, z kim się konsultujesz. Nie ufaj ani freedesktop.org.

Poza tym udev jest pochłaniany przez horror znany jako systemd, nie wiem więc, co można zrobić z tymi śmieciami / etc / udev. I głupio jest powiedzieć, że pisanie reguł udev jest jakoś lepsze niż cokolwiek innego. Wydaje się, że ludzie Gentoo chcą się do tego przyczepić i nie muszą mieć systemu, więc rozwinęli go w eudev.

Jeśli chcesz absurdalnie szybki, bez nieprzyjemnych niespodzianek system, skorzystaj z podstaw Linuksa.