Mengapa / dev / null sebuah file? Mengapa fungsinya tidak diimplementasikan sebagai program sederhana?

Saya mencoba memahami konsep file khusus di Linux. Namun, memiliki file khusus /devtampaknya konyol ketika fungsinya dapat diimplementasikan oleh beberapa baris dalam C sepengetahuan saya.

Selain itu, Anda bisa menggunakannya dengan cara yang hampir sama, yaitu menyalurkan ke nullalih alih mengarahkan /dev/null. Apakah ada alasan khusus untuk menjadikannya sebagai file? Tidak menjadikannya file yang menyebabkan banyak masalah lain seperti terlalu banyak program yang mengakses file yang sama?

Selain manfaat kinerja menggunakan perangkat khusus karakter, manfaat utama adalah modularitas . / dev / null dapat digunakan di hampir semua konteks di mana file diharapkan, bukan hanya di jaringan pipa shell. Pertimbangkan program yang menerima file sebagai parameter baris perintah.

# We don't care about log output.
$ frobify --log-file=/dev/null

# We are not interested in the compiled binary, just seeing if there are errors.
$ gcc foo.c -o /dev/null  || echo "foo.c does not compile!".

# Easy way to force an empty list of exceptions.
$ start_firewall --exception_list=/dev/null

Ini semua adalah kasus di mana menggunakan program sebagai sumber atau bak cuci akan sangat rumit. Bahkan dalam kasus shell pipeline, stdout dan stderr dapat diarahkan ke file secara mandiri, sesuatu yang sulit dilakukan dengan executable seperti sink:

# Suppress errors, but print output.
$ grep foo * 2>/dev/null

Dalam keadilan, ini bukan file biasa per se; itu adalah perangkat khusus karakter :

$ file /dev/null
/dev/null: character special (3/2)

Ini berfungsi sebagai perangkat dan bukan sebagai file atau program berarti itu adalah operasi yang lebih sederhana untuk mengarahkan input atau output dari itu, karena dapat dilampirkan ke deskriptor file apa pun, termasuk input / output / kesalahan standar.

Saya curiga mengapa ada banyak hubungannya dengan visi / desain yang berbentuk Unix (dan akibatnya Linux), dan keuntungan yang berasal dari itu.

Tidak diragukan lagi ada manfaat kinerja yang tidak dapat diabaikan untuk tidak memutar proses tambahan, tapi saya pikir ada lebih dari itu: Early Unix memiliki metafora "semuanya adalah file", yang memiliki keuntungan yang tidak jelas namun elegan jika Anda melihat itu dari perspektif sistem, bukan dari perspektif skrip shell.

Katakanlah Anda memiliki nullprogram command-line Anda, dan /dev/nullsimpul perangkat. Dari perspektif shell-scripting, foo | nullprogram ini benar-benar berguna dan nyaman , dan foo >/dev/nullmembutuhkan sedikit waktu lebih lama untuk mengetik dan bisa terasa aneh.

Tapi inilah dua latihan:

1. Mari kita melaksanakan program nullmenggunakan alat Unix yang ada dan /dev/null- mudah: cat >/dev/null. Selesai.

2. Anda dapat menerapkan /dev/nulldalam hal null?

Anda memang benar bahwa kode C untuk hanya membuang input itu sepele, jadi mungkin belum jelas mengapa ada file virtual yang tersedia untuk tugas tersebut.

Pertimbangkan: hampir setiap bahasa pemrograman sudah perlu bekerja dengan file, deskriptor file, dan path file, karena mereka adalah bagian dari paradigma "semuanya adalah file" dari awal.

Jika semua yang Anda miliki adalah program yang menulis ke stdout, well, program tidak peduli jika Anda mengarahkan mereka ke file virtual yang menelan semua penulisan, atau pipa ke program yang menelan semua penulisan.

Sekarang jika Anda memiliki program yang mengambil jalur file untuk membaca atau menulis data (yang dilakukan sebagian besar program) - dan Anda ingin menambahkan fungsionalitas "input kosong" atau "buang hasil ini" ke program-program tersebut - yah, dengan /dev/nullyang gratis.

Perhatikan bahwa keanggunannya adalah mengurangi kompleksitas kode dari semua program yang terlibat - untuk setiap usecase umum-tetapi-khusus yang dapat disediakan oleh sistem Anda sebagai "file" dengan "nama file" yang sebenarnya, kode Anda dapat menghindari penambahan perintah kustom Opsi-line dan jalur kode khusus untuk ditangani.

