สำหรับเรื่องที่ว่าสิ่งที่ผิดกับพวงของไฟล์แบบคงที่ใน/dev? เห็นได้ชัดว่าไม่น่าพอใจพอที่นักพัฒนาจะได้คิดค้นล้อนี้ใหม่ด้วยการนับ 3 ครั้งของฉันในขณะนี้ ( devfs-> udev + HAL-> udev) และตอนนี้เห็นได้ชัดว่ากำลังเข้าสู่โปรแกรม Grand Unified Init ด้วยเช่นกันดังนั้นสี่ครั้ง

ฉันจำได้ว่าเมื่อฉันเริ่มใช้งาน Linux เมื่อหลายปีก่อนรู้สึกประหลาดใจที่แม้จะอ้างว่า "ทุกอย่างเป็นไฟล์" แต่ก็ไม่มี/dev/eth0(ที่สมเหตุสมผลในภายหลังเนื่องจากไม่ใช่อุปกรณ์ char หรือ block - แม้ว่าจะเป็นประเภทอุปกรณ์ "แพ็คเก็ต" ก็ตาม จะน่าสนใจ ... ) ระบุว่าทำไมโปรแกรมที่จัดการแผนภูมิต้นไม้อุปกรณ์ char และ block จึงต้องรับผิดชอบอุปกรณ์เครือข่ายด้วย? ฉันเคยเห็นการอ้างอิงที่คลุมเครือกับ "ความยืดหยุ่น" แต่สิ่งนี้เพิ่มอะไรมากกว่าพูดว่า ifconfig (8) ไม่เพียงแค่ดูใน/proc/net/dev? ตัวอย่างเช่นฉันรู้ว่า NetworkManager จะไม่อยู่ในเน็ตหรือ OpenBSD เร็ว ๆ นี้เพราะมันขึ้นอยู่กับudevว่าทีมไหนไม่ต้องการเขียน สิ่งที่ฉันไม่ได้/devที่มีการเปิดเผยหลายวิธีโดยเคอร์เนล (และไม่มีพวกเขาใน/dev!)

มันเป็นเพราะ hotplugging หรือไม่ มีปัญหากับเคอร์เนลเพียงแค่ฟังบัสโดยสารจริงและโหลดโมดูลที่เหมาะสมในข้อความ "เพิ่มอุปกรณ์" หรือไม่ หรือพระเจ้าห้ามผู้ดูแลระบบที่แท้จริงทำเช่นนั้น? ฉันจำได้ว่าในช่วงต้นปี 2000 เซิร์ฟเวอร์ของฉันบางครั้งจะเริ่มต้นการ์ดเครือข่ายตามลำดับที่คาดไม่ถึงและฉันคิดว่ามันสมเหตุสมผลที่จะตัดสินใจตั้งชื่อใน userland (แม้ว่ามันจะไม่ยากอย่างยิ่งที่จะแก้ไขกลับ) ดูเหมือนว่าค้อนขนาดใหญ่สำหรับแมลงสาบ (หรือปัญหาที่อาจเกิดขึ้นใช้กรณีที่ฉันไม่ได้คิดหนักกว่าเซิร์ฟเวอร์หรือพีซีแบบติดตั้งกับชั้นซึ่งเป็นประสบการณ์ของฉัน)

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

อีกสองสิ่ง: การย้ายของ Linux ไปยังองค์กรและเซิร์ฟเวอร์ขนาดใหญ่อื่น ๆ ก็คือการเปิดเผยแบบคง/devที่จะเสีย เทคโนโลยีที่ก้าวหน้าทั้งในผู้บริโภคและองค์กรต่างเปิดเผยเรื่องตลก / dev เป็นเรื่องตลก [คำตอบนี้เต็มไปด้วย backstory มากกว่าโดยเฉพาะอย่างยิ่งทำไม devfs จึงถูกแทนที่ด้วย udev]

อ่อนเพลียจาก Major & Minor Number Space

/devไฟล์จะถูกระบุภายในเคอร์เนลด้วยหมายเลขหลักและรองของพวกเขา เคอร์เนลไม่เคยสนใจชื่อจริง ๆ (และคุณสามารถทำได้mv /dev/sda /dev/disk-1และมันจะทำงานต่อไปได้แม้ว่าโปรแกรมแน่นอนจะไม่รู้ว่าจะหาได้จากที่ไหน)

ด้วยสแตติก/devคุณต้องจัดสรรหมายเลขหลัก / รองสำหรับอุปกรณ์ที่อาจเกิดขึ้นได้ ตัวเลขเหล่านี้ต้องไม่ซ้ำกันทั่วโลกเนื่องจากส่งเป็นส่วนหนึ่งของ distros ไม่ได้สร้างขึ้นตามความต้องการ ปัญหาคือว่าพวกเขาแต่ละหมายเลข 8 บิต - ช่วงคือ 0–255

