Đối với vấn đề đó, chính xác thì có gì sai với một loạt các tệp tĩnh trong /dev? Có vẻ như không đủ thỏa mãn để các nhà phát triển đã phát minh lại bánh xe này bằng số đếm của tôi 3 lần bây giờ ( devfs-> udev + HAL-> udev), và bây giờ rõ ràng nó cũng sẽ tham gia Chương trình Khởi đầu Thống nhất, vì vậy bốn lần.

Tôi nhớ khi tôi mới bắt đầu sử dụng Linux cách đây nhiều năm, đã rất ngạc nhiên rằng mặc dù tuyên bố rằng "mọi thứ đều là tệp", nhưng không có /dev/eth0(điều này sau đó có ý nghĩa, vì nó không phải là một thiết bị char hoặc chặn - mặc dù là loại thiết bị "gói" sẽ rất thú vị ...). Cho rằng, tại sao chương trình xử lý cây tệp char và khối thiết bị cũng chịu trách nhiệm cho các thiết bị mạng? Tôi đã thấy các tham chiếu mơ hồ về "tính linh hoạt", nhưng điều này thêm vào những gì, nói, ifconfig (8) làm gì khi chỉ nhìn vào /proc/net/dev? Tôi biết, chẳng hạn, NetworkManager sẽ không có mặt trên Net hoặc OpenBSD bất cứ lúc nào vì nó phụ thuộc vào udev, điều mà cả hai đội đều không muốn viết; những gì tôi không '/devđã được nhân ra nhiều cách (và không có cách nào trong số đó /dev!).

Có phải chỉ vì cắm nóng? Có vấn đề gì với kernel chỉ lắng nghe các bus vật lý và tải các mô-đun thích hợp trên thông báo "thêm thiết bị" không? Hoặc, Chúa cấm, các quản trị viên thực tế làm như vậy? Tôi nhớ lại vào đầu những năm 2000, máy chủ của tôi đôi khi sẽ khởi tạo các card mạng của họ theo một thứ tự không mong muốn và tôi cho rằng việc đặt tên được quyết định trong vùng người dùng là rất hợp lý (mặc dù lúc đó rất khó để khắc phục), nhưng điều này có vẻ giống như một chiếc búa tạ cho một con gián. (Hoặc có thể sự cố xảy ra với các trường hợp sử dụng mà tôi không nghĩ đến khó khăn hơn nhiều so với các máy chủ hoặc máy tính có giá đỡ, đó là kinh nghiệm của tôi.)

Vì vậy, để nêu rõ câu hỏi của tôi: udev thực sự giải quyết vấn đề gì và làm thế nào các devfs, HAL và / hoặc một tập tin cũ đơn giản không giải quyết được chúng? Có một lý do cụ thể cho nhiều thứ khác nhau (cắm nóng, quản lý thiết bị chung, quản lý thiết bị mạng, đặt tên thiết bị, ưu tiên trình điều khiển, v.v.) cho tất cả là một chương trình không?

Hai điều nữa: Việc Linux chuyển sang doanh nghiệp & các máy chủ lớn khác đã khiến cho tĩnh /devbị phá vỡ. Công nghệ tiến bộ, trong cả người tiêu dùng và doanh nghiệp, đã phơi bày tĩnh / dev như một trò đùa. [Câu trả lời này lấp đầy trong phần hậu trường, đặc biệt là tại sao các devfs được thay thế bằng udev].

Kiệt sức của không gian số lượng lớn và nhỏ

/devcác tệp được xác định bên trong kernel bằng số chính và số phụ. Hạt nhân chưa bao giờ thực sự quan tâm đến tên (ví dụ, mv /dev/sda /dev/disk-1và bạn có thể tiếp tục làm việc, mặc dù tất nhiên các chương trình sẽ không biết tìm nó ở đâu).

Với một tĩnh /dev, bạn cần phân bổ một số chính / phụ cho mọi thiết bị tiềm năng có thể tồn tại. Những con số này cần phải là duy nhất trên toàn cầu, vì chúng được vận chuyển như một phần của các bản phân phối, không được tạo theo yêu cầu. Vấn đề là mỗi số 8 bit của họ có phạm vi 0 02255.