Rekayasa perangkat lunak yang baik sering tergantung pada menemukan metafora yang baik atau "alami" untuk mengabstraksi beberapa elemen masalah dengan cara yang menjadi lebih mudah untuk dipikirkan tetapi tetap fleksibel , sehingga Anda dapat memecahkan berbagai masalah tingkat tinggi yang pada dasarnya sama tanpa harus menghabiskan waktu dan energi mental untuk mengimplementasikan kembali solusi untuk masalah tingkat rendah yang sama secara konstan.

"Semuanya adalah file" tampaknya menjadi salah satu metafora untuk mengakses sumber daya: Anda memanggil openjalur yang diberikan dalam namespace heirarkis, mendapatkan referensi (deskriptor file) ke objek, dan Anda dapat readdan write, dll pada deskriptor file. Stdin / stdout / stderr Anda juga deskriptor file yang baru saja dibuka sebelumnya untuk Anda. Pipa Anda hanyalah file dan deskriptor file, dan pengalihan file memungkinkan Anda merekatkan semua bagian ini.

Unix berhasil seperti halnya sebagian karena seberapa baik abstraksi ini bekerja bersama, dan /dev/nullpaling baik dipahami sebagai bagian dari keseluruhan itu.

PS Ada baiknya melihat versi Unix dari "semuanya adalah file" dan hal-hal seperti /dev/nullsebagai langkah pertama menuju generalisasi metafora yang lebih fleksibel dan kuat yang telah diterapkan di banyak sistem yang mengikuti.

Sebagai contoh, di Unix objek seperti file khusus seperti /dev/nullharus diimplementasikan dalam kernel itu sendiri, tetapi ternyata cukup berguna untuk mengekspos fungsionalitas dalam bentuk file / folder yang sejak itu banyak sistem telah dibuat yang menyediakan jalan bagi program untuk melakukannya.

Salah satu yang pertama adalah sistem operasi Plan 9, yang dibuat oleh beberapa orang yang sama yang membuat Unix. Kemudian, GNU Hurd melakukan sesuatu yang mirip dengan "penerjemahnya". Sementara itu, Linux akhirnya mendapatkan FUSE (yang telah menyebar ke sistem arus utama lainnya sekarang juga).

Saya pikir /dev/nulladalah perangkat karakter (yang berperilaku seperti file biasa), bukan program untuk alasan kinerja .

Jika itu akan menjadi sebuah program, itu akan memerlukan memuat, memulai, menjadwalkan, menjalankan, dan setelah itu menghentikan dan membongkar program. Program C sederhana yang Anda gambarkan tentu saja tidak akan menghabiskan banyak sumber daya, tetapi saya pikir itu membuat perbedaan yang signifikan ketika mempertimbangkan sejumlah besar (katakanlah jutaan) tindakan pengalihan / perpipaan karena operasi manajemen proses mahal dalam skala besar seperti mereka melibatkan sakelar konteks.

Asumsi lain: Memipipkan ke dalam suatu program membutuhkan memori yang akan dialokasikan oleh program penerima (bahkan jika itu dibuang langsung sesudahnya). Jadi, jika Anda menyambungkan ke alat Anda memiliki konsumsi memori ganda, sekali pada program pengiriman dan sekali lagi pada program penerima.

Selain "semuanya adalah file" dan karenanya mudah digunakan di mana-mana berdasarkan sebagian besar jawaban lain, ada juga masalah kinerja seperti yang disebutkan oleh @ user5626466.

Untuk ditampilkan dalam praktik, kami akan membuat program sederhana bernama nullread.c:

#include <unistd.h>
char buf[1024*1024];
int main() {
        while (read(0, buf, sizeof(buf)) > 0);
}

dan kompilasi dengan gcc -O2 -Wall -W nullread.c -o nullread

(Catatan: kita tidak dapat menggunakan lseek (2) pada pipa, jadi satu-satunya cara untuk mengeringkan pipa adalah dengan membacanya sampai kosong).

% time dd if=/dev/zero bs=1M count=5000 |  ./nullread
5242880000 bytes (5,2 GB, 4,9 GiB) copied, 9,33127 s, 562 MB/s
dd if=/dev/zero bs=1M count=5000  0,06s user 5,66s system 61% cpu 9,340 total
./nullread  0,02s user 3,90s system 41% cpu 9,337 total

sedangkan dengan /dev/nullredirection file standar, kami mendapatkan kecepatan yang jauh lebih baik (karena fakta-fakta yang disebutkan: kurang konteks switching, kernel hanya mengabaikan data daripada menyalinnya dll):

% time dd if=/dev/zero bs=1M count=5000 > /dev/null
5242880000 bytes (5,2 GB, 4,9 GiB) copied, 1,08947 s, 4,8 GB/s
dd if=/dev/zero bs=1M count=5000 > /dev/null  0,01s user 1,08s system 99% cpu 1,094 total

