Mengapa kernel Linux 15+ juta baris kode? [Tutup]

Apa isi dari basis kode monolitik ini?

Saya memahami dukungan arsitektur prosesor, keamanan, dan virtualisasi, tetapi saya tidak dapat membayangkan bahwa lebih dari 600.000 baris.

Apa driver historis & alasan saat ini yang termasuk dalam basis kode kernel?

Apakah 15+ juta baris itu termasuk setiap driver tunggal untuk setiap perangkat keras yang pernah ada? Jika demikian, itu kemudian menimbulkan pertanyaan, mengapa driver tertanam dalam kernel dan bukan paket terpisah yang terdeteksi secara otomatis dan diinstal dari ID perangkat keras?

Apakah ukuran basis kode merupakan masalah untuk perangkat yang terbatas penyimpanan atau terbatas memori?

Tampaknya itu akan mengasapi ukuran kernel untuk perangkat ARM terbatas ruang jika semua itu tertanam. Apakah banyak garis yang diambil oleh preprosesor? Sebut saya gila, tapi saya tidak bisa membayangkan mesin yang membutuhkan banyak logika untuk menjalankan apa yang saya pahami adalah peran kernel.

Apakah ada bukti bahwa ukurannya akan menjadi masalah dalam 50+ tahun karena sifatnya yang tampaknya terus bertambah?

Termasuk driver berarti itu akan tumbuh ketika perangkat keras dibuat.

EDIT : Bagi mereka yang berpikir ini adalah sifat kernel, setelah beberapa penelitian saya menyadari itu tidak selalu. Sebuah kernel tidak diperlukan untuk menjadi ini besar, seperti Carnegie Mellon mikrokernel Mach terdaftar sebagai contoh 'biasanya di bawah 10.000 baris kode'

Driver dipertahankan di dalam kernel sehingga ketika perubahan kernel membutuhkan pencarian dan penggantian global (atau pencarian dan modifikasi tangan) untuk semua pengguna fungsi, itu dilakukan oleh orang yang melakukan perubahan. Memiliki driver Anda diperbarui oleh orang-orang yang membuat perubahan API adalah keuntungan yang sangat bagus, daripada harus melakukannya sendiri ketika tidak dikompilasi pada kernel yang lebih baru.

Alternatifnya (itulah yang terjadi untuk driver yang dipelihara di luar pohon), adalah bahwa patch harus disinkronkan kembali oleh pengelola untuk mengikuti perubahan.

Pencarian cepat menghasilkan perdebatan tentang pengembangan driver di-pohon vs di luar pohon .

Cara Linux dipelihara sebagian besar dengan menjaga segala sesuatu dalam repo arus utama. Membangun kernel stripped-down kecil didukung oleh opsi konfigurasi untuk mengontrol #ifdefs. Jadi Anda benar-benar dapat membangun kernel kecil yang dilucuti yang mengkompilasi hanya sebagian kecil dari kode di seluruh repo.

Penggunaan ekstensif Linux dalam sistem tertanam telah menyebabkan dukungan yang lebih baik untuk meninggalkan hal-hal dari Linux bertahun-tahun sebelumnya ketika pohon sumber kernel lebih kecil. Kernel super-minimal 4.0 mungkin lebih kecil dari kernel 2.4.0 super-minimal.

Menurut cloc run terhadap 3.13, Linux adalah sekitar 12 juta baris kode.

• 7 juta LOC dalam driver /
• 2 juta LOC di lengkungan /
• hanya 139 ribu LOC di kernel /

lsmod | wc pada laptop Debian saya menunjukkan 158 modul yang dimuat saat runtime, jadi memuat modul secara dinamis adalah cara yang baik untuk mendukung perangkat keras.

Sistem konfigurasi yang kuat (mis. make menuconfig) Digunakan untuk memilih kode mana yang akan dikompilasi (dan lebih ke titik Anda, kode mana yang tidak dikompilasi). Embedded system menentukan sendiri .configberkas hanya dengan dukungan hardware yang mereka pedulikan (termasuk hardware mendukung built-in ke kernel atau modul sebagai loadable).

Bagi siapa pun yang penasaran, inilah rincian linecount untuk mirror GitHub:

