ทำไมเคอร์เนล Linux มีโค้ดมากกว่า 15 ล้านเส้น? [ปิด]

อะไรคือเนื้อหาของฐานรหัสเสาหินนี้?

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

อะไรคือเหตุผลในอดีตและปัจจุบันไดรเวอร์จะรวมอยู่ในฐานรหัสเคอร์เนล?

15 ล้านเส้นเหล่านั้นรวมถึงไดรเวอร์ทุกตัวสำหรับฮาร์ดแวร์ทุกชิ้นหรือไม่? ถ้าเป็นเช่นนั้นก็จะเกิดคำถามทำไมจึงมีไดรเวอร์ฝังอยู่ในเคอร์เนลและไม่แยกแพคเกจที่ตรวจพบโดยอัตโนมัติและติดตั้งจาก ID ฮาร์ดแวร์

ขนาดของรหัสฐานเป็นปัญหาสำหรับอุปกรณ์ที่จัดเก็บข้อมูลหรือ จำกัด หน่วยความจำหรือไม่?

ดูเหมือนว่ามันจะขยายขนาดเคอร์เนลสำหรับอุปกรณ์ ARM ที่ จำกัด พื้นที่หากสิ่งที่ฝังอยู่ มีบรรทัดจำนวนมากที่ถูกเลือกโดยตัวประมวลผลล่วงหน้าหรือไม่? โทรหาฉันบ้า แต่ฉันนึกภาพไม่ออกว่าเครื่องจักรต้องการตรรกะมากมายในการทำงานสิ่งที่ฉันเข้าใจคือบทบาทของเคอร์เนล

มีหลักฐานว่าขนาดจะเป็นปัญหาใน 50 ปีขึ้นไปเนื่องจากมันดูเหมือนธรรมชาติที่เคยเติบโต?

การรวมไดรเวอร์หมายความว่ามันจะเติบโตขึ้นเมื่อฮาร์ดแวร์ทำขึ้น

แก้ไข : สำหรับผู้ที่คิดว่านี่คือลักษณะของเมล็ดหลังจากการวิจัยบางอย่างฉันรู้ว่ามันไม่ได้เป็นเสมอ เคอร์เนลไม่จำเป็นต้องมีขนาดใหญ่เท่านี้เนื่องจากmicrokernel Mach ของ Carnegie Mellon ถูกระบุว่าเป็นตัวอย่าง 'มักจะต่ำกว่า 10,000 บรรทัดของโค้ด'

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

ทางเลือกอื่น (ซึ่งเป็นสิ่งที่เกิดขึ้นสำหรับไดรเวอร์ที่เก็บรักษาไว้นอกโครงสร้าง) คือแพตช์จะต้องได้รับการซิงค์อีกครั้งโดยผู้ดูแลเพื่อให้ทันกับการเปลี่ยนแปลงใด ๆ

การค้นหาอย่างรวดเร็วทำให้เกิดการโต้แย้งเรื่องการพัฒนาไดร์เวอร์แบบ in-tree และ out-of-tree

วิธีที่ Linux ได้รับการดูแลนั้นส่วนใหญ่จะเก็บทุกอย่างไว้ใน repo mainline การสร้างเมล็ดขนาดเล็กที่ถูกปล้นได้รับการสนับสนุนโดยตัวเลือกการกำหนดค่าเพื่อควบคุม#ifdefs ดังนั้นคุณสามารถสร้างเมล็ดที่ถูกปล้นเล็ก ๆ ที่รวบรวมได้เพียงส่วนเล็ก ๆ ของรหัสใน repo ทั้งหมด

การใช้งาน Linux อย่างกว้างขวางในระบบสมองกลฝังตัวได้นำไปสู่การสนับสนุนที่ดีกว่าในการละทิ้งสิ่งต่าง ๆ ได้ดีกว่า Linux เมื่อหลายปีก่อนเมื่อต้นกำเนิดเคอร์เนลมีขนาดเล็กลง เคอร์เนลขั้นต่ำสุด 4.0 อาจมีขนาดเล็กกว่าเคอร์เนล 2.4.0 ขั้นต่ำสุด

ตามclocทำงานกับ 3.13, Linux มีโค้ดประมาณ 12 ล้านบรรทัด

• 7 ล้าน LOC ในไดรเวอร์ /
• 2 ล้าน LOC ในส่วนโค้ง /
• เพียง 139,000 LOC ในเคอร์เนล /

