Tại sao nhân Linux có hơn 15 triệu dòng mã? [đóng cửa]

Nội dung của cơ sở mã nguyên khối này là gì?

Tôi hiểu hỗ trợ kiến ​​trúc bộ xử lý, bảo mật và ảo hóa, nhưng tôi không thể tưởng tượng rằng có hơn 600.000 dòng hoặc hơn thế.

Các trình điều khiển lý do lịch sử và hiện tại được bao gồm trong cơ sở mã hạt nhân là gì?

15+ triệu dòng đó có bao gồm mọi trình điều khiển duy nhất cho mọi phần cứng bao giờ không? Nếu vậy, điều đó đặt ra câu hỏi, tại sao các trình điều khiển được nhúng trong kernel và không tách rời các gói được tự động phát hiện và cài đặt từ ID phần cứng?

Có phải kích thước của cơ sở mã là một vấn đề đối với các thiết bị bị hạn chế lưu trữ hoặc bị hạn chế bộ nhớ?

Có vẻ như nó sẽ làm tăng kích thước hạt nhân cho các thiết bị ARM bị giới hạn không gian nếu tất cả những thứ đó được nhúng. Có rất nhiều dòng bị loại bỏ bởi bộ tiền xử lý? Gọi tôi là điên, nhưng tôi không thể tưởng tượng một cỗ máy cần nhiều logic đó để chạy những gì tôi hiểu là vai trò của hạt nhân.

Có bằng chứng nào cho thấy kích thước sẽ là một vấn đề trong hơn 50 năm do bản chất dường như ngày càng phát triển của nó?

Bao gồm các trình điều khiển có nghĩa là nó sẽ phát triển khi phần cứng được thực hiện.

EDIT : Đối với những người nghĩ rằng đây là bản chất của hạt nhân, sau một số nghiên cứu tôi nhận ra nó không phải lúc nào cũng vậy. Một hạt nhân không bắt buộc phải lớn như vậy, vì microkernel Mach của Carnegie Mellon đã được liệt kê như một ví dụ 'thường dưới 10.000 dòng mã'

Trình điều khiển được duy trì trong kernel, do đó, khi thay đổi kernel yêu cầu tìm kiếm và thay thế toàn cầu (hoặc tìm kiếm và sửa đổi bằng tay) cho tất cả người dùng chức năng, người đó sẽ thực hiện thay đổi. Có trình điều khiển của bạn được cập nhật bởi những người thực hiện thay đổi API là một lợi thế rất tốt, thay vì phải tự làm điều đó khi nó không biên dịch trên kernel gần đây hơn.

Thay thế (đó là những gì xảy ra đối với các trình điều khiển được duy trì ngoài cây), là bản vá phải được đồng bộ hóa lại bởi các nhà bảo trì của nó để theo kịp bất kỳ thay đổi nào.

Một cuộc tìm kiếm nhanh đã tạo ra một cuộc tranh luận về sự phát triển trình điều khiển trong cây và ngoài cây .

Cách Linux được duy trì chủ yếu bằng cách giữ mọi thứ trong repo dòng chính. Việc xây dựng các hạt nhân nhỏ xuống được hỗ trợ bởi các tùy chọn cấu hình để điều khiển #ifdefs. Vì vậy, bạn hoàn toàn có thể xây dựng các hạt nhân tước nhỏ, chỉ biên dịch một phần nhỏ của mã trong toàn bộ repo.

Việc sử dụng rộng rãi Linux trong các hệ thống nhúng đã dẫn đến sự hỗ trợ tốt hơn cho việc loại bỏ mọi thứ so với Linux trước đó khi cây nguồn nhỏ hơn. Một hạt nhân 4.0 siêu tối thiểu có lẽ nhỏ hơn một hạt nhân 2.4.0 siêu tối thiểu.

Theo cloc chạy với 3.13, Linux có khoảng 12 triệu dòng mã.

• 7 triệu LỘC trong trình điều khiển /
• 2 triệu LỘC trong vòm /
• chỉ 139 nghìn LỘC trong kernel /

