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

109

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'

Jonathan
sumber
9
Kembali pada 2012 itu memiliki lebih dari 5 juta baris hanya untuk driver. 1,9 juta baris untuk mendukung arsitektur prosesor yang berbeda. Info lebih lanjut h-online.com/open/features/…
steve
11
Ya saya telah mengkodekan sebuah kompiler, penganalisa leksikal, dan generator kode byte untuk suatu bahasa, dan itu turing lengkap plus rekursi dan tidak butuh 10.000 baris.
Jonathan
5
(lihat sekarang, itu sekitar 2.700 baris)
Jonathan
4
Anda harus mengunduh dan mengonfigurasi make menuconfiguntuk melihat seberapa banyak kode dapat diaktifkan / dinonaktifkan sebelum dibuat.
casey
6
@ JonathanLeaders: Saya telah menyelesaikan turing kompiler lengkap untuk LISP seperti bahasa dalam kurang dari 100 baris, dengan program uji rendering Mandelbrots. Selalu tergantung.
phresnel

Jawaban:

43

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.

Peter Cordes
sumber
4
Sekarang INI masuk akal bagi saya mengapa logis untuk memiliki semua kode bersama, menghemat waktu dengan biaya sumber daya komputer & ketergantungan yang berlebihan.
Jonathan
8
@ JonathanLeaders: yeah, ia menghindari bit-rot untuk driver dengan perawatan yang tidak terlalu aktif. Mungkin juga berguna untuk memiliki semua kode driver saat mempertimbangkan perubahan inti. Pencarian pada semua penelepon dari beberapa API internal dapat mengaktifkan driver yang menggunakannya dengan cara yang tidak Anda pikirkan, berpotensi memengaruhi perubahan yang Anda pikirkan.
Peter Cordes
1
@ JonathanLeaders datang pada xd, seolah-olah garis ekstra itu mengambil banyak ruang ekstra, dalam pengukuran modern menginstalnya pada pc.
Junaga
3
@Junaga: Anda sadar bahwa linux sangat portabel dan dapat diskalakan, bukan? Membuang 1MB memori kernel yang digunakan secara permanen pada sistem tertanam 32MB adalah masalah besar. Ukuran kode sumber tidak penting, tetapi ukuran biner yang dikompilasi masih penting. Memori kernel tidak dipetakan, jadi bahkan dengan ruang swap Anda tidak bisa mendapatkannya kembali.
Peter Cordes
1
@Rolf: Besar, tapi bukan spageti. Saat ini cukup baik dirancang tanpa ketergantungan dua arah bolak-balik antara kode inti dan driver. Driver dapat ditinggalkan tanpa merusak inti kernel. Ketika fungsi internal atau API di-refactored sehingga driver perlu menggunakannya secara berbeda, driver mungkin perlu diubah, tetapi itu normal untuk refactoring.
Peter Cordes
79

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).

drewbenn
sumber
3
menghitung modul tidak cukup, banyak yang mungkin dibangun oleh config
Alex
5
Saya pikir dari sini kita dapat menyimpulkan kernel Linux sangat besar karena mendukung semua jenis konfigurasi perangkat, bukan karena itu sangat rumit. Kita lihat di sini bahwa sangat sedikit dari garis 15m yang benar-benar digunakan. Meskipun, karena hampir semua hal, itu mungkin terlalu rumit, setidaknya kita bisa tidur di malam hari mengetahui itu masuk akal
Jonathan
2
@ JonathanLeaders: Ya - dan juga modul untuk perangkat aneh, ada modul untuk sistem file yang tidak jelas, protokol jaringan, dll ...
psmears
6
@ JonathanLeader Saya ingat ketika Linux mulai - bahkan mendapatkan installer untuk bekerja (jika bahkan memiliki installer!) Sangat menyebalkan - masih ada beberapa distro di mana Anda harus memilih driver mouse Anda secara manual. Membuat hal-hal seperti jaringan atau, tuhan melarang, X-window, bekerja, adalah ritual peralihan. Pada instalasi Red Hat pertama saya, saya harus menulis driver grafis saya sendiri, karena hanya ada tiga (!) Driver yang tersedia. Memiliki dasar-dasar kerja secara default adalah tanda kedewasaan - dan tentu saja, Anda dapat melakukan lebih banyak penyesuaian pada sistem tertanam, di mana hanya ada beberapa kombinasi HW.
Luaan
2
@ JonathanLeaders Seperti yang saya pikir Anda sudah sadari, LOC di sumbernya kurang lebih relevan. Jika Anda ingin tahu berapa banyak memori yang digunakan kernel, ada banyak cara langsung .
goldilocks
67

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.