lsmod | wc บนแล็ปท็อป Debian ของฉันแสดงโมดูลที่โหลด 158 ที่รันไทม์ดังนั้นการโหลดโมดูลแบบไดนามิกจึงเป็นวิธีที่ใช้งานได้ดีในการรองรับฮาร์ดแวร์

ระบบการกำหนดค่าที่แข็งแกร่ง (เช่นmake menuconfig) จะใช้ในการเลือกรหัสที่จะรวบรวม (และอื่น ๆ ไปยังจุดของคุณซึ่งรหัสที่จะไม่รวบรวม) ระบบสมองกลฝังตัวกำหนด.configไฟล์ของตัวเองด้วยการสนับสนุนฮาร์ดแวร์ที่พวกเขาสนใจ (รวมถึงการสนับสนุนฮาร์ดแวร์ในตัวให้กับเคอร์เนลหรือโมดูลที่โหลดได้)

สำหรับทุกคนที่อยากรู้อยากเห็นนี่คือรายละเอียด linecount สำหรับกระจก 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
=============================================

driversก่อให้เกิดจำนวนมากของ linecount

คำตอบที่ดูเหมือนจะเป็น "ใช่มีรหัสจำนวนมาก" และไม่มีใครแก้ปัญหาด้วยคำตอบที่มีเหตุผลที่สุด: 15M +? แล้วอะไรล่ะ? อะไรสาย 15M ของรหัสที่มาจะทำอย่างไรกับราคาของปลา? อะไรทำให้สิ่งนี้เป็นไปไม่ได้

Linux มีจำนวนมากอย่างชัดเจน มีอะไรมากกว่านั้นอีกมากมาย ... แต่บางจุดของคุณแสดงว่าคุณไม่เคารพสิ่งที่เกิดขึ้นเมื่อมันถูกสร้างและใช้งาน

• ไม่ใช่ทุกอย่างที่ถูกรวบรวม ระบบสร้างเคอร์เนลช่วยให้คุณกำหนดค่าได้อย่างรวดเร็วซึ่งเลือกชุดของซอร์สโค้ด บางตัวเป็นรุ่นทดลองบางรุ่นเก่าบางรุ่นไม่จำเป็นสำหรับทุกระบบ ดูที่/boot/config-$(uname -r)(บน Ubuntu) make menuconfigและคุณจะเห็นว่ามีการแยกออกเป็นจำนวนเท่าใด

  และนั่นคือการกระจายเดสก์ท็อปเป้าหมายตัวแปร การกำหนดค่าสำหรับระบบฝังตัวจะดึงสิ่งที่ต้องการเท่านั้น

• ไม่ใช่ทุกอย่างในตัว ในการกำหนดค่าของฉันคุณสมบัติเคอร์เนลส่วนใหญ่ถูกสร้างเป็นโมดูล:

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

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

• โมดูลถูกโหลดแบบไดนามิก แม้ว่าระบบจะมีโมดูลหลายพันโมดูล แต่ระบบจะอนุญาตให้คุณโหลดสิ่งที่คุณต้องการ เปรียบเทียบผลลัพธ์ของ:

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

  แทบไม่มีอะไรโหลด

• Microkernels นั้นไม่เหมือนกัน เพียงแค่ 10 วินาทีในการดูภาพที่นำไปสู่หน้า Wikipedia ที่คุณเชื่อมโยงไว้จะเป็นการเน้นว่าภาพเหล่านั้นได้รับการออกแบบในลักษณะที่แตกต่างไปจากเดิมอย่างสิ้นเชิง

  

  ไดรเวอร์ Linux ถูกทำให้เป็นแบบภายใน (ส่วนใหญ่เป็นโมดูลที่โหลดแบบไดนามิก) ไม่ใช่ userspace และระบบไฟล์นั้นเป็นแบบเดียวกัน ทำไมถึงแย่กว่าการใช้ไดรเวอร์ภายนอก เหตุใดไมโครจึงดีกว่าสำหรับการคำนวณทั่วไป

ความคิดเห็นอีกครั้งเน้นว่าคุณไม่ได้รับมัน หากคุณต้องการที่จะปรับใช้ลินุกซ์บนฮาร์ดแวร์ที่ไม่ต่อเนื่อง (เช่นการบินและอวกาศทีโว, แท็บเล็ต ฯลฯ ) คุณกำหนดค่าเพื่อสร้างเพียงไดรเวอร์ที่คุณต้องการ make localmodconfigคุณสามารถทำเช่นเดียวกันบนเดสก์ทอปของคุณด้วย คุณจบลงด้วยการสร้างเคอร์เนลขนาดเล็กที่มีความยืดหยุ่นเป็นศูนย์