lsmod | wc trên máy tính xách tay Debian của tôi hiển thị 158 mô-đun được tải khi chạy, do đó, tải mô-đun động là cách hỗ trợ phần cứng được sử dụng tốt.

Hệ thống cấu hình mạnh mẽ (ví dụ make menuconfig) được sử dụng để chọn mã nào sẽ biên dịch (và hơn thế nữa theo điểm của bạn, mã nào không biên dịch). Các hệ thống nhúng xác định .configtệp riêng của chúng chỉ với sự hỗ trợ phần cứng mà chúng quan tâm (bao gồm hỗ trợ phần cứng tích hợp vào kernel hoặc dưới dạng các mô-đun có thể tải).

Đối với bất kỳ ai tò mò, đây là bảng phân tích linecount cho gương 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đóng góp cho rất nhiều linecount.

Các câu trả lời cho đến nay dường như là "có rất nhiều mã" và không ai giải quyết câu hỏi bằng câu trả lời hợp lý nhất: 15M +? VẬY THÌ SAO? 15M dòng mã nguồn có liên quan gì đến giá cá? Điều gì làm cho điều này rất không thể tưởng tượng?

Linux rõ ràng làm rất nhiều. Nhiều hơn bất cứ điều gì khác ... Nhưng một số điểm của bạn cho thấy bạn không tôn trọng những gì đang xảy ra khi nó được xây dựng và sử dụng.

• Không phải tất cả mọi thứ được biên soạn. Hệ thống xây dựng Kernel cho phép bạn nhanh chóng xác định các cấu hình chọn bộ mã nguồn. Một số là thử nghiệm, một số là cũ, một số không cần thiết cho mọi hệ thống. Nhìn vào /boot/config-$(uname -r)(trên Ubuntu) make menuconfigvà bạn sẽ thấy số lượng được loại trừ.

  Và đó là một phân phối máy tính để bàn biến mục tiêu. Cấu hình cho một hệ thống nhúng sẽ chỉ kéo theo những thứ nó cần.

• Không phải mọi thứ đều được tích hợp sẵn. Trong cấu hình của tôi, hầu hết các tính năng Kernel được xây dựng dưới dạng các mô-đun:

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

  Để rõ ràng, tất cả những thứ này có thể được tích hợp ... Giống như chúng có thể được in ra và làm thành một chiếc bánh sandwich giấy khổng lồ. Nó sẽ không có ý nghĩa trừ khi bạn đang thực hiện một bản dựng tùy chỉnh cho một công việc phần cứng riêng biệt (trong trường hợp đó, bạn đã giới hạn số lượng các mục này rồi).

• Các mô-đun được tải động. Ngay cả khi một hệ thống có sẵn hàng ngàn mô-đun, hệ thống sẽ cho phép bạn tải chỉ những thứ bạn cần. So sánh kết quả đầu ra của:

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

  Hầu như không có gì được tải.

• Microkernels không giống nhau. Chỉ cần 10 giây nhìn vào hình ảnh hàng đầu đến trang Wikipedia mà bạn liên kết sẽ làm nổi bật chúng được thiết kế theo một cách hoàn toàn khác.

  

  Trình điều khiển Linux được nội bộ hóa (chủ yếu là các mô-đun được tải động), không phải không gian người dùng và các hệ thống tệp tương tự như bên trong. Tại sao điều đó tồi tệ hơn việc sử dụng trình điều khiển bên ngoài? Tại sao vi mô tốt hơn cho tính toán mục đích chung?

Các ý kiến ​​một lần nữa nhấn mạnh bạn không nhận được nó. Nếu bạn muốn triển khai Linux trên phần cứng riêng biệt (ví dụ: hàng không vũ trụ, TiVo, máy tính bảng, v.v.), bạn định cấu hình nó để chỉ xây dựng các trình điều khiển bạn cần . Bạn có thể làm tương tự trên máy tính để bàn của bạn với make localmodconfig. Bạn kết thúc với một bản dựng Kernel cho mục đích nhỏ bé với độ linh hoạt bằng không.

