มีทางเลือกอื่นในการใช้ `udev 'หรือไม่

ในขณะที่ฉันเข้าใจความยิ่งใหญ่ของ udev และชื่นชมความพยายามของนักพัฒนาฉันก็แค่สงสัยว่ามีทางเลือกอื่นหรือไม่

ตัวอย่างเช่นฉันอาจจินตนาการว่าควรมีวิธีในการสร้างสคริปต์เริ่มต้นที่สร้างโหนดอุปกรณ์ส่วนใหญ่ซึ่งในระบบของฉัน (ไม่มีฮาร์ดแวร์ที่เปลี่ยนแปลง) จะเหมือนกันที่สุด

ประโยชน์หรือเหตุผลที่ฉันต้องการข้ามudevจะเหมือนกับการข้ามdbusคือลดความซับซ้อนและเพิ่มการเปลี่ยนแปลงในการตั้งค่าระบบให้ปลอดภัยยิ่งขึ้น

มีทางเลือกต่าง ๆ ให้udevออกมี ดูเหมือน Gentoo mdevสามารถใช้สิ่งที่เรียกว่า ตัวเลือกอื่นจะพยายามใช้udevบรรพบุรุษdevfsdของ สุดท้ายคุณก็สามารถสร้างไฟล์อุปกรณ์ทั้งหมดที่คุณต้องการmknodได้เสมอ

โปรดทราบว่าในระยะหลังไม่จำเป็นต้องสร้างทุกอย่างในเวลาบูตเนื่องจากโหนดสามารถสร้างได้บนดิสก์และไม่ได้อยู่ในระบบไฟล์ชั่วคราวเช่นเดียวกับตัวเลือกอื่น ๆ แน่นอนคุณสูญเสียความยืดหยุ่นในการสร้างไฟล์อุปกรณ์แบบไดนามิกเมื่อเสียบปลั๊กฮาร์ดแวร์ใหม่ (เช่นแท่ง USB) ฉันเชื่อว่าวิธีการมาตรฐานในยุคนี้คือการมีไฟล์อุปกรณ์ทุกไฟล์ที่คุณสามารถสร้างขึ้นได้อย่างสมเหตุสมผลภายใต้/dev(เช่นไฟล์อุปกรณ์จำนวนมาก)

แน่นอนว่าความยากลำบากในการหาวิธีการเหล่านี้ในการทำงานใน distro ที่ทันสมัยอาจจะค่อนข้างสูง วิกิ Gentoo กล่าวถึงความยากลำบากในการmdevทำงานกับสภาพแวดล้อมเดสก์ท็อป (ไม่ต้องอยู่นอก Gentoo) การdevfsdเปิดตัวครั้งสุดท้ายคือปี 2002 ฉันไม่รู้ว่ามันจะใช้งานได้กับเมล็ดข้าวหรือไม่ การสร้างโหนดด้วยตนเองอาจเป็นวิธีที่มีศักยภาพมากที่สุด แต่แม้การปิดใช้งานudevอาจเป็นสิ่งที่ท้าทายโดยเฉพาะอย่างยิ่งในการใช้ distos systemd( udevตอนนี้เป็นส่วนหนึ่งของการsystemdแนะนำการพึ่งพาที่แข็งแกร่ง)

คำแนะนำของฉันติดudev;)

เคอร์เนล Linux รุ่นใหม่รองรับdevtmpfsระบบไฟล์^{(อย่าสับสนกับโบราณdevfs)}ซึ่งสร้างโหนดอุปกรณ์ทั้งหมดแบบไดนามิกทันทีที่เคอร์เนลค้นพบ (ในความเป็นจริงล่าสุดudevเผยแพร่ต้องนี้คุณจะพบว่า udev ไม่สร้างโหนดอุปกรณ์ใด ๆ อีกต่อไปเพียง symlinks.)

ในทำนองเดียวกันการโหลดเฟิร์มแวร์ก็ถูกย้ายไปยังเคอร์เนลด้วยเช่นกันดังนั้นงานที่เหลืออยู่เพียงอย่างเดียวudevคือการโหลดโมดูล (ตามโมเดอเรนเชียล) และการใช้การอนุญาตอุปกรณ์ & กฎอื่น ๆ

ดังนั้นในทางทฤษฎีแล้วเคอร์เนลแบบโมโนลิทิกอย่างสมบูรณ์ควรบูตโดยไม่ต้องมี udev

อย่างไรก็ตามปัญหาที่แท้จริงที่นี่คือสิ่งที่เกิดขึ้นในภายหลัง

1. โปรแกรมค่อนข้าง userspace ไม่กี่พึ่งพา udev libudevการรักษาฐานข้อมูลของอุปกรณ์ผ่านเข้าถึง ในขณะที่การแจกแจงอุปกรณ์และการฟังเหตุการณ์ที่เพิ่ม / ลบสามารถทำได้โดยตรงโดยใช้เคอร์เนลอินเตอร์เฟส (sysfs และ netlink) คุณจะยังคงอยู่โดยไม่มีข้อมูลเมตาทั้งหมดที่กฎ udev ต่างๆได้แนบไว้

2. udev กฎยังรักษาต่างๆ symlinks "ถาวร" ใน/dev/disk/by-*, /dev/mapper, /dev/input/by-path, /dev/snd/by-pathและอื่น ๆ ตัวอย่างเช่นหากคุณมีดิสก์สองแผ่นที่เชื่อมต่อกันจะไม่มีการรับประกันว่าดิสก์แรกจะเป็นsdaหรือเสมอsdbแต่ udev รับประกันว่า symlink ใน/dev/disk/by-uuidนั้นจะยังคงชี้ไปทางขวา

3. ในขณะที่โหนดอุปกรณ์ที่ถูกสร้างขึ้นในขณะนี้โดย kernel และดังนั้นจึงไม่กังวลของคุณอีกต่อไปก็ยังคงเป็นสิ่งสำคัญที่จะทราบว่าบางชนิดอุปกรณ์ได้เริ่มต้นใช้กำหนดแบบไดนามิก / หมายเลขเล็ก ๆ น้อย ๆ ที่สำคัญดังนั้นแม้ว่าคุณจะ/dev/fuseเป็น 10,228 และ/dev/hpetเป็น 10229 วันนี้พวกเขาจะมีตัวเลขที่แตกต่างกันทุกครั้งหลังจากรีบูตดังนั้นทั้งdevtmpfsหรือ (ในระบบเก่า) โปรแกรมที่ฟัง uevents เป็นต้อง

หลายสิ่งเหล่านี้สามารถทำได้อย่างง่ายดายโดยโปรแกรมอื่น ๆ เช่นmdevแน่นอน ประเด็นของฉันคือ/etc/MAKEDEVสคริปต์คงที่จะไม่ทำงานอีกต่อไป ...

ดังนั้นโดยทั่วไปเมื่อพูดถึงความซับซ้อนในการบู๊ต udev ก็น่าจะเป็นสิ่งที่คุณกังวลน้อยที่สุด

มีหลายทางเลือก:

• เพียงแค่มีชุดของที่เหมาะสมchmod, chown, lnและคำสั่งเช่นกันในสคริปต์ที่ทำงานเป็นส่วนหนึ่งของการบูต
• ใช้systemd-udevตัวจัดการ plug-and-play ที่เป็นส่วนหนึ่งของโครงการ systemd
• ใช้Gentoo'seudevซึ่งเป็นทางแยกsystemd-udevที่ systemd ได้แยกออกจากกันอย่างมีนัยสำคัญ
• ใช้Devuan'svdevซึ่งเป็นตัวจัดการแบบ plug-and-play ที่พัฒนาโดย Jude Nelson ซึ่งเป็นส่วนหนึ่งของ Devuan
• ใช้mdevซึ่งตรงกันข้ามกับคำตอบอื่นไม่ได้เป็นสิ่งที่ Gentoo มันเป็นผู้จัดการ Plug-and-play ที่สร้างไว้ในBusyBox
• ใช้Sucklessmdevซึ่งเป็นตัวจัดการแบบ plug-and-play ที่พัฒนาโดย Dimitris Papastamos
• ใช้Laurent Bercot'smdevdซึ่งเป็นการกำหนดค่าที่เข้ากันได้กับ BusyBox mdevแต่ทำหน้าที่จัดการซ็อกเก็ตของตัวเองและไม่เข้าใจโปรโตคอล LISTEN

สิ่งเหล่านี้ทั้งหมดนอกเหนือจากตอนแรกจำเป็นต้องมีชุดของกฎที่อธิบายถึงวิธีการตอบสนองต่อเหตุการณ์การแจ้งเตือนเคอร์เนลเกี่ยวกับอุปกรณ์ อย่างชัดเจน

นอกจากนี้ยังมีเครื่องมือที่จะใช้โปรแกรมที่ออกแบบมาสำหรับ/proc/sys/kernel/hotplugเช่นสองตัวmdevและจะปรับและทำให้เป็นลำดับโดยการฟังซ็อกเก็ต netlink แล้ววางไข่โปรแกรมเหล่านั้น:

• Laurent Bercot แก่s6-netlink-listenerแล้วs6-uevent-spawner
• netlink-datagram-socket-listen และplug-and-play-event-handlerจากชุดเครื่องมือ nosh

udev? ทางเลือกที่ดีที่สุดคือไม่ใช้ และโดยการเรียนรู้วิธีที่จะไม่ใช้ Linux และโลก * NIX จะเริ่มมีเหตุผลมากขึ้น

ทางเลือกระยะยาวที่ดีที่สุดคือการใช้อุปกรณ์คงที่ (ดูหมายเหตุ) หากคุณมีไดรเวอร์แล้วเคอร์เนล Linux จะจัดการกับฮอตปลั๊ก ฉันไม่ต้องการวิ่ง udevd เลย

dbus เป็นอีกเรื่องหนึ่ง มันทำให้ระบบของคุณช้าลง แต่โลกของคนสคริปต์ที่เปลี่ยนแปลงตลอดเวลาต่างก็ชื่นชอบมัน ดังนั้นสิ่งต่างๆมากมายที่คุณคุ้นเคยเช่นเว็บเบราว์เซอร์หรือแอปพลิเคชันที่มีแบ็กเอนด์สคริปต์ต้องได้รับการแก้ไข (เปิดตัวหรือสร้างใหม่โดยไม่ต้องมีเนื้อหานั้น

หมายเหตุ: หากคุณเพิ่งเสียบปลั๊กแฟลชไดรฟ์หรืออุปกรณ์ดีวีดีให้ใช้dmesg|tailเพื่อดูชื่ออุปกรณ์ที่จะเมานต์ การเรียนรู้เมื่ออุปกรณ์เป็นตัวละครหรืออุปกรณ์บล็อกคือความรู้พื้นฐานของระบบในโลกของฮาร์ดแวร์คอมพิวเตอร์ ใน Linux เป็นโอเพ่นซอร์สตรวจสอบสิ่งนี้มากมายเกี่ยวกับ Linux ไม่ใช่แค่ฝังไว้ เป็นวิธีที่ดีที่สุดสำหรับการทำความเข้าใจกับตรรกะที่ตรงไปตรงมา (ไม่ใช่ปรัชญา) ของ * NIX ทั้งหมดเช่น Linux (Solaris, HPUX, AIX, ฯลฯ )

Udev, dbus, gconf / dconf, systemd, gnome-shell, Gnome, Glib, mono และ Fedora สำหรับผู้ที่มีเวลาในมือที่ไม่สามารถ RTFM หรือต้องการการปรับปรุงอัตโนมัติโดยอัตโนมัติ (ดู) แต่ช้ากว่า กว่ากากน้ำตาล, บั๊กกี้, ลินุกซ์ครึ่งทาง (สถานที่ที่น่ากลัวอย่างแท้จริงดูรอบ ๆ เว็บเพื่อรับประสบการณ์ที่คล้ายกันมากมาย)

จากนั้นบูทระบบก็จะทำการรัน udevd แต่มันก็อ้างว่า udev เป็นสิ่งจำเป็นเพราะอุปกรณ์หมายเลขรองwill changeเมื่อรีบูต raison d'etre ของ Udev ดูเหมือนจะขัดแย้งกันเองทุกครั้ง และตำแหน่งของไฟล์นั้นดูเหมือนผิดเสมอไม่ว่าคุณจะปรึกษาใคร อย่าไว้ใจหรือ freedesktop.org

นอกจาก udev กำลังถูกดูดซับเข้าไปในหนังสยองขวัญที่รู้จักกันในชื่อ systemd ฉันไม่รู้ว่าสิ่งใดที่ทำกับขยะ / etc / udev และมันเป็นคำพูดที่ไร้สาระที่จะกล่าวว่าการเขียนกฎ udev นั้นดีกว่าสิ่งใด ดูเหมือนว่าคนที่มีความสุภาพจะต้องการแขวนมันและไม่จำเป็นต้องมี systemd ดังนั้นพวกเขาจึงแยกมันออกเป็น eudev

หากคุณต้องการระบบที่น่าขันอย่างรวดเร็วไม่น่าแปลกใจให้ใช้พื้นฐานของ Linux