Ban đầu, ví dụ, Linux bắt đầu với 8,0 là sda, 8,1 là sda1, 8,16 là sdb, v.v. Nhưng mọi người cứ thêm ngày càng nhiều đĩa vào máy, đặc biệt là khi bạn xem xét những thứ như kênh sợi quang. Vì vậy, tại một số điểm, số chính 65 Hàng71 đã được thêm cho nhiều đĩa hơn. Sau đó, số chính 128 trận135. Nhưng mọi người vẫn muốn có nhiều đĩa hơn ...

Và các định dạng bảng phân vùng như GPT xuất hiện, hỗ trợ nhiều phân vùng hơn trên mỗi đĩa. Và tất nhiên các thiết bị khác đã ăn qua không gian số: bộ điều khiển RAID khác nhau, quản lý âm lượng hợp lý, v.v.

Kết quả cuối cùng có thể được nhìn thấy tại Danh sách thiết bị LANANA Linux . Nếu bạn nhìn vào danh sách 2.6 (số duy nhất vẫn còn đó), rất nhiều khối số chính thông qua 200 (tối đa: 255) sử dụng. Rõ ràng, những con số sẽ hết.

Thay đổi số lượng lớn hơn không dễ dàng. Nó thay đổi nhân ABI. Tùy thuộc vào hệ thống tập tin, nó thay đổi cách bố trí trên đĩa. Nhưng, tất nhiên, hầu hết các thiết bị đó không tồn tại trên bất kỳ một hệ thống nào, ngay cả một thiết bị (chẳng hạn) đã hết đĩa SCSI có thể có rất nhiều thứ miễn phí, có lẽ nó không cần đĩa cứng IBM XT, ví dụ.

Với tính năng động /dev, bản phân phối không phải gửi số thiết bị. Họ không còn phải là duy nhất trên toàn cầu. Chúng thậm chí không phải là duy nhất trên giày.

Tên thiết bị không thể đoán trước

Nó được sử dụng để thực sự dễ dàng để gán một số cho tất cả mọi thứ. Một bảng có hai kênh IDE; mỗi kênh IDE hỗ trợ một chủ và một nô lệ. Bạn có thể chỉ định theo thứ tự kênh và thứ tự master-then-Slave. Vì vậy, hdatrở thành kênh đầu tiên, chủ; hdbkênh đầu tiên, nô lệ; hdckênh thứ hai, chủ; vv Những người đã được dự đoán và ổn định. Chúng có thể thay đổi nếu bạn thêm một ổ đĩa mới hoặc xóa một ổ đĩa, nhưng vắng mặt thay đổi phần cứng, chúng là tĩnh.

Bạn có thể đặt /dev/hda1tại của bạn /etc/fstabvà tự tin nó sẽ ở lại làm việc, ít nhất là thay đổi phần cứng vắng mặt.

IDE đã làm việc như thế. Không có gì sau khi nó làm.

SATA có vẻ đơn giản: một cổng, một đĩa. Nhưng không phải vậy; nó cho phép nhân số cổng. Và nó cho phép trao đổi nóng. Tuy nhiên, thay đổi phần cứng vắng mặt, bạn thực sự vẫn có thể giữ cho ánh xạ hoạt động.

USB tệ hơn nhiều. Nó không chỉ cho phép trao đổi nóng, nó là điển hình. Mọi người cắm vào ổ flash USB mọi lúc. Hơn nữa, các thiết bị có thể mất một thời gian để thăm dò điều tra và thực sự có thể thay đổi bất cứ khi nào chúng cảm thấy như vậy (ví dụ: khi bật hoặc tắt chế độ lưu trữ USB trên điện thoại của bạn). Firewire cũng tương tự. Với cả hai bạn không thể thực sự đưa ra một bản đồ ổn định.

Mạng kèm theo đĩa không có bất kỳ thứ tự cổng vốn có. Thứ tự duy nhất mà kernel sử dụng là thứ tự chúng xuất hiện. Tương tự với khối lượng logic.