=============================================
    Item           Lines             %
=============================================
  ./usr                 845        0.0042
  ./init              5,739        0.0283
  ./samples           8,758        0.0432
  ./ipc               8,926        0.0440
  ./virt             10,701        0.0527
  ./block            37,845        0.1865
  ./security         74,844        0.3688
  ./crypto           90,327        0.4451
  ./scripts          91,474        0.4507
  ./lib             109,466        0.5394
  ./mm              110,035        0.5422
  ./firmware        129,084        0.6361
  ./tools           232,123        1.1438
  ./kernel          246,369        1.2140
  ./Documentation   569,944        2.8085
  ./include         715,349        3.5250
  ./sound           886,892        4.3703
  ./net             899,167        4.4307
  ./fs            1,179,220        5.8107
  ./arch          3,398,176       16.7449
  ./drivers      11,488,536       56.6110
=============================================

driversberkontribusi pada banyak jumlah lini.

Jawabannya sejauh ini tampaknya "ya ada banyak kode" dan tidak ada yang menangani pertanyaan dengan jawaban yang paling logis: 15M +? TERUS? Apa hubungan 15 juta baris kode sumber dengan harga ikan? Apa yang membuat ini sangat tak terbayangkan?

Linux jelas banyak. Jauh lebih dari apa pun ... Tetapi beberapa poin Anda menunjukkan Anda tidak menghargai apa yang terjadi ketika itu dibangun dan digunakan.

• Tidak semuanya dikompilasi. Sistem build Kernel memungkinkan Anda untuk dengan cepat menentukan konfigurasi yang memilih set kode sumber. Ada yang eksperimental, ada yang tua, ada yang tidak diperlukan untuk setiap sistem. Lihat /boot/config-$(uname -r)(di Ubuntu) di make menuconfigdan Anda akan melihat berapa banyak yang dikecualikan.

  Dan itu adalah distribusi desktop target-variabel. Konfigurasi untuk sistem tertanam hanya akan menarik hal-hal yang dibutuhkannya.

• Tidak semuanya built-in. Dalam konfigurasi saya, sebagian besar fitur Kernel dibangun sebagai modul:

  grep -c '=m' /boot/config-`uname -r`  # 4078
  grep -c '=y' /boot/config-`uname -r`  # 1944
  

  Agar lebih jelas, ini semua bisa menjadi built-in ... Sama seperti mereka dapat dicetak dan dibuat menjadi roti kertas raksasa. Itu tidak masuk akal kecuali jika Anda melakukan custom build untuk pekerjaan hardware diskrit (dalam hal ini, Anda sudah membatasi jumlah item-item ini).

• Modul dimuat secara dinamis. Bahkan ketika suatu sistem memiliki ribuan modul yang tersedia untuk itu, sistem akan memungkinkan Anda untuk memuat hal-hal yang Anda butuhkan. Bandingkan keluaran dari:

  find /lib/modules/$(uname -r)/ -iname '*.ko' | wc -l  # 4291
  lsmod | wc -l                                         # 99
  

  Hampir tidak ada yang dimuat.

• Microkernels bukan hal yang sama. Hanya 10 detik melihat gambar utama ke halaman Wikipedia yang Anda tautkan akan menyorotinya dirancang dengan cara yang sama sekali berbeda.

  

  Driver Linux diinternalisasi (sebagian besar sebagai modul yang dimuat secara dinamis), bukan ruang pengguna, dan sistem file juga internal. Mengapa itu lebih buruk daripada menggunakan driver eksternal? Mengapa mikro lebih baik untuk komputasi keperluan umum?

Komentar lagi menyoroti Anda tidak mendapatkannya. Jika Anda ingin menggunakan Linux pada perangkat keras diskrit (mis. Aerospace, TiVo, tablet, dll.) Anda mengkonfigurasinya untuk membangun hanya driver yang Anda butuhkan . Anda dapat melakukan hal yang sama pada desktop Anda make localmodconfig. Anda berakhir dengan build Kernel mungil untuk tujuan kecil dengan fleksibilitas nol.

