เหตุใดอินเทอร์เฟซเครือข่ายจึงไม่เหมือนกันในอุปกรณ์อื่น ๆ ?

ฉันอยากรู้อยากเห็นเป็นส่วนใหญ่ แต่ทำไมไม่เชื่อมต่อเครือข่ายใน / dev? มีอุปกรณ์ประเภทอื่น ๆ ที่ไม่แสดงเป็นโหนดภายใต้ / dev หรือไม่

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

อุปกรณ์บางอย่างนั้นเหมือนกับไฟล์ทั่วไปมาก: มันทำมาจากจำนวนไบต์ที่ จำกัด และสิ่งที่คุณเขียนในตำแหน่งที่กำหนดสามารถอ่านได้จากตำแหน่งเดียวกันในภายหลัง อุปกรณ์เหล่านี้จะเรียกว่าอุปกรณ์ป้องกัน

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

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

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

{ echo $'GET http://www.google.com/ HTTP/1.0\r';
  echo $'Host: www.google.com\r';
  echo $'\r' >&0; cat; } <>/dev/tcp/www.google.com/80

ในความเป็นจริง ksh และ bash จัดเตรียมอินเทอร์เฟซสำหรับไคลเอนต์ TCP และ UDP อย่างไรก็ตามโดยทั่วไปแอปพลิเคชันเครือข่ายมีความซับซ้อนกว่าแอปพลิเคชันที่เข้าถึงไฟล์ ในขณะที่การแลกเปลี่ยนข้อมูลส่วนใหญ่จะดำเนินการด้วยการโทรคล้ายกับreadและการwriteสร้างการเชื่อมต่อที่ต้องการข้อมูลเพิ่มเติมมากกว่าแค่ชื่อไฟล์ ตัวอย่างเช่นการฟังการเชื่อมต่อ TCP มีสองขั้นตอน: หนึ่งที่จะดำเนินการเมื่อเซิร์ฟเวอร์เริ่มฟังและหนึ่งที่จะดำเนินการในแต่ละครั้งที่ลูกค้าเชื่อมต่อ ขั้นตอนพิเศษดังกล่าวไม่เหมาะกับไฟล์ API ซึ่งเป็นสาเหตุหลักที่ทำให้ระบบเครือข่ายมี API ของตัวเอง

อุปกรณ์อีกประเภทหนึ่งที่โดยทั่วไปแล้วไม่มีรายการใน/devบน Linux (แต่มีในรุ่นที่แตกต่างจากยูนิกซ์) คืออะแดปเตอร์วิดีโอ ตามหลักการแล้วอะแดปเตอร์วิดีโออย่างง่ายอาจถูกเปิดเผยเป็นอุปกรณ์framebufferซึ่งอาจเป็นอุปกรณ์บล็อกที่ทำจากบล็อกที่แสดงสีของแต่ละพิกเซล อะแดปเตอร์วิดีโอเร่งความเร็วสามารถแสดงเป็นอุปกรณ์ตัวอักษรที่แอปพลิเคชันส่งคำสั่ง ที่นี่ข้อเสียเปรียบของอินเทอร์เฟซอุปกรณ์คือมันช้า: แอปพลิเคชันการแสดงผล (ในทางปฏิบัติเซิร์ฟเวอร์ X) จะต้องทำการโทรเคอร์เนลทุกครั้งที่แสดงอะไร สิ่งที่เกิดขึ้นแทนคือเซิร์ฟเวอร์ X ส่วนใหญ่เขียนโดยตรงไปยังหน่วยความจำของอะแดปเตอร์วิดีโอเพราะมันเร็วกว่า

คุณสามารถค้นหาได้ใน/sys/class/netไดเรกทอรี มันลิงก์สัญลักษณ์ไปยังไฟล์อื่น ๆ ใน/sys/device/../../ต่อไปนี้เป็นผลลัพธ์เครื่องเสมือนของฉัน (linux kernel 3.10) และคุณสามารถใช้คำสั่งudevadm info <filename>เพื่อดูคุณสมบัติของมัน

lrwxrwxrwx. 1 root root 0 Apr  3 13:38 ens33 -> ../../devices/pci0000:00/0000:00:11.0/0000:02:01.0/net/ens33

AT & T / Solaris "Transport Level Interface" (TLI) วิธีการทำเครือข่าย TCP / IP มีไฟล์พิเศษเช่น "/ dev / tcp" หรือ "/ dev / udp" โปรแกรมเมอร์เปิดไฟล์พิเศษนั้นเพื่อรับซ็อกเก็ตของตระกูลโปรโตคอลที่เหมาะสม ฉันคิดว่านั่นเป็นเหตุผลที่คุณต้องมี "-lnsl" เมื่อรวบรวมโปรแกรมที่ใช้ซ็อกเก็ตบน Solaris: ภายใต้โปรแกรม TLI

แม้ว่า Linux ดั้งเดิมจะไม่ได้เป็นไปอย่างสมบูรณ์ posix นับประสาแม้ปฏิบัติตามมาตรฐาน Open Group ทุกประเภท (นอก LSB อาจ) มีความพยายามในการพอร์ตฟังก์ชันการทำงานของ UNIX เพิ่มเติมลงใน Linux

Glendix เป็นโครงการหนึ่งที่ให้บริการพอร์ตของระบบไฟล์เสมือน / สุทธิจาก Plan9 ซึ่งให้คุณทำตามที่อธิบายไว้

Plan9 Port / ระบบไฟล์สุทธิไปยัง linux