Jadi pada dasarnya ada dua jenis hal yang berbeda di sini:
- Sistem file normal, yang menyimpan file dalam direktori dengan data dan metadata, dengan cara yang biasa (termasuk tautan lunak, tautan keras, dan seterusnya). Ini sering, tetapi tidak selalu, didukung oleh perangkat blok untuk penyimpanan persisten (tmpfs hanya hidup di RAM, tetapi sebaliknya identik dengan sistem file normal). Semantik ini sudah tidak asing lagi; baca, tulis, ganti nama, dan seterusnya, semua berfungsi seperti yang Anda harapkan.
- Sistem file virtual, dari berbagai jenis.
/proc
dan/sys
adalah contohnya di sini, seperti juga sistem file kustom FUSE sepertisshfs
atauifuse
. Ada lebih banyak keragaman dalam hal ini, karena sebenarnya mereka hanya merujuk ke sistem file dengan semantik yang dalam beberapa hal 'disesuaikan'. Jadi, saat Anda membaca dari file di bawah/proc
, Anda sebenarnya tidak mengakses bagian data tertentu yang telah disimpan oleh sesuatu yang lain yang menulisnya sebelumnya, seperti pada sistem file normal. Anda pada dasarnya melakukan panggilan kernel, meminta beberapa informasi yang dihasilkan saat itu juga. Dan kode ini dapat melakukan apa saja yang disukainya, karena ini hanyalah beberapa fungsi di suatu tempat yang mengimplementasikanread
semantik. Dengan demikian, Anda memiliki perilaku aneh file di bawah/proc
, seperti misalnya berpura-pura menjadi symlink padahal sebenarnya tidak.
Kuncinya adalah /dev
itu sebenarnya, biasanya, salah satu dari jenis pertama. Adalah normal dalam distribusi modern untuk memiliki /dev
menjadi sesuatu seperti tmpfs, tetapi dalam sistem yang lebih lama, adalah normal untuk menjadikannya direktori biasa pada disk, tanpa atribut khusus apa pun. Kuncinya adalah file di bawah /dev
adalah node perangkat, sejenis file khusus yang mirip dengan soket FIFO atau Unix; node perangkat memiliki nomor besar dan kecil, dan membaca atau menulisnya adalah melakukan panggilan ke driver kernel, seperti membaca atau menulis FIFO memanggil kernel untuk menyangga output Anda dalam sebuah pipa. Pengemudi ini dapat melakukan apa pun yang diinginkannya, tetapi biasanya menyentuh perangkat keras, mis. untuk mengakses hard disk atau memutar suara di speaker.
Untuk menjawab pertanyaan awal:
-
Ada dua pertanyaan yang relevan apakah 'file itu ada' atau tidak; ini adalah apakah file node perangkat benar-benar ada, dan apakah kode kernel yang mendukungnya bermakna. Yang pertama diselesaikan seperti apa pun pada sistem file normal. Sistem modern menggunakan
udev
atau sesuatu seperti itu untuk menonton peristiwa perangkat keras dan secara otomatis membuat dan menghancurkan node perangkat di bawah/dev
demikian. Tetapi sistem yang lebih lama, atau build kustom ringan, hanya dapat memiliki semua node perangkatnya secara harfiah di disk, dibuat sebelumnya. Sementara itu, ketika Anda membaca file-file ini, Anda sedang melakukan panggilan ke kode kernel yang ditentukan oleh nomor perangkat mayor dan minor; jika ini tidak masuk akal (misalnya, Anda mencoba membaca perangkat blokir yang tidak ada), Anda hanya akan mendapatkan semacam kesalahan I/O. -
Cara kerjanya adalah kode kernel apa yang harus dipanggil untuk file perangkat mana yang bervariasi. Untuk sistem file virtual seperti
/proc
, mereka mengimplementasikanread
mereka sendiri danwrite
fungsi; kernel hanya memanggil kode itu tergantung pada titik pemasangannya, dan implementasi sistem file menangani sisanya. Untuk file perangkat, dikirim berdasarkan nomor perangkat mayor dan minor.
Berikut daftar file /dev/sda1
di server Arch Linux saya yang terbaru:
% ls -li /dev/sda1
1294 brw-rw---- 1 root disk 8, 1 Nov 9 13:26 /dev/sda1
Jadi entri direktori di /dev/
untuk sda
memiliki nomor inode, 1294. Ini adalah file asli di disk.
Lihatlah di mana ukuran file biasanya muncul. "8, 1" muncul sebagai gantinya. Ini adalah nomor perangkat utama dan kecil. Perhatikan juga 'b' di izin file.
File /usr/include/ext2fs/ext2_fs.h
berisi (fragmen) C struct:
/*
* Structure of an inode on the disk
*/
struct ext2_inode {
__u16 i_mode; /* File mode */
Struct itu menunjukkan kepada kita struktur on-disk dari inode file. Banyak hal menarik yang ada di dalam struktur itu; perhatikan baik-baik.
i_mode
elemen struct ext2_inode
memiliki 16 bit, dan hanya menggunakan 9 untuk izin pengguna/grup/lainnya, baca/tulis/eksekusi, dan 3 lainnya untuk setuid, setgid, dan sticky. Ada 4 bit untuk membedakan antara jenis seperti "file biasa", "tautan", "direktori", "pipa bernama", "soket keluarga Unix", dan "perangkat blok".
Kernel Linux dapat mengikuti algoritme pencarian direktori biasa, lalu membuat keputusan berdasarkan izin dan tanda di i_mode
elemen. Untuk 'b', blokir file perangkat, ia dapat menemukan nomor perangkat mayor dan minor, dan secara tradisional, gunakan nomor perangkat utama untuk mencari pointer ke beberapa fungsi kernel (driver perangkat) yang berhubungan dengan disk. Nomor perangkat minor biasanya digunakan sebagai, misalnya, nomor perangkat bus SCSI, atau nomor perangkat EIDE atau semacamnya.
Beberapa keputusan lain tentang cara menangani file seperti /proc/cpuinfo
dibuat berdasarkan jenis sistem file. Jika Anda melakukan:
% mount | grep proc
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
Anda dapat melihat bahwa /proc
memiliki tipe sistem file "proc". Membaca dari file di /proc
menyebabkan kernel melakukan sesuatu yang berbeda berdasarkan jenis sistem file, sama seperti membuka file pada sistem file ReiserFS atau DOS akan menyebabkan kernel menggunakan fungsi yang berbeda untuk menemukan file, dan menemukan data file.
Pada akhirnya, mereka semua adalah file untuk Unix, itulah keindahan abstraksinya.
Cara file ditangani oleh kernel, sekarang adalah cerita yang berbeda.
/proc dan saat ini /dev dan /run (alias /var/run) adalah sistem file virtual dalam RAM. /proc adalah antarmuka/jendela untuk variabel dan struktur kernel.
Saya sarankan membaca Kernel Linux http://tldp.org/LDP/tlk/tlk.html dan Linux Device Drivers, Edisi Ketiga https://lwn.net/Kernel/LDD3/.
Saya juga menikmati Desain dan Implementasi Sistem Operasi FreeBSD http://www.amazon.com/Design-Implementation-FreeBSD-Operating-System/dp/0321968972/ref=sr_1_1
Lihat halaman relevan yang berkaitan dengan pertanyaan Anda.
http://www.tldp.org/LDP/tlk/dd/drivers.html