Dlaczego jądro Linuksa ma ponad 15 milionów linii kodu? [Zamknięte]

Jaka jest zawartość tej monolitycznej bazy kodu?

Rozumiem obsługę architektury procesorów, bezpieczeństwo i wirtualizację, ale nie wyobrażam sobie, aby było to więcej niż 600 000 linii.

Jakie są historyczne i obecne powody, dla których sterowniki są zawarte w bazie kodu jądra?

Czy te ponad 15 milionów linii obejmuje każdy sterownik dla każdego elementu sprzętu? Jeśli tak, to nasuwa się pytanie, dlaczego sterowniki są osadzone w jądrze, a nie oddzielne pakiety, które są automatycznie wykrywane i instalowane na podstawie identyfikatorów sprzętu?

Czy rozmiar kodu stanowi problem w przypadku urządzeń o ograniczonej pamięci lub o ograniczonej pamięci?

Wygląda na to, że gdyby to wszystko było osadzone, zwiększyłoby rozmiar jądra dla ograniczonych przestrzennie urządzeń ARM. Czy preprocesor usuwa wiele linii? Nazywaj mnie szalonym, ale nie wyobrażam sobie maszyny wymagającej tyle logiki, aby uruchomić to, co rozumiem, to role jądra.

Czy istnieją dowody, że rozmiar będzie problemem za ponad 50 lat ze względu na jego pozornie stale rosnący charakter?

Dołączenie sterowników oznacza, że ​​będzie rosnąć wraz z produkcją sprzętu.

EDYCJA : Dla tych, którzy myślą, że taka jest natura jąder, po kilku badaniach zdałem sobie sprawę, że nie zawsze. Jądro nie musi być tak duże, ponieważ mikrojądro Carnegie Mellon Mach zostało wymienione jako przykład „zwykle poniżej 10 000 wierszy kodu”

Sterowniki są utrzymywane w jądrze, więc gdy zmiana jądra wymaga globalnego wyszukiwania i zamiany (lub wyszukiwania i modyfikacji ręki) dla wszystkich użytkowników funkcji, robi to osoba dokonująca zmiany. Aktualizowanie sterownika przez osoby dokonujące zmian w interfejsie API to bardzo miła zaleta, zamiast konieczności robienia tego samemu, gdy nie kompiluje się na nowszym jądrze.

Alternatywą (co dzieje się w przypadku sterowników utrzymywanych poza drzewem) jest to, że łatka musi zostać ponownie zsynchronizowana przez swoich opiekunów, aby nadążać za wszelkimi zmianami.

Szybkie wyszukiwanie wywołało debatę na temat rozwoju sterowników wewnątrz drzewa i poza drzewem .

Linux jest obsługiwany głównie przez utrzymywanie wszystkiego w głównym repozytorium. Budowanie małych, zredukowanych jąder jest obsługiwane przez opcje konfiguracji do kontrolowania #ifdefs. Możesz więc absolutnie zbudować małe, zredukowane jądra, które kompilują tylko niewielką część kodu w całym repozytorium.

Szerokie zastosowanie Linuksa w systemach osadzonych doprowadziło do lepszego wsparcia dla pomijania rzeczy niż Linux miał wiele lat wcześniej, gdy drzewo źródeł jądra było mniejsze. Super-minimalne jądro 4.0 jest prawdopodobnie mniejsze niż super-minimalne jądro 2.4.0.

Według cloc działającego na 3.13, Linux zawiera około 12 milionów linii kodu.

• 7 milionów LOC w sterownikach /
• 2 miliony LOC w łuku /
• tylko 139 tysięcy LOC w jądrze /

lsmod | wc na moim laptopie Debian pokazuje 158 modułów załadowanych w czasie wykonywania, więc dynamiczne ładowanie modułów jest dobrze używanym sposobem wspierania sprzętu.

Solidny system konfiguracji (np. make menuconfig) Służy do wyboru, który kod ma zostać skompilowany (a bardziej do twojego punktu, którego kodu nie skompilować). Systemy osadzone definiują własny .configplik tylko za pomocą obsługiwanego sprzętu (w tym obsługi sprzętu wbudowanego w jądro lub jako moduły ładowalne).

Dla każdego, kto jest ciekawy, oto podział liczby wierszy dla lustra 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
=============================================

driversprzyczynia się do dużej liczby linii.

Dotychczasowe odpowiedzi wydają się brzmiać „tak, jest dużo kodu” i nikt nie odpowiada na pytanie z najbardziej logiczną odpowiedzią: 15 mln +? WIĘC CO? Co 15 mln wierszy kodu źródłowego ma wspólnego z ceną ryb? Co czyni to tak niewyobrażalnym?

Linux wyraźnie robi wiele. O wiele więcej niż cokolwiek innego ... Ale niektóre z twoich punktów pokazują, że nie szanujesz tego, co się dzieje, gdy jest zbudowany i używany.

• Nie wszystko jest skompilowane. System kompilacji jądra umożliwia szybkie definiowanie konfiguracji, które wybierają zestawy kodu źródłowego. Niektóre są eksperymentalne, niektóre stare, niektóre po prostu nie są potrzebne dla każdego systemu. Spójrz na /boot/config-$(uname -r)(na Ubuntu) w, make menuconfiga zobaczysz, ile jest wykluczone.

  I to jest dystrybucja pulpitu ze zmiennym celem. Konfiguracja dla systemu osadzonego pobierałaby tylko to, czego potrzebuje.