ตัวอย่างเช่นในตอนแรก Linux เริ่มต้นด้วย 8,0 เป็น sda, 8,1 เป็น sda1, 8,16 เป็น sdb เป็นต้น แต่ผู้คนก็เพิ่มดิสก์เข้ากับเครื่องมากขึ้นเรื่อย ๆ ดังนั้นในบางจุดมีการเพิ่มหมายเลขหลัก 65-71 สำหรับดิสก์เพิ่มเติม ต่อมาหมายเลขหลัก 128–135 แต่ถึงกระนั้นผู้คนก็ยังต้องการดิสก์เพิ่มมากขึ้น ...

และรูปแบบตารางพาร์ติชั่นเช่น GPT มารองรับพาร์ติชันเพิ่มเติมต่อดิสก์ และแน่นอนว่าอุปกรณ์อื่น ๆ กำลังกินพื้นที่จำนวน: ตัวควบคุม RAID ต่างๆการจัดการปริมาณตรรกะ ฯลฯ

ผลลัพธ์ที่สามารถมองเห็นได้ในรายการอุปกรณ์ LANANA ลินุกซ์ หากคุณดูที่รายการ 2.6 (มีเพียงรายการเดียวเท่านั้น) จำนวนบล็อกหลักที่สำคัญจนถึง 200 (สูงสุด: 255) - ใช้แล้ว เห็นได้ชัดว่าตัวเลขจะหมด

การเปลี่ยนเป็นตัวเลขขนาดใหญ่นั้นไม่ใช่เรื่องง่าย มันเปลี่ยนเคอร์เนล ABI มันเปลี่ยนเค้าโครงบนดิสก์ขึ้นอยู่กับระบบไฟล์ แต่แน่นอนว่าอุปกรณ์เหล่านั้นส่วนใหญ่ไม่ได้มีอยู่ในระบบใดระบบหนึ่งแม้แต่อุปกรณ์ที่มี (เช่น) ดิสก์ SCSI ที่หมดอาจมีของฟรีมากมาย - มันอาจไม่ต้องการฮาร์ดดิสก์ IBM XT ตัวอย่างเช่น.

ด้วยไดนามิกได/devรฟ์ไม่จำเป็นต้องจัดส่งหมายเลขอุปกรณ์ พวกเขาไม่จำเป็นต้องเป็นเอกลักษณ์ระดับโลกอีกต่อไป พวกเขาไม่จำเป็นต้องมีเอกลักษณ์ในรองเท้าบูท

ชื่ออุปกรณ์ไม่แน่นอน

มันเคยเป็นเรื่องง่ายที่จะกำหนดหมายเลขให้กับทุกสิ่ง กระดานมีสองช่อง IDE; แต่ละช่องสัญญาณ IDE รองรับหนึ่งต้นแบบและสลาฟหนึ่งช่อง คุณสามารถกำหนดตามลำดับช่องทางและคำสั่ง master-then-slave ดังนั้นhdaจะกลายเป็นช่องทางแรกต้นแบบ; hdbช่องแรกทาส; hdcช่องทางที่สองต้นแบบ; เป็นต้นซึ่งสามารถคาดเดาได้และมีเสถียรภาพ อาจเปลี่ยนแปลงได้หากคุณเพิ่มไดรฟ์ใหม่หรือลบออกหนึ่งรายการ แต่หากไม่มีการเปลี่ยนแปลงฮาร์ดแวร์

คุณสามารถใส่/dev/hda1ในของคุณ/etc/fstabและจะมีความมั่นใจว่ามันจะอยู่ในการทำงานอย่างน้อยการเปลี่ยนแปลงฮาร์ดแวร์ขาด

IDE ทำงานเช่นนั้น ไม่มีอะไรหลังจากนั้น

SATA ดูเหมือนง่าย: หนึ่งพอร์ตหนึ่งดิสก์ แต่ไม่เป็นเช่นนั้น มันช่วยให้ตัวคูณพอร์ต และช่วยให้การสลับร้อน ยังคงไม่มีการเปลี่ยนแปลงฮาร์ดแวร์คุณยังสามารถใช้งานการทำแผนที่ได้

USB แย่ลงมาก มันไม่เพียง แต่อนุญาตให้สลับร้อนเท่านั้นมันเป็นเรื่องปกติ ผู้คนเสียบ USB แฟลชไดรฟ์ตลอดเวลา เพิ่มเติมอุปกรณ์อาจใช้เวลาสักครู่ในการสอบสวนและสามารถเปลี่ยนแปลงได้ทุกเมื่อที่พวกเขารู้สึกว่ามันชอบ (เช่นเมื่อเปิดหรือปิดโหมดที่เก็บข้อมูล USB บนโทรศัพท์ของคุณ) Firewire คล้ายกัน คุณไม่สามารถสร้างแผนที่ที่มั่นคงขึ้นได้

ดิสก์ที่เชื่อมต่อเครือข่ายไม่มีคำสั่งพอร์ตโดยธรรมชาติ คำสั่งเดียวที่เคอร์เนลใช้คือเรียงตามลำดับที่ปรากฏพร้อมกับโลจิคัลวอลุ่ม

