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”
źródło
make menuconfig
aby zobaczyć, ile kodu można włączyć / wyłączyć przed budowaniem.Odpowiedzi:
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
#ifdef
s. 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.
źródło
Według cloc działającego na 3.13, Linux zawiera około 12 milionów linii kodu.
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.config
plik tylko za pomocą obsługiwanego sprzętu (w tym obsługi sprzętu wbudowanego w jądro lub jako moduły ładowalne).źródło
find /lib/modules/$(uname -r)/ -name '*.ko' | wc
mówi nieco ponad 3000. I FWIW, to Debian , „uniwersalny system operacyjny”, który zapewnia pełny system operacyjny, który powinien działać na każdym nowoczesnym komputerze zbudowanym wokół jądra Linux.Dla każdego, kto jest ciekawy, oto podział liczby wierszy dla lustra GitHub:
drivers
przyczynia się do dużej liczby linii.źródło
grep -Pir "\x66\x75\x63\x6b" /usr/src/linux/ | wc -l
./documentation
ma ponad 500 000 linii kodu? ....co?wc
liczba, która ma tę zaletę, że jest łatwiejsza do zdefiniowania niż „linie kodu” :)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 menuconfig
a 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:
Ż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:
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.
źródło
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 (-I
jest ignorowane i-include
nieobsługiwane, ten drugi służy do dołączenia wygenerowanego nagłówka konfiguracji) w tym momencie użyciecat
nie zmienia wiele: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:
zbudował jądro
proces kompilacji jądra pozostawia ukryte pliki wywoływane
*.cmd
za pomocą wiersza poleceń używanego również do kompilacji.o
plików, przetwarzania tych plików i wyodrębnienia kopii celu i zależnościscript.sh
poniżej i użycia jej z find :tworzy to kopię dla każdej zależności o
.o
nazwie o nazwie cel.o.c
kod .c
.h nagłówki (odkażone)
źródło
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.
źródło