Bu konuda, bir sürü statik dosyada tam olarak yanlış olan neydi /dev? Geliştiricilerin bu tekerleği şimdiye kadar 3 kez ( devfs-> udev + HAL-> udev) benim sayımla yeniden icat etmeleri yeterince tatmin edici görünmüyor ve şimdi de görünüşe göre Grand Unified Init Programına dört kez gidiyor.

Linux'u ilk kullanmaya başladığımda yıllar önce "her şeyin bir dosya olduğunu" iddia etmesine /dev/eth0rağmen, "paket" bir cihaz türü olmasına rağmen "char" veya "blok" bir cihaz olmadığı için mantıklı olmadığını hatırlıyorum. ilginç olurdu ...). Buna göre, char ve blok aygıt dosyasını barındıran program ağ ağacından neden sorumludur? Ben "esneklik" için belirsiz başvuruları gördüm ama bu ne üzerinde eklese ne diyelim ki, ifconfig (8) sadece bakarak yapar /proc/net/dev? Mesela, NetworkManager yakın zamanda Net veya OpenBSD’de olmayacak, çünkü udevne takımın yazmak istediğine bağlı; ne yapıyorum/devbu zaten çekirdek tarafından birçok şekilde ortaya çıkar (ve hiçbiri /dev!).

Sadece hotplugging yüzünden mi? Çekirdeğin sadece fiziksel otobüsleri dinlemesi ve uygun modülleri bir "cihaz eklenmiş" mesajına yerleştirmesiyle ilgili sorunlar var mıydı? Ya da, Tanrı korusun, gerçek yönetici öyle mi yapıyor? 2000'lerin başında sunucularım bazen ağ kartlarını beklenmedik bir sırayla başlatacaklarını hatırlıyorum ve sanırım bu ismin kullanıcıya göre karar vermesinin mantıklı olduğunu düşünüyorum (o zamanlar bunu düzeltmek çok zor olmasa da). Bu hamamböceği için bir balyoz gibi görünüyor. (Ya da belki bu problem, benim deneyimim olan rafa monte edilmiş sunuculardan ya da bilgisayarlardan daha fazla düşünmeyi düşünmediğim durumları kullanır.)

Öyleyse sorumu açık bir şekilde ifade etmek için: udev gerçekte hangi sorunları çözüyor ve devfs, HAL ve / veya eski düz bir dosya bunları nasıl çözemedi? Bir çok farklı şeyin (hotplugging, genel cihaz yönetimi, ağ cihazı yönetimi, cihaz isimlendirme, sürücü önceliği, vb.) Hepsinin bir program olması için özel bir sebep var mı?