การแสวงหาความเร็วในการบู๊ตทำให้สิ่งต่าง ๆ แย่ลงด้วย ในขั้นต้นเคอร์เนลจะนั่งรออย่างมีความสุขและรอเวลาค่อนข้างนานเช่นอุปกรณ์ USB ทั้งหมดเพื่อเริ่มต้น ในการตรวจสอบบัส SCSI ทั้งหมดอย่างเต็มที่ ฯลฯ โพรบเหล่านั้นถูกสร้างเป็นงานพื้นหลัง การบูตจะไม่รออีกต่อไป อุปกรณ์ถูกเพิ่มเมื่อโพรบเสร็จสมบูรณ์

ดังนั้นเคอร์เนลจึงเหลืออยู่ไม่มากก็น้อย "ไม่ว่าจะเรียงลำดับอะไรก็ตาม" นั่นหมายความว่าหลายประเภทของอุปกรณ์ที่สามารถและไม่เปลี่ยนแปลงการสั่งซื้อทุกบูตสิ่งที่อยู่ในการบู๊ตเป็นในการบูตอีก/dev/sdb /dev/sdcเรื่องนี้ทำให้ความคิดของ/devเรื่องตลกคงที่

สรุป

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

คำถามที่ดี.

ในทางใดทางหนึ่งอาร์กิวเมนต์นี้สามารถย้อนกลับไปได้: เนื่องจากเคอร์เนล 2.6.13 นำเสนอเวอร์ชันใหม่ของueventมันจึงต้องเกิดขึ้นdevfsอีกครั้งซึ่งจะต้องมีการเขียนใหม่เพื่อใช้ประโยชน์จากคุณลักษณะใหม่ของอินเทอร์เฟซ ดังนั้นในทางคำถามควรจะเป็นสาเหตุที่การเปลี่ยนแปลงในเคอร์เนล

อย่างไรก็ตามเมื่อคำนึงถึงคุณค่าแล้วคำถามของคุณจะได้รับคำตอบในบทความของ Wikipedia นี้ :

แตกต่างจากระบบ Unix ทั่วไปที่โหนดอุปกรณ์ในไดเรกทอรี / dev เป็นชุดของไฟล์แบบคงที่ตัวจัดการอุปกรณ์ Linux udev จะจัดเตรียมเฉพาะโหนดสำหรับอุปกรณ์ที่มีอยู่จริงในระบบ แม้ว่า devfs จะใช้ในการจัดเตรียมการทำงานที่คล้ายกัน Greg Kroah-Hartman อ้างถึงสาเหตุหลายประการในการเลือกใช้งาน devfs:

1) udev รองรับการตั้งชื่ออุปกรณ์ถาวรซึ่งไม่ได้ขึ้นอยู่กับตัวอย่างเช่นลำดับที่อุปกรณ์ถูกเสียบเข้ากับระบบ การตั้งค่าเริ่มต้น udev ให้ชื่อถาวรสำหรับอุปกรณ์เก็บข้อมูล ฮาร์ดดิสก์ใด ๆ ได้รับการยอมรับโดย id ระบบไฟล์ที่ไม่ซ้ำกันชื่อของดิสก์และตำแหน่งทางกายภาพของฮาร์ดแวร์ที่เชื่อมต่ออยู่

2) udev ดำเนินการทั้งหมดในพื้นที่ของผู้ใช้ซึ่งต่างจากพื้นที่เคอร์เนลของ devfs ผลลัพธ์อย่างหนึ่งคือ udev ย้ายนโยบายการตั้งชื่อออกจากเคอร์เนลและสามารถเรียกใช้โปรแกรมโดยพลการเพื่อตั้งชื่ออุปกรณ์จากคุณสมบัติของอุปกรณ์ก่อนที่จะสร้างโหนด ที่นั่นกระบวนการทั้งหมดก็ขัดจังหวะและทำงานด้วยลำดับความสำคัญต่ำกว่า

ฉันอาจจะเพิ่มด้วย udev ความเป็นไปได้ของrace conditionซึ่งโดยทั่วไปจะทำลายการตั้งชื่อของอุปกรณ์ใน devfs และ hotplug จะหลีกเลี่ยง กล่าวอีกนัยหนึ่ง: ด้วย devfs ไม่มีวิธีที่จะทำให้แน่ใจว่าพอร์ตอีเธอร์เน็ตซ้ายสุดของคุณจะถูกเรียกeth0และพอร์ตที่ถูกที่สุดeth1ทำให้การตั้งค่าเราเตอร์ (หนึ่งพอร์ตเป็น WAN หนึ่งพอร์ตไปยัง LAN) ยากที่จะ การดำเนินการ

การนำรูปแบบการตั้งชื่อดิสก์มาใช้บนพื้นฐานของ GUID นั้นเป็นข้อดีอีกอย่างหนึ่งและการย้ายกระบวนการทั้งหมดไปยังพื้นที่ของผู้ใช้ยิ่งใหญ่กว่านี้: คุณเคยค้นหาในเว็บไซต์นี้เพื่อดูว่ามีคนเขียนกฎ udev ของตัวเองกี่คน?

เป็นตัวอย่างง่ายๆของข้อดีที่มีอยู่ในการมี udev ใน userspace ให้ตรวจสอบคำถามนี้หรือคำถามอื่น ๆทั้งในเว็บไซต์นี้