Có những lựa chọn thay thế cho việc sử dụng `udev`?


16

Trong khi tôi hiểu sự tuyệt vời của udev và đánh giá cao nỗ lực của các nhà phát triển, tôi chỉ đơn giản là tự hỏi liệu có sự thay thế nào cho nó không.

Ví dụ, tôi có thể tưởng tượng nên có một cách để tạo tập lệnh khởi động tạo ra hầu hết các nút thiết bị mà trên hệ thống của tôi (không thay đổi phần cứng) dù sao cũng giống nhau.

Lợi ích hoặc lý do tôi muốn bỏ qua udevsẽ giống như bỏ qua dbus, cụ thể là giảm độ phức tạp và bằng cách đó tăng các thay đổi của tôi để thiết lập hệ thống an toàn hơn.

Câu trả lời:


23

Có nhiều lựa chọn thay thế udevngoài kia. Dường như Gentoo có thể sử dụng một cái gì đó gọi là mdev. Một lựa chọn khác là cố gắng sử dụng udevtiền thân của nó devfsd. Cuối cùng, bạn luôn có thể tạo tất cả các tệp thiết bị bạn cần mknod.

Lưu ý rằng với cái sau, không cần tạo mọi thứ khi khởi động vì các nút có thể được tạo trên đĩa chứ không phải trong một hệ thống tệp tạm thời như với các tùy chọn khác. Tất nhiên, bạn mất tính linh hoạt khi có các tệp thiết bị được tạo động khi cắm phần cứng mới (ví dụ: thẻ nhớ USB). Tôi tin rằng cách tiếp cận tiêu chuẩn trong thời đại này là có mọi tệp thiết bị mà bạn có thể cần một cách hợp lý đã được tạo theo /dev(tức là rất nhiều tệp thiết bị).

Tất nhiên, khó khăn trong việc có bất kỳ phương pháp nào trong số những cách tiếp cận này để làm việc trong một bản phân phối hiện đại có lẽ là khá cao. Wiki Gentoo đề cập đến những khó khăn trong mdevviệc làm việc với môi trường máy tính để bàn (huống chi là bên ngoài Gentoo). Bản devfsdphát hành cuối cùng là năm 2002, tôi không biết liệu nó có hoạt động được với các hạt nhân hiện đại hay không. Tạo các nút theo cách thủ công có lẽ là cách tiếp cận khả thi nhất, nhưng ngay cả việc vô hiệu hóa udevcũng có thể là một thách thức, đặc biệt là trong các bản phân phối sử dụng systemd( udevhiện là một phần của systemd, điều này cho thấy sự phụ thuộc mạnh mẽ).

Lời khuyên của tôi là gắn bó với udev;)


1
Cảm ơn! Câu trả lời tuyệt vời giải quyết hầu hết nếu không phải tất cả các khía cạnh của câu hỏi và có đầy đủ thông tin! Tự hỏi làm thế nào để giải quyết vấn đề systemd ngay bây giờ ... Tôi sẽ xem làm thế nào để giải quyết vấn đề này :)
nhân

udevnên hoạt động hoàn toàn tốt mà không cần systemd- cả hai chỉ được phát triển trong cùng một cơ sở mã, nhưng udevcó thể được xây dựng + chạy độc lập với nó.
Elias Probst

@Elias, tất nhiên, udevđã tồn tại lâu hơn nhiều so với systemddù sao. Câu hỏi là, có thể systemdlàm việc mà không có udev? Tôi đoán là ít nhất bạn sẽ phải biên dịch lại với một số loại --without-udevtùy chọn.
Graeme

2
@Graeme: Không, không thể. Nó giống như cố gắng giảm độ phức tạp của một chiếc xe hơi bằng cách tháo các bánh xe. Nếu bạn ổn với việc khởi động với systemd ( rất nhiều ), nhưng quan tâm nghiêm túc về sự phức tạp của udev (vốn ngày càng ít đi), thì bạn có những điều thực sự bối rối.
dùng1686

@grawity Điểm công bằng, nhưng có lẽ tôi thậm chí không ổn với việc khởi động với systemd cho init rồi! phải cho nó một cái nhìn
nhân

22