สำหรับดิสทริบิวชันเช่น Ubuntu แพคเกจเคอร์เนล 40MB เดียวนั้นใช้ได้ ไม่ขัดว่าจริง ๆ แล้วเป็นที่นิยมมากกว่าในสถานการณ์การเก็บถาวรและการดาวน์โหลดขนาดใหญ่ที่เก็บโมดูลลอยได้ 4000+ ชุดเป็นแพ็คเกจ มันใช้พื้นที่ดิสก์น้อยลงสำหรับพวกเขาง่ายต่อการทำแพ็กเกจในเวลารวบรวมง่ายต่อการจัดเก็บและดีกว่าสำหรับผู้ใช้ของพวกเขา (ผู้ที่มีระบบที่ใช้งานได้)

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

มันไม่ใช่ถนนเดินรถทางเดียว รหัสจะถูกเตะออกหากไม่ได้รับการบำรุงรักษา

กราฟฟองเล็ก ๆ ตั้งค่า svg (ซอ)

เชลล์สคริปต์เพื่อสร้าง json จากเคอร์เนลบิลด์ใช้กับhttp://bl.ocks.org/mbostock/4063269

แก้ไข : เปิดออกunifdefมีข้อ จำกัด บางอย่าง ( -Iถูกเพิกเฉยและ-includeไม่ได้รับการสนับสนุนหลังถูกใช้เพื่อรวมส่วนหัวการกำหนดค่าที่สร้างขึ้น) ณ จุดนี้การใช้catไม่เปลี่ยนแปลงมาก:

274692 total # (was 274686)

อัปเดตสคริปต์และขั้นตอนแล้ว

ข้างไดรเวอร์, arch และอื่น ๆ มีโค้ดที่มีเงื่อนไขมากมายที่รวบรวมหรือไม่ขึ้นอยู่กับการกำหนดค่าที่เลือกรหัสไม่จำเป็นต้องอยู่ในโมดูลที่โหลดแบบไดนามิก แต่สร้างขึ้นในแกนกลาง

ดังนั้นแหล่งดาวน์โหลดlinux-4.1.6 , เลือกTinyconfig , มันไม่เปิดใช้งานโมดูลและฉันไม่รู้ว่ามันเปิดใช้งานอะไรหรือผู้ใช้สามารถทำอะไรกับมันได้ตอนรันไทม์, อย่างไรก็ตาม, ตั้งค่าเคอร์เนล:

# tinyconfig      - Configure the tiniest possible kernel
make tinyconfig

สร้างเคอร์เนล

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

กระบวนการสร้างเคอร์เนลปล่อยให้ไฟล์ที่ซ่อนเรียก*.cmdด้วยบรรทัดคำสั่งที่ใช้ในการสร้าง.oไฟล์เพื่อประมวลผลไฟล์เหล่านั้นและแยกเป้าหมายและการอ้างอิงคัดลอกscript.shด้านล่างและใช้กับการค้นหา :

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

นี้สร้างสำเนาสำหรับการพึ่งพาของเป้าหมายแต่ละ.oชื่อ.o.c

รหัส. c

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 ส่วนหัว (ถูกสุขอนามัย)

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

การแลกเปลี่ยนเมล็ดของเสาหินถกเถียงกันระหว่าง Tananbaum และ Torvalds ในที่สาธารณะตั้งแต่ต้น หากคุณไม่จำเป็นต้องข้ามไปยัง userspace สำหรับทุกสิ่งดังนั้นอินเตอร์เฟสไปยังเคอร์เนลอาจง่ายกว่า หากเคอร์เนลเป็นเสาหินก็สามารถเพิ่มประสิทธิภาพ (และยุ่งมากขึ้น!) ภายใน

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

โปรดทราบว่าเคอร์เนลเสาหินไม่ใช่ทางออกเดียว ในบางสถาปัตยกรรมขอบเขตเคอร์เนล / ผู้ใช้พื้นที่ไม่แพงกว่าการเรียกใช้ฟังก์ชั่นอื่น ๆ ทำให้ microkernels น่าสนใจ