(ini seharusnya menjadi komentar di sana, tetapi terlalu besar untuk itu dan benar-benar tidak dapat dibaca)

Pertanyaan Anda diajukan seolah-olah sesuatu akan diperoleh mungkin dalam kesederhanaan dengan menggunakan program nol sebagai pengganti file. Mungkin kita bisa menyingkirkan gagasan "file ajaib" dan sebagai gantinya hanya "pipa biasa".

Tapi pertimbangkan, pipa juga file . Mereka biasanya tidak dinamai, dan hanya dapat dimanipulasi melalui deskriptor file mereka.

Pertimbangkan contoh yang agak dibuat-buat ini:

$ echo -e 'foo\nbar\nbaz' | grep foo
foo

Dengan menggunakan proses substitusi Bash kita dapat mencapai hal yang sama melalui cara yang lebih bundaran:

$ grep foo <(echo -e 'foo\nbar\nbaz')
foo

Ganti grepuntuk echodan kita bisa lihat di bawah selimut:

$ echo foo <(echo -e 'foo\nbar\nbaz')
foo /dev/fd/63

The <(...)konstruk hanya diganti dengan nama file, dan grep berpikir itu adalah membuka file lama, itu hanya terjadi untuk diberi nama /dev/fd/63. Di sini, /dev/fdadalah direktori ajaib yang membuat pipa bernama untuk setiap deskriptor file yang dimiliki oleh file yang mengaksesnya.

Kita bisa membuatnya kurang ajaib dengan mkfifomembuat pipa bernama yang muncul lsdan semuanya, seperti file biasa:

$ mkfifo foofifo
$ ls -l foofifo 
prw-rw-r-- 1 indigo indigo 0 Apr 19 22:01 foofifo
$ grep foo foofifo

Di tempat lain:

$ echo -e 'foo\nbar\nbaz' > foofifo

dan lihat, grep akan menampilkan foo.

Saya pikir begitu Anda menyadari pipa dan file biasa dan file khusus seperti / dev / null semua hanya file, jelas menerapkan program nol lebih kompleks. Kernel harus menangani penulisan ke file dengan cara apa pun, tetapi dalam kasus / dev / null ia hanya dapat meletakkan tulisan di lantai, sedangkan dengan pipa ia harus benar-benar mentransfer byte ke program lain, yang kemudian harus sebenarnya membacanya.

Saya berpendapat bahwa ada masalah keamanan di luar paradigma dan kinerja historis. Membatasi jumlah program dengan kredensial eksekusi istimewa, tidak peduli sesederhana apa pun, merupakan prinsip mendasar keamanan sistem. Pengganti /dev/nulltentu diperlukan untuk memiliki hak istimewa seperti itu karena digunakan oleh layanan sistem. Kerangka kerja keamanan modern melakukan pekerjaan yang sangat baik untuk mencegah eksploitasi, tetapi tidak mudah. Perangkat berbasis kernel yang diakses sebagai file jauh lebih sulit untuk dieksploitasi.

Seperti orang lain sudah tunjukkan, /dev/null adalah program yang dibuat dari beberapa baris kode. Hanya saja baris kode ini adalah bagian dari kernel.

Untuk membuatnya lebih jelas, inilah implementasi Linux: perangkat karakter memanggil fungsi saat membaca atau menulis. Menulis ke /dev/nullpanggilan write_null , saat membaca panggilan read_null , terdaftar di sini .

Secara harfiah beberapa baris kode: fungsi-fungsi ini tidak melakukan apa pun. Anda akan membutuhkan lebih banyak baris kode daripada jari di tangan Anda hanya jika Anda menghitung fungsi selain membaca dan menulis.

Saya harap Anda juga mengetahui / dev / chargen / dev / zero dan lainnya seperti mereka termasuk / dev / null.

LINUX / UNIX memiliki beberapa di antaranya - yang tersedia sehingga orang dapat memanfaatkan dengan baik BAGIAN KODE TERTULIS.

Chargen dirancang untuk menghasilkan pola karakter yang spesifik dan berulang - cukup cepat dan akan mendorong batas perangkat serial dan itu akan membantu men-debug protokol serial yang ditulis dan gagal dalam beberapa tes atau lainnya.

Nol dirancang untuk mengisi file yang ada atau menghasilkan banyak nol

/ dev / null hanyalah alat lain dengan ide yang sama.

Semua alat ini di toolkit Anda berarti bahwa Anda memiliki kesempatan untuk membuat program yang ada melakukan sesuatu yang unik tanpa memperhatikan mereka (kebutuhan spesifik Anda) sebagai penggantian perangkat atau file

Mari kita siapkan kontes untuk melihat siapa yang dapat menghasilkan hasil paling menarik mengingat hanya beberapa perangkat karakter dalam versi LINUX Anda.