Các hạt nhân Linux hiện đại hỗ trợ devtmpfshệ thống tệp (không nhầm lẫn với cổ đại devfs) , tạo ra tất cả các nút thiết bị một cách linh hoạt ngay khi nhân phát hiện ra chúng. (Trên thực tế, các udevbản phát hành mới nhất yêu cầu điều này; bạn sẽ thấy rằng udev không tạo bất kỳ nút thiết bị nào nữa, chỉ có các liên kết tượng trưng.)

Tương tự, tải phần sụn cũng đã được chuyển vào kernel, do đó, các tác vụ còn lại chỉ udevthực hiện là tải mô-đun (theo phương thức) và áp dụng các quyền của thiết bị và các quy tắc udev khác.

Vì vậy, trong lý thuyết, một hạt nhân nguyên khối hoàn toàn sẽ khởi động tốt mà không cần udev.

Tuy nhiên, vấn đề thực sự ở đây là những gì xảy ra sau đó.

  1. Khá nhiều chương trình không gian người dùng dựa trên udev duy trì cơ sở dữ liệu thiết bị của mình, có thể truy cập thông qua libudev. Trong khi liệt kê các thiết bị và nghe các sự kiện được thêm / xóa có thể được thực hiện trực tiếp bằng giao diện kernel (sysfs và netlink), bạn vẫn sẽ bị bỏ lại mà không có tất cả các siêu dữ liệu mà các quy tắc udev khác đã đính kèm.

  2. udev quy tắc cũng duy trì khác nhau liên kết tượng trưng "dai dẳng" trong /dev/disk/by-*, /dev/mapper, /dev/input/by-path, /dev/snd/by-path, và vân vân. Ví dụ: nếu bạn có hai đĩa được kết nối, không có gì đảm bảo rằng cái đầu tiên sẽ luôn luôn sdahoặc sdb, nhưng udev đảm bảo rằng các liên kết tượng trưng trong /dev/disk/by-uuidsẽ tiếp tục trỏ đến đúng.

  3. Mặc dù các nút thiết bị hiện được tạo bởi kernel và do đó không còn là mối lo ngại của bạn nữa, nhưng điều quan trọng cần lưu ý là một số loại thiết bị đã bắt đầu sử dụng các số chính / phụ được gán động, do đó, mặc dù bạn có /dev/fuse10,228 và /dev/hpet10,229 ngày hôm nay, chúng sẽ có các số khác nhau sau mỗi lần khởi động lại, do đó, devtmpfshoặc (trên các hệ thống cũ), một chương trình lắng nghe các yêu cầubắt buộc .

Nhiều trong số những điều này có thể dễ dàng được thực hiện bởi các chương trình khác, chẳng hạn như mdev. Quan điểm của tôi là một /etc/MAKEDEVkịch bản tĩnh sẽ không hoạt động nữa ...


Vì vậy, về cơ bản, khi nói đến độ phức tạp của boot, udev hoàn toàn có thể mối quan tâm ít nhất của bạn.


Thật thú vị, bạn có biết phiên bản kernel nào giới thiệu việc tạo các nút động không?
Graeme

2
@Graeme: Khoảng 2.6.32 .
dùng1686

12

Có một số lựa chọn thay thế:

  • Đơn giản chỉ cần có một tập hợp thích hợp chmod, chown, ln, và các lệnh như vậy trong một kịch bản được chạy như một phần của bootstrap.
  • Sử dụng systemd-udev, trình quản lý plug-and-play là một phần của dự án systemd.
  • Sử dụng Gentoo'seudev , một nhánh systemd-udevmà từ đó systemd đã chuyển hướng đáng kể.
  • Sử dụng Devuan'svdev , một trình quản lý plug-and-play được phát triển bởi Jude Nelson, đó là một phần của Devuan.
  • Sử dụng mdev, trái với câu trả lời khác không phải là một điều Gentoo. Đó là trình quản lý plug-and-play được tích hợp trong BusyBox .
  • Sử dụng Sucklessmdev , trình quản lý plug-and-play được phát triển bởi Dimitris Papastamos.
  • Sử dụng Laurent Bercotmdevd , cấu hình tương thích với BusyBox mdevnhưng xử lý ổ cắm riêng và không hiểu giao thức LISTEN.

Tất cả những điều này, ngoài phần đầu tiên, yêu cầu các bộ quy tắc mô tả cách phản ứng với các sự kiện thông báo kernel về thiết bị. Chắc chắn.

