왜 리눅스 커널이 1,500 만 줄의 코드입니까? [닫은]

이 모 놀리 식 코드베이스의 내용은 무엇입니까?

프로세서 아키텍처 지원, 보안 및 가상화를 이해하고 있지만 60 만 라인 이상인 것으로는 상상할 수 없습니다.

드라이버가 커널 코드베이스에 포함 된 과거 및 현재 이유는 무엇입니까?

1,500 만 개 이상의 라인에 모든 하드웨어에 대한 모든 단일 드라이버가 포함되어 있습니까? 그렇다면 드라이버가 커널에 내장되어 있고 자동 감지되어 설치된 하드웨어 패키지를 하드웨어 ID와 분리하지 않는 이유는 무엇입니까?

스토리지 기반 또는 메모리 제한 장치의 경우 코드베이스의 크기가 문제입니까?

공간이 제한된 ARM 장치가 모두 포함 된 경우 커널 크기를 크게 늘리는 것 같습니다. 전처리기에 의해 많은 라인이 제거됩니까? 나를 미치게 부르지 만, 내가 이해하는 것을 실행하기 위해 많은 논리가 필요한 기계가 커널의 역할이라고 상상할 수는 없습니다.

점점 커지고있는 자연으로 인해 50 년 이상 크기가 문제가 될 것이라는 증거가 있습니까?

드라이버를 포함한다는 것은 하드웨어가 만들어 짐에 따라 커질 것이라는 의미입니다.

편집 : 이것이 커널의 본질이라고 생각하는 사람들을 위해, 일부 연구 후 나는 그것이 항상 그렇지는 않다는 것을 깨달았습니다. Carnegie Mellon의 마이크로 커널 Mach가 '보통 10,000 줄 미만의 코드'의 예로 나열 되었기 때문에 커널 이이 크기 일 필요는 없습니다.

드라이버는 커널 내부에 유지되므로 커널 변경이 함수의 모든 사용자에 대해 전역 검색 및 교체 (또는 검색 및 수정)가 필요한 경우 변경하는 사람이 수행합니다. 사람들이 API를 변경하여 드라이버를 업데이트하는 것은 최신 커널에서 컴파일하지 않을 때 직접 수행하는 대신 매우 좋은 이점입니다.

대안은 (트리 외부에서 유지 관리되는 드라이버의 경우) 패치가 변경 사항에 따라 유지 관리 담당자가 다시 동기화해야한다는 것입니다.

빠른 검색으로 인트 리 및 아웃 트리 드라이버 개발에 대한 논쟁이 제기되었습니다 .

리눅스가 유지되는 방식은 대부분 메인 라인 저장소에 모든 것을 유지하는 것입니다. 작은 스트립 다운 커널 빌드는 #ifdefs 를 제어하기위한 구성 옵션에 의해 지원됩니다 . 따라서 전체 리포지토리에서 코드의 작은 부분 만 컴파일하는 작은 스트립 다운 커널을 절대적으로 빌드 할 수 있습니다.

임베디드 시스템에서 리눅스를 광범위하게 사용 함으로써 커널 소스 트리가 더 작 았던 리눅스보다 몇 년 전보다 더 많은 것들을 지원할 수 있게 되었습니다. 최고-최소 4.0 커널은 아마도 최고-최소 2.4.0 커널보다 작을 것입니다.

3.13에 대한 cloc run에 따르면 Linux는 약 1200 만 줄의 코드입니다.

• 드라이버 7 백만 LOC /
• 아치에서 2 백만 LOC /
• 커널에서 139 천 LOC 만

lsmod | wc 내 데비안 랩톱에는 런타임에로드 된 158 개의 모듈이 표시되므로 동적으로 모듈을로드하는 것이 하드웨어를 지원하는 잘 사용되는 방법입니다.

강력한 구성 시스템 (예 :) make menuconfig은 컴파일 할 코드를 선택하는 데 사용됩니다 (및 컴파일 하지 않을 코드 ). 임베디드 시스템은 .config관심 하드웨어 지원 (커널에 내장 된 하드웨어 지원 또는로드 가능한 모듈 포함)으로 자체 파일을 정의합니다 .

궁금한 점이 있다면 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많은 라인 수 에 기여합니다 .

지금까지의 대답은 "그렇습니다. 많은 코드가 있습니다"라고 보이며 아무도 가장 논리적 인 대답으로 15M +? 그래서 무엇? 소스 코드 의 15M 라인 은 생선 가격과 어떤 관련이 있습니까? 상상할 수없는 이유는 무엇입니까?