İki şey daha: Linux'un şirkete ve diğer büyük sunuculara taşınması statik /devkırılmaya neden oldu. Hem tüketici hem de işletmede, ileri teknoloji, statik / dev'i şaka olarak ortaya koyuyordu. [Bu cevap arkaplanın çoğunu doldurur, özellikle devfs'in neden udev ile değiştirildiğini].

Büyük ve Küçük Sayı Alanlarının Tükenmesi

/devdosyalar çekirdeğin içindeki büyük ve küçük sayılarla tanımlanır. Çekirdek aslında adı hiç umursamadı (ve örneğin, mv /dev/sda /dev/disk-1ve çalışmaya devam edecektiniz - elbette programlar onu nerede bulacağını bilmese bile).

Statikle /dev, olabilecek her potansiyel cihaz için büyük / küçük bir sayı ayırmanız gerekir. Bu rakamların, talep üzerine yaratılmayan dağıtımların bir parçası olarak gönderildiğinden, küresel olarak benzersiz olmaları gerekir. Sorun, her birinin 8 bitlik sayıları olmasıdır - aralık, 0-255'tir.

Örneğin, Linux, 8,0 sda, 8,1 sda1, 8,16 sdb, vb. İle başladı. Fakat insanlar, özellikle fiber kanal gibi şeyler düşündüğünüzde makinelere daha fazla disk eklemeye devam ettiler. Bir noktada, daha fazla disk için 65-71 arası büyük sayılar eklendi. Daha sonra, büyük sayılar 128–135. Ve yine de insanlar daha fazla disk istemeye devam etti ...

GPT gibi bölüm tablosu biçimleri ortaya çıktı ve disk başına daha fazla bölüm desteklendi. Ve elbette, diğer cihazlar sayı alanı boyunca yemek yiyorlardı: çeşitli RAID denetleyicileri, mantıksal ses yönetimi vb.

Sonuçta LANANA Linux Aygıt Listesi'nde görülebilir . 2.6 listesine bakarsanız (hala orada olan tek kişi), büyük sayıdaki 200 sayıdaki (maks: 255) blok kullanılır. Açıkça, sayılar tükenirdi.

Daha büyük sayılara geçmek kolay değildi. ABI çekirdeğini değiştirir. Dosya sistemine bağlı olarak, disk düzenini değiştirir. Ancak, elbette, bu cihazların çoğu herhangi bir sistemde mevcut değildi, hatta (örneğin) SCSI diskleri tükenmişti bile, muhtemelen bol miktarda ücretsiz şeyler vardı - muhtemelen bir IBM XT sabit diskine ihtiyaç duymuyordu, Örneğin.

Bir dinamik /devolduğunda, dağıtım cihaz numaralarını göndermek zorunda değildir. Artık küresel olarak benzersiz olmaları gerekmiyor. Botlar arasında benzersiz olmaları bile gerekmez.

Cihaz isimleri tahmin edilemezdi

Her şeye bir sayı atamak gerçekten kolaydı. Bir kurulun iki IDE kanalı vardı; Her IDE kanalı bir master ve bir slave destekledi. Kanal sırasına ve master-then-slave sırasına atayabilirsiniz. Böylece hdailk kanal olur, usta; hdbilk kanal, köle; hdcikinci kanal, ana; vb. Bunlar öngörülebilir ve kararlıydı. Yeni bir sürücü eklerseniz veya çıkarırsanız değişebilirler, ancak donanım değişikliği yoksa, bunlar statikti.

Sen koyabilirsiniz /dev/hda1Gözlerinde farklı /etc/fstabve çalışma kalmak en azından eksik donanım değişiklikleri ediyorum emin olun.

IDE böyle çalıştı. Ondan sonra bir şey yok.

SATA basit görünüyor: bir port, bir disk. Ama öyle değil; port çarpanlarına izin verir. Ve çalışırken değiştirilebilir. Yine de, hiçbir donanım değişikliği olmazsa, haritayı çalışmaya devam ettirmeye devam edebilirsiniz.

USB çok daha kötü. Yalnızca çalışırken değiştirmeye izin vermekle kalmaz, tipiktir. İnsanlar her zaman USB flash sürücüler takarlar. Ayrıca, cihazların araştırması biraz zaman alabilir ve ne zaman isterlerse değişebilir (örneğin, telefonunuzdaki USB depolama modunu açıp kapattığınızda). Firewire benzer. Hiçbirinde, gerçekten kararlı bir haritalama yapamazsınız.

Ağa bağlı disklerde herhangi bir iç port sırası yoktur. Çekirdeğin kullandığı tek sıra, göründükleri sıradır. Mantıksal birimlerle aynıdır.

Önyükleme hızı arayışı da işleri daha da kötüleştirdi. Başlangıçta, çekirdek mutlu bir şekilde oturur ve örneğin tüm USB cihazlarının başlatılması için oldukça uzun süre beklerdi. Tüm SCSI otobüslerini vs. tamamen araştırmak için. Bu sondalar arka plan görevlerine dönüştürüldü; önyükleme artık onları beklemeyecekti. Cihazlar, problar tamamlandıktan sonra eklenir.

Bu yüzden çekirdek, aşağı yukarı "hangi sırayla ortaya çıkarsalar" ile bırakıldı. Bu, birçok önyükleme aygıtının her önyükleme sırasını değiştirebileceği ve değiştirdiği anlamına geliyordu; bir önyüklemede /dev/sdbolan başka bir önyüklemede /dev/sdc. Bu, statik fikrini /devşaka yapar.

özet

/devTahmin edilemeyen cihaz prob siparişleri nedeniyle statikin önemsiz hale gelmesinin kombinasyonunu aldığınızda ve önemli bir çalışmanın bitmemesine yol açan statik büyük / küçük sayıları tahsis etmeye devam ettiğinizde, Linux geliştiricilerin neden bir dinamiğe geçmeyi seçtikleri anlaşılıyor /dev.

İyi soru.

Bir şekilde, bu argüman tersine çevrilebilir: 2.6.13 çekirdeği yeni bir versiyonunu ueventsunduğundan devfs, arayüzün yeni özelliklerinden yararlanmak için yeniden yazılması gereken bir durum ortaya çıktı . Öyleyse, bir bakıma soru, çekirdekteki değişimin neden olması gerektiğidir.

Bununla birlikte, değeri gerçek olan bu Vikipedi'nin makalesinde sorunuzu yanıtlayın :

/ Dev dizinindeki aygıt düğümlerinin statik bir dosya kümesi olduğu geleneksel Unix sistemlerinin aksine, Linux udev aygıt yöneticisi dinamik olarak yalnızca bir sistemde bulunan aygıtlar için düğümleri sağlar. Devfs benzer işlevsellik sağlamak için kullanılsa da, Greg Kroah-Hartman, devfs yerine uygulanmasını tercih etmek için bir takım nedenlerden bahsetti:

1) udev, örneğin cihazların sisteme takılı olduğu sıraya bağlı olmayan kalıcı cihaz adlandırmalarını destekler. Varsayılan udev ayarları, depolama aygıtları için kalıcı adlar sağlar. Herhangi bir sabit disk, benzersiz dosya sistemi kimliği, diskin adı ve bağlı olduğu donanımdaki fiziksel konumu ile tanınır.

2) udev, devfs'nin çekirdek alanının aksine tamamen kullanıcı alanında çalışır. Bunun bir sonucu olarak, udev adlandırma politikasını çekirdeğin dışına çıkardı ve düğüm oluşturulmadan önce cihazın adını aygıtın özelliklerinden bir ad oluşturmak için isteğe bağlı programlar çalıştırabilir; orada, tüm süreç de kesilebilir ve daha düşük bir öncelikle çalışır.

Muhtemelen udev ile race conditiondevfs ve hotplug'daki cihazların isimlendirilmesinde temelde zayıf olan bir a ihtimalinden kaçınılması gerektiğini eklemeliyim . Başka bir deyişle: devfs ile en soldaki ethernet portunuzun çağrılmasının eth0ve en sağdaki yolunun aranmasını sağlamanın hiçbir yolu yoktu, eth1(saf bir örnek olarak) yönlendiricilerin (WAN'a bir port, bir LAN'a LAN) kurulumunu zorlaştırıyordu. uygulamak.

Disklerin adlandırma düzeninin GUID'e dayanarak benimsenmesi bir başka artıdır ve tüm süreci kullanıcı alanına daha da büyük bir alan haline getirir: kaç kişinin kendi udev kurallarını yazdığını görmek için bu siteyi aradınız mı?

Kullanıcı alanında udev'in doğasında var olan avantajların basit bir örneği olarak , hem bu sitede hem de bu soruda ya da bu diğer soruyu kontrol edin .