pengguna3276552
sumber
19
Itu menarik. Yang lebih menarik adalah potensi titik lemah dalam kode, di mana programmer merasa jengkel:grep -Pir "\x66\x75\x63\x6b" /usr/src/linux/ | wc -l
jimmij
4
@jimmij '\ x73 \ x68 \ x69 \ x74' mungkin lebih umum sesuai dengan penelitian terobosan ini (jika sedikit tanggal) .
Nick T
3
Fakta acak: folder yang lebih dekat ke 600 000 LOC yang diperkirakan oleh OP adalah dokumentasi.
Davidmh
1
./documentationmemiliki lebih dari 500.000 baris kode? ....apa?
C_B
1
@drewbenn Saya lebih memahaminya sebagai "dokumentasi tidak kosong?"
Izkata
43

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.

Oli
sumber
2
Perhatian terutama untuk sistem tertanam. Seperti yang Anda tunjukkan, Anda memiliki 4.000 modul yang tidak digunakan pada sistem Anda sendiri. Dalam beberapa robotika kecil atau aplikasi luar angkasa, (BACA: bukan komputasi tujuan umum) ini akan menjadi limbah yang tidak dapat diterima.
Jonathan
2
@ JonathanLeaders Saya pikir Anda bisa menghapusnya dengan aman. Pada instalasi desktop, mereka ada jika Anda tiba-tiba memasukkan sesuatu di port usb, atau mengubah beberapa konfigurasi perangkat keras, dll.
Didier A.
1
Ya persis. Saya masih tetap terkejut dengan asumsi seperti "Anda bisa mencolokkan perangkat USB kapan saja karena itu kita memerlukan 15m baris kode" ditulis pada tingkat kernel , dan bukan pada tingkat distro, mengingat Linux digunakan di ponsel dan berbagai perangkat tertanam. Yah, saya kira distro tidak mengambil daftar itu sendiri. Saya hanya akan berpikir dukungan untuk pluggability harus bersifat additive dan tidak subtraktif, yaitu distro yang akan memilih 'ikut-ikutan' dengan menambahkan sumber paket, sebagai lawan dari konfigurasi ARM yang tertanam mengatakan bahwa kernel hanya satu persen dari ukuran saat ini
Jonathan
5
@ JonathanLeaders Anda tidak akan pernah menjalankan kernel yang dikonfigurasikan untuk desktop pada sistem embedded. Sistem tertanam kami memiliki 13 modul dan telah menghapus semua dukungan perangkat keras yang tidak kami butuhkan (bersama dengan banyak penyesuaian lainnya). Berhenti membandingkan Desktop dengan sistem yang disematkan. Linux berfungsi dengan baik karena mendukung semuanya dan dapat dikustomisasi untuk hanya memasukkan apa yang Anda pedulikan. Dan modul 4k itu sangat bagus untuk sistem desktop: ketika laptop terakhir saya mati, saya hanya memasukkan hard drive ke laptop yang jauh lebih baru dan semuanya berjalan dengan baik .
drewbenn
3
Jawaban yang baik atau berharga ini menderita dari nada marah dan agresif. -1.
TypeIA
19

Linux tinyconfig mengkompilasi jumlah baris sumber 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
Alex
sumber
@JonathanLeaders asyik mengerjakannya, senang ada yang suka
Alex
9

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.

rampok
sumber
1
"Pada beberapa arsitektur, batas kernel / userspace tidak lebih mahal daripada panggilan fungsi lainnya" - menarik! Arsitektur apa itu? Terlihat sangat sulit untuk dilakukan jika Anda tidak hanya meninggalkan perlindungan memori apa pun setidaknya.
Voo
1
Saya membaca semua video millcomputing.com dari Ivan Goddard (cpu mill / belt, sangat mirip VLIW). Klaim khusus ini adalah tema sentral, dan implikasinya tidak jelas sampai Anda tiba di video keamanan. Ini adalah arsitektur POC dalam simulasi, tetapi mungkin bukan satu-satunya arsitektur dengan properti ini.
Rob
1
Ah itu menjelaskannya. Dalam pengalaman saya (dan saya akan menjadi yang pertama untuk mengakui bahwa saya tidak mengikuti industri sedekat itu) ada banyak arsitektur simulasi dan hanya sedikit yang memenuhi klaim mereka begitu karet menyentuh jalan, yaitu mereka diletakkan pada perangkat keras nyata. Meskipun ide di balik itu mungkin menarik dalam hal apa pun - bukan pertama kalinya CPU tertentu telah disebutkan. Jika Anda pernah menemukan arsitektur yang ada yang memiliki properti ini, saya akan sangat tertarik.
Voo
1
BTW, ada lebih banyak sumber daya dalam debat yang Anda sebutkan: en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate
Jonathan