Các nhiệm vụ cho tốc độ khởi động cũng làm cho mọi thứ tồi tệ hơn. Ban đầu, kernel sẽ vui vẻ ngồi xung quanh và chờ một khoảng thời gian khá dài, ví dụ, tất cả các thiết bị USB sẽ khởi tạo. Để thăm dò đầy đủ tất cả các xe buýt SCSI, v.v. Những đầu dò đó được thực hiện thành các nhiệm vụ nền; khởi động sẽ không còn chờ đợi trên chúng. Các thiết bị được thêm vào khi các đầu dò hoàn thành.

Vì vậy, hạt nhân bị bỏ lại, ít nhiều, "bất cứ thứ tự nào chúng xuất hiện". Điều này có nghĩa là nhiều loại thiết bị có thể và đã thay đổi thứ tự cho mỗi boot boot, những gì trên một boot /dev/sdbnày là trên một boot khác /dev/sdc. Điều này làm cho ý tưởng của một tĩnh /devmột trò đùa.

Tóm lược

Khi bạn kết hợp tĩnh /devtrở nên ngày càng vô nghĩa do các lệnh thăm dò thiết bị không thể đoán trước và tiếp tục phân bổ các số chính / phụ tĩnh dẫn đến công việc đáng kể để không hết, thì rõ ràng lý do tại sao các nhà phát triển của Linux chọn chuyển sang động /dev.

Câu hỏi hay.

Theo một cách nào đó, lập luận này có thể được đảo ngược: vì kernel 2.6.13 đã giới thiệu một phiên bản mới uevent, nên chắc chắn sẽ xảy ra việc devfsphải viết lại để tận dụng các tính năng mới của giao diện. Vì vậy, theo một cách nào đó, câu hỏi phải là tại sao sự thay đổi trong kernel.

Tuy nhiên, lấy nó theo mệnh giá, câu hỏi của bạn đã được trả lời trong bài viết của Wikipedia này :

Không giống như các hệ thống Unix truyền thống, nơi các nút thiết bị trong thư mục / dev là một tập hợp tĩnh, trình quản lý thiết bị Linux udev chỉ cung cấp động các nút cho các thiết bị thực sự có trên hệ thống. Mặc dù các devfs được sử dụng để cung cấp chức năng tương tự, Greg Kroah-Hartman đã trích dẫn một số lý do để thích triển khai hơn các devfs:

1) udev hỗ trợ đặt tên thiết bị liên tục, không phụ thuộc vào, ví dụ, thứ tự các thiết bị được cắm vào hệ thống. Thiết lập udev mặc định cung cấp tên liên tục cho các thiết bị lưu trữ. Bất kỳ đĩa cứng nào cũng được nhận dạng bởi id hệ thống tệp duy nhất của nó, tên của đĩa và vị trí vật lý trên phần cứng mà nó được kết nối.

2) udev thực thi hoàn toàn trong không gian người dùng, trái ngược với không gian kernel của devfs. Một hậu quả là udev đã chuyển chính sách đặt tên ra khỏi kernel và có thể chạy các chương trình tùy ý để soạn tên cho thiết bị từ các thuộc tính của thiết bị, trước khi nút được tạo; ở đó, toàn bộ quá trình cũng bị gián đoạn và nó chạy với mức độ ưu tiên thấp hơn.

Tôi có lẽ nên thêm rằng với udev khả năng a race condition, về cơ bản làm suy yếu việc đặt tên thiết bị trong devfs và hotplug, là tránh. Nói cách khác: với các devfs, không có cách nào để đảm bảo rằng cổng ethernet ngoài cùng bên trái của bạn sẽ được gọi eth0và cổng ngoài cùng bên phải của nó eth1, làm cho việc thiết lập các bộ định tuyến (một cổng thành WAN, một cổng sang LAN) khó thực hiện triển khai thực hiện.

Việc áp dụng sơ đồ đặt tên của các đĩa dựa trên GUID là một điểm cộng khác và chuyển toàn bộ quá trình sang không gian người dùng thậm chí còn lớn hơn: bạn đã tìm kiếm qua trang web này để xem có bao nhiêu người viết quy tắc udev của riêng họ?

Là một ví dụ đơn giản về những lợi thế vốn có khi có udev trong không gian người dùng, hãy kiểm tra câu hỏi này hoặc câu hỏi khác , cả trên trang web này.