Ngoài ra còn có các công cụ sẽ lấy các chương trình được thiết kế cho /proc/sys/kernel/hotplug, chẳng hạn như hai mdevs, và sẽ điều chỉnh và tuần tự hóa chúng bằng cách nghe một ổ cắm netlink và sau đó sinh ra các chương trình đó:


6

udev? Thay thế tốt nhất là không sử dụng nó. Và bằng cách học cách không sử dụng Linux, thế giới * NIX sẽ bắt đầu có ý nghĩa logic hơn.

Cách thay thế dài hạn tốt nhất là sử dụng các thiết bị tĩnh (xem ghi chú). Nếu bạn đã có trình điều khiển, nhân Linux sẽ quản lý việc cắm nóng. Tôi thích không có udevd chạy, bao giờ.

dbus là một vấn đề khác Nó làm chậm hệ thống của bạn, nhưng thế giới kịch bản luôn thay đổi của mọi người yêu thích nó. Vì vậy, rất nhiều thứ, bạn đã từng sử dụng, như trình duyệt web hoặc ứng dụng có phụ trợ tập lệnh, phải được sửa chữa (khởi chạy hoặc xây dựng lại mà không có nội dung đó hoặc bị đổ cho ứng dụng khác).

Lưu ý: Nếu bạn chỉ cắm vào ổ đĩa flash hoặc thiết bị dvd, hãy sử dụng dmesg|tailđể xem tên của thiết bị cần gắn. Học khi một thiết bị là một nhân vật hoặc thiết bị khối là kiến ​​thức hệ thống cơ bản trong thế giới phần cứng máy tính. Trong Linux, nó là nguồn mở, hãy kiểm tra điều này rất nhiều về Linux, không chỉ là nhúng . Đó là cách tốt nhất để hiểu rộng hơn về logic chuyển tiếp thẳng (không phải triết lý) của tất cả các * NIX, như Linux (Solaris, HPUX, AIX, v.v.).

Udev, dbus, gconf / dconf, systemd, gnome-shell, Gnome, Glib, mono và Fedora dành cho những người có nhiều thời gian trên tay, những người không thể RTFM, hoặc muốn tự động cập nhật thực sự trơn tru (nhìn) nhưng chậm hơn hơn cả mật đường, lỗi, nửa đường có Linux. (Một nơi thực sự khủng khiếp, hãy tìm kiếm trên web cho hàng tấn trải nghiệm tương tự).

Hệ thống khởi động sau đó chạy udevd. Nhưng, tuyên bố udev là cần thiết bởi vì, số lượng thiết bị nhỏ will changekhi khởi động lại. Nhà tù của Udev dường như mâu thuẫn ở mỗi lượt. Và nơi các tập tin của nó dường như luôn luôn sai cho dù bạn hỏi ý kiến ​​ai. Đừng tin tưởng hoặc freedesktop.org.

Bên cạnh udev đang bị cuốn hút vào nỗi kinh hoàng được gọi là systemd, tôi không biết người ta làm gì với những thứ linh tinh / etc / udev sau đó. Và, thật mệt mỏi khi nói rằng viết các quy tắc udev bằng cách nào đó tốt hơn bất cứ điều gì. Những người hiền lành dường như muốn bám vào nó và không cần phải có hệ thống, vì vậy họ đã rẽ nhánh nó sang eudev.

Nếu bạn muốn có một hệ thống nhanh chóng lố bịch, không có bất ngờ khó chịu, hãy sử dụng các kiến ​​thức cơ bản về Linux.


6
Đây là một câu nói hay hơn là một câu trả lời ...
jasonwryan

2
@jasonwryan có phần đúng, vẫn có một số giá trị vì nó khuyên một số cách để tự xử lý các tác vụ được quy định trong udevchức năng. Cũng có phần cũng ổn để chỉ ra những điểm mạnh của phương pháp thay thế này .
nhân

1
Nâng cao điều này. Lý do là trong khi tôi hoàn toàn đồng ý rằng phong cách có thể bị một số người coi là không phù hợp, nó có giá trị và thậm chí nếu nó không thực sự hữu ích, tôi có xu hướng chấp nhận nó như một thực tế. Trong kernel 4.x, udev đang đổi tên ngẫu nhiên các giao diện ethernet .. CÁI GÌ?!
Victor

Bạn không thể dựa vào kernel cho các thiết bị đặt tên liên tục. Ít nhất udev cung cấp cho bạn quyền kiểm soát nó.
Emmanuel
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.