Untuk distribusi seperti Ubuntu, paket Kernel 40MB tunggal dapat diterima. Tidak, gosok itu, sebenarnya lebih disukai daripada skenario pengarsipan dan pengunduhan besar-besaran yang menjaga 4000+ modul mengambang sebagai paket. Menggunakan lebih sedikit ruang disk untuk mereka, lebih mudah untuk mengemas pada waktu kompilasi, lebih mudah untuk menyimpan dan lebih baik bagi para penggunanya (yang memiliki sistem yang hanya berfungsi).

Masa depan juga tampaknya tidak menjadi masalah. Laju kecepatan CPU, kepadatan disk / harga, dan peningkatan bandwidth tampaknya jauh lebih cepat daripada pertumbuhan Kernel. Paket Kernel 200MB dalam 10 tahun tidak akan menjadi akhir jika dunia.

Ini juga bukan jalan satu arah. Kode akan dikeluarkan jika tidak dipelihara.

tinyconfig bubble graph svg (biola)

shell script untuk membuat json dari kernel build, gunakan dengan http://bl.ocks.org/mbostock/4063269

Sunting : ternyata unifdefmemiliki beberapa batasan ( -Idiabaikan dan -includetidak didukung, yang terakhir digunakan untuk menyertakan tajuk konfigurasi yang dibuat) pada saat ini menggunakan cattidak banyak berubah:

274692 total # (was 274686)

skrip dan prosedur diperbarui.

Selain driver, arch dll ada banyak kode kondisional yang dikompilasi atau tidak tergantung pada konfigurasi yang dipilih, kode tidak harus dalam modul yang dimuat dinamis tetapi dibangun di inti.

Jadi, unduh sumber linux-4.1.6 , pilih tinyconfig , itu tidak mengaktifkan modul dan saya benar-benar tidak tahu apa itu memungkinkan atau apa yang bisa dilakukan pengguna saat runtime, konfigurasi kernel:

# tinyconfig      - Configure the tiniest possible kernel
make tinyconfig

membangun kernel

time make V=1 # (should be fast)
#1049168 ./vmlinux (I'm using x86-32 on other arch the size may be different)

proses pembuatan kernel meninggalkan file tersembunyi yang disebut *.cmddengan baris perintah yang digunakan juga untuk membangun .ofile, untuk memproses file-file itu dan mengekstrak target dan dependensi salin di script.shbawah ini dan menggunakannya dengan find :

find -name "*.cmd" -exec sh script.sh "{}" \;

ini membuat salinan untuk setiap ketergantungan .onama target.o.c

.c code

find -name "*.o.c" | grep -v "/scripts/" | xargs wc -l | sort -n
...
   8285 ./kernel/sched/fair.o.c
   8381 ./kernel/sched/core.o.c
   9083 ./kernel/events/core.o.c
 274692 total

.h header (disanitasi)

make headers_install INSTALL_HDR_PATH=/tmp/test-hdr
find /tmp/test-hdr/ -name "*.h" | xargs wc -l
...
  1401 /tmp/test-hdr/include/linux/ethtool.h
  2195 /tmp/test-hdr/include/linux/videodev2.h
  4588 /tmp/test-hdr/include/linux/nl80211.h
112445 total

Pengorbanan kernel monolitik diperdebatkan antara Tananbaum dan Torvalds di depan umum sejak awal. Jika Anda tidak perlu menyeberang ke ruang pengguna untuk semuanya, maka antarmuka ke kernel bisa lebih sederhana. Jika kernel bersifat monolitik, maka dapat lebih dioptimalkan (dan lebih berantakan!) Secara internal.

Kami telah memiliki modul sebagai kompromi untuk beberapa waktu. Dan ini berlanjut dengan hal-hal seperti DPDK (memindahkan lebih banyak fungsi jaringan dari kernel). Semakin banyak inti yang ditambahkan, semakin penting untuk menghindari penguncian; jadi lebih banyak hal akan pindah ke userspace dan kernel akan menyusut.

Perhatikan bahwa kernel monolitik bukan satu-satunya solusi. Pada beberapa arsitektur, batas kernel / userspace tidak lebih mahal daripada panggilan fungsi lainnya, membuat microkernels menarik.