Đối với các bản phân phối như Ubuntu, một gói Kernel 40 MB duy nhất được chấp nhận. Không, chà rằng, nó thực sự thích hợp hơn với kịch bản lưu trữ và tải xuống khổng lồ giữ hơn 4000 mô-đun nổi như các gói. Nó sử dụng ít không gian đĩa hơn cho họ, dễ dàng đóng gói hơn trong thời gian biên dịch, dễ lưu trữ hơn và tốt hơn cho người dùng của họ (những người có một hệ thống chỉ hoạt động).

Tương lai dường như cũng không phải là một vấn đề. Tốc độ của CPU, mật độ ổ đĩa / giá cả và cải thiện băng thông dường như nhanh hơn nhiều so với sự tăng trưởng của Kernel. Gói hạt nhân 200 MB trong 10 năm sẽ không phải là kết thúc nếu thế giới.

Đó cũng không phải là con đường một chiều. Mã sẽ bị loại nếu nó không được duy trì.

biểu đồ bong bóng tinyconfig svg (fiddle)

shell script để tạo json từ bản dựng kernel, sử dụng với http://bl.ocks.org/mbostock/4063269

Chỉnh sửa : hóa ra unifdefcó một số giới hạn ( -Ibị bỏ qua và -includekhông được hỗ trợ, cái sau được sử dụng để bao gồm tiêu đề cấu hình được tạo) tại thời điểm này bằng cách sử dụng catkhông thay đổi nhiều:

274692 total # (was 274686)

kịch bản và thủ tục cập nhật.

Bên cạnh trình điều khiển, vòm, vv có rất nhiều mã có điều kiện được biên dịch hay không tùy thuộc vào cấu hình đã chọn, mã không nhất thiết phải trong các mô-đun được tải động mà được xây dựng trong lõi.

Vì vậy, đã tải xuống các nguồn linux-4.1.6 , chọn tinyconfig , nó không kích hoạt các mô-đun và tôi thực sự không biết nó kích hoạt cái gì hoặc người dùng có thể làm gì với nó khi chạy, dù sao, hãy cấu hình kernel:

# tinyconfig      - Configure the tiniest possible kernel
make tinyconfig

xây dựng hạt nhân

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

quá trình xây dựng kernel để lại các tệp ẩn được gọi *.cmdbằng dòng lệnh cũng được sử dụng để xây dựng .ocác tệp, để xử lý các tệp đó và trích xuất mục tiêu và phụ thuộc sao chép script.shbên dưới và sử dụng nó với find :

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

điều này tạo ra một bản sao cho mỗi phụ thuộc của mục tiêu .ođược đặt tên.o.c

mã .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 tiêu đề (khử trùng)

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

Sự đánh đổi của các hạt nhân nguyên khối đã được tranh luận giữa Tananbaum và Torvalds ngay từ đầu. Nếu bạn không cần phải xâm nhập vào không gian người dùng cho mọi thứ, thì giao diện với kernel có thể đơn giản hơn. Nếu kernel là nguyên khối, thì nó có thể được tối ưu hóa hơn (và lộn xộn hơn!) Trong nội bộ.

Chúng tôi đã có các mô-đun như một sự thỏa hiệp trong một thời gian khá dài. Và nó đang tiếp tục với những thứ như DPDK (chuyển nhiều chức năng mạng ra khỏi kernel). Càng nhiều lõi được thêm vào, điều quan trọng hơn là tránh khóa; vì vậy nhiều thứ sẽ di chuyển vào không gian người dùng và kernel sẽ co lại.

Lưu ý rằng hạt nhân nguyên khối không phải là giải pháp duy nhất. Trên một số kiến ​​trúc, ranh giới kernel / không gian người dùng không đắt hơn bất kỳ lệnh gọi chức năng nào khác, làm cho microkernels hấp dẫn.