리눅스는 분명히 많은 일을합니다. 다른 것보다 훨씬 더 ... 그러나 당신의 요점 중 일부는 그것이 만들어지고 사용될 때 일어나는 일을 존중하지 않는다는 것을 보여줍니다.

• 모든 것이 컴파일되는 것은 아닙니다. 커널 빌드 시스템을 사용하면 소스 코드 세트를 선택하는 구성을 신속하게 정의 할 수 있습니다. 일부는 실험적이고 일부는 오래되었으며 일부는 모든 시스템에 필요하지 않습니다. 봐 /boot/config-$(uname -r)에서 (우분투) 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
  

  거의 아무것도로드되지 않습니다.

• 마이크로 커널은 같은 것이 아닙니다. 받는 최고의 이미지를보고 그냥 십초 위키 백과 페이지 는 링크는 그들이 완전히 다른 방식으로 설계되어 강조한다.

  

  Linux 드라이버는 사용자 공간이 아닌 내부적으로 (대부분 동적으로로드 된 모듈로) 파일 시스템은 내부적으로 비슷합니다. 왜 외부 드라이버를 사용하는 것보다 나쁩니 까? 범용 컴퓨팅에 마이크로가 더 나은 이유는 무엇입니까?

댓글이 다시 표시되지 않음을 강조 표시합니다. 개별 하드웨어 (예 : 항공 우주, TiVo, 태블릿 등)에 Linux를 배포 하려면 필요한 드라이버 만 빌드하도록 구성하십시오 . 로 데스크톱에서도 동일한 작업을 수행 할 수 있습니다 make localmodconfig. 유연성이 전혀없는 작은 목적의 커널 빌드로 끝납니다.

Ubuntu와 같은 배포판의 경우 단일 40MB 커널 패키지가 허용됩니다. 아니요, 4000 개 이상의 부동 모듈을 패키지로 유지하는 대규모 보관 및 다운로드 시나리오 보다 실제로 선호 됩니다. 디스크 공간을 적게 사용하고 컴파일 타임에 패키지하기가 쉽고 저장하기 쉬우 며 사용자 (작동하는 시스템을 가진 사용자)에게 더 좋습니다.

미래도 문제가되지 않는 것 같습니다. CPU 속도, 디스크 밀도 / 가격 및 대역폭 개선 속도는 커널의 성장보다 훨씬 빠릅니다. 세계에서 10 년 안에 200MB 커널 패키지는 끝나지 않을 것입니다.

또한 일방 통행 거리가 아닙니다. 코드가 유지되지 않으면 코드가 쫓겨납니다.

tinyconfig 버블 그래프 svg (바이올린)

커널 빌드에서 json을 작성하는 쉘 스크립트 는 http://bl.ocks.org/mbostock/4063269 와 함께 사용하십시오.

편집 : 이 시점에서 unifdef약간의 변경이 없었습니다 ( -I무시되고 -include지원되지 않으며, 후자는 생성 된 구성 헤더를 포함하는 데 사용됩니다) cat.

274692 total # (was 274686)

스크립트 및 절차가 업데이트되었습니다.

드라이버, 아치 등 이외에도 선택한 구성에 따라 컴파일되거나 조건이없는 많은 조건부 코드가 있습니다. 코드는 동적으로로드 된 모듈이 아니라 코어에 내장되어 있습니다.

따라서 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 와 함께 사용 하기 위해 사용되는 명령 줄을 사용하여 숨겨진 파일을 남겨 둡니다 .

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 사이에서 논의되었습니다. 모든 것을 위해 사용자 공간으로 넘어갈 필요가 없다면 커널 인터페이스가 더 간단해질 수 있습니다. 커널이 모 놀리식이라면 내부적으로 더 최적화되고 더 복잡 할 수 있습니다.

우리는 모듈을 꽤 오랫동안 타협했습니다. 그리고 DPDK (커널에서 더 많은 네트워킹 기능을 이동)와 같은 것들을 계속하고 있습니다. 코어가 많을수록 잠금을 피하는 것이 중요합니다. 더 많은 것들이 사용자 공간으로 이동하고 커널이 줄어들 것입니다.

모 놀리 식 커널 만이 유일한 해결책은 아닙니다. 일부 아키텍처에서는 커널 / 사용자 공간 경계가 다른 함수 호출보다 비싸지 않으므로 마이크로 커널이 매력적입니다.