• Nie wszystko jest wbudowane. W mojej konfiguracji większość funkcji jądra jest zbudowana jako moduły:

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

  Żeby było jasne, można je wszystkie wbudować ... Tak jak można je wydrukować i przekształcić w gigantyczną papierową kanapkę. To po prostu nie miałoby sensu, gdybyś nie robił niestandardowej kompilacji dla dyskretnego zadania sprzętowego (w takim przypadku ograniczyłbyś już liczbę tych elementów).

• Moduły ładowane są dynamicznie. Nawet jeśli w systemie są dostępne tysiące modułów, system pozwoli Ci załadować tylko to, czego potrzebujesz. Porównaj wyniki:

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

  Prawie nic nie jest załadowane.

• Mikrojądra to nie to samo. Wystarczy 10 sekund, by spojrzeć na wiodący obraz do strony Wikipedii, do której się odnosiłeś , podkreślając, że są one zaprojektowane w zupełnie inny sposób.

  

  Sterowniki systemu Linux są zinternalizowane (głównie jako moduły ładowane dynamicznie), a nie przestrzeń użytkownika, a systemy plików są podobnie wewnętrzne. Dlaczego jest to gorsze niż używanie zewnętrznych sterowników? Dlaczego mikro jest lepsze do obliczeń ogólnego zastosowania?

Komentarze ponownie podkreślają, że go nie otrzymujesz. Jeśli chcesz wdrożyć Linuksa na dyskretnym sprzęcie (np. Lotniczym, TiVo, tablecie itp.) , Skonfiguruj go tak, aby budował tylko potrzebne sterowniki . Możesz zrobić to samo na pulpicie za pomocą make localmodconfig. W efekcie powstaje niewielka, specjalnie zaprojektowana wersja jądra z zerową elastycznością.

W przypadku dystrybucji takich jak Ubuntu dopuszczalny jest pojedynczy pakiet jądra o wielkości 40 MB. Nie, wyczyść to, w rzeczywistości jest to lepsze niż masowe archiwizowanie i pobieranie scenariusza, w którym utrzymywanie ponad 4000 pływających modułów w postaci pakietów. Zużywa dla nich mniej miejsca na dysku, łatwiejsze do spakowania w czasie kompilacji, łatwiejsze do przechowywania i jest lepszy dla ich użytkowników (którzy mają system, który po prostu działa).

Przyszłość też nie wydaje się problemem. Szybkość procesora, gęstość dysku / ceny i poprawa przepustowości wydają się znacznie szybsze niż wzrost jądra. Pakiet 200 MB jądra za 10 lat nie byłby końcem, gdyby świat.

To też nie jest ulica jednokierunkowa. Kod zostaje wyrzucony, jeśli nie jest utrzymywany.

Tinyconfig Bubble Graph SVG (skrzypce)

skrypt powłoki, aby utworzyć Json z kompilacji jądra, użyj z http://bl.ocks.org/mbostock/4063269

Edycja : okazało się, unifdefże ma pewne ograniczenia ( -Ijest ignorowane i -includenieobsługiwane, ten drugi służy do dołączenia wygenerowanego nagłówka konfiguracji) w tym momencie użycie catnie zmienia wiele:

274692 total # (was 274686)

skrypt i procedura zostały zaktualizowane.

Oprócz sterowników, arch itp. Jest wiele skompilowanych kodów warunkowych lub nie, w zależności od wybranej konfiguracji, kod niekoniecznie w dynamicznie ładowanych modułach, ale wbudowany w rdzeń.

Tak więc, pobrałem źródła linux-4.1.6 , wybrałem tinyconfig , nie włącza modułów i szczerze mówiąc nie wiem, co to włącza ani co użytkownik może z tym zrobić w czasie wykonywania, w każdym razie skonfiguruj jądro:

# tinyconfig      - Configure the tiniest possible kernel
make tinyconfig

zbudował jądro

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

proces kompilacji jądra pozostawia ukryte pliki wywoływane *.cmdza pomocą wiersza poleceń używanego również do kompilacji .oplików, przetwarzania tych plików i wyodrębnienia kopii celu i zależności script.shponiżej i użycia jej z find :

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

tworzy to kopię dla każdej zależności o .onazwie o nazwie cel.o.c

kod .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 nagłówki (odkażone)

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

Kompromisy dotyczące monolitycznych jąder były od samego początku dyskutowane publicznie między Tananbaumem i Torvaldsem. Jeśli nie musisz wchodzić do przestrzeni użytkownika, wszystko w interfejsie jądra może być prostsze. Jeśli jądro jest monolityczne, może być wewnętrznie bardziej zoptymalizowane (i bardziej niechlujne!).

Od dłuższego czasu mieliśmy moduły jako kompromis. I kontynuuje takie rzeczy jak DPDK (przenoszenie większej liczby funkcji sieciowych z jądra). Im więcej rdzeni zostanie dodanych, tym ważniejsze jest unikanie blokowania; więc więcej rzeczy przeniesie się do przestrzeni użytkownika, a jądro się skurczy.

Zauważ, że monolityczne jądra nie są jedynym rozwiązaniem. W niektórych architekturach granica jądra / przestrzeni użytkownika nie jest droższa niż jakiekolwiek inne wywołanie funkcji, co czyni mikrokernele atrakcyjnymi.