2011-12-12 4 views
12

Chciałbym to wiedzieć na temat pierwszego rozruchu i kolejnych butów.W jaki sposób jądro Linux wie, które sterowniki załadować podczas rozruchu?

Kompiluję własne jądro i chcę, aby był tak szczupły, jak to tylko możliwe. Chcę ręcznie skompilować plik .config (głównie jako narzędzie do nauki), więc muszę wiedzieć wszystko, co można wyłączyć. Wiem, że możliwe jest rozwiązanie na mojej aktualnej liście dystrybucyjnej załadowanych sterowników. Jednak jestem ciekawy, w jaki sposób moja dystrybucja odkryła, które sterowniki należy załadować na początku.

TIA.

+3

Zgadywanie tego byłoby lepszym pytaniem dla http://unix.stackexchange.com. – ziesemer

+0

http://doc.opensuse.org/documentation/html/openSUSE_113/opensuse-reference/cha.udev.html – firo

Odpowiedz

3

Greg Kroah daje doskonały przykład, jak znaleźć dokładnie te sterowniki, których potrzebujesz dla jądra. Uprzejmie Greg daje jego książka z dala za darmo online

http://files.kroah.com/lkn/

cytat z książki Grega

I'm especially proud of the chapter on how to figure out how to configure 
a custom kernel based on the hardware running on your machine. This is an 
essential task for anyone wanting to wring out the best possible speed and 
control of your hardware. 
+0

Dzięki za odpowiedź Adrian. Aktualnie pracuję nad rozdziałem 7 książki. Greg Kroah szczegółowo opisuje proces odkrywania, jakie moduły są aktualnie ładowane przez działające jądro - co jest bardzo cenne. Co mnie interesuje, to w jaki sposób system operacyjny wiedział, aby załadować te moduły w pierwszej kolejności? – izzy

+0

ASAIK Brute force ogólnie - próbuje załadować - jeśli to nie działa, prawdopodobnie nie ma sprzętu. –

12

Jak jądro Linux wiedzieć, które sterowniki załadować przy starcie systemu?

Kernel generuje zdarzenia dla urządzeń na przykład magistrali PCI, gdy są one podłączone (albo na gorąco, albo na zimno, zdarzenia są ustawiane w kolejce, dopóki przestrzeń użytkownika nie uruchomi AFAIR). udev odbierze te zdarzenia i wykona wywołania modprobe, które będą zawierać PID/VID (identyfikator produktu/dostawcy) urządzenia (ów); zazwyczaj jest to ciąg znaków z niektórymi * w nim. Modprobe obliczy przecięcie zbioru wyrażone przez wieloznacznik żądań obciążenia udev i zestaw aliasów modułów jądra (z których mogą to być symbole wieloznaczne).

Od USB/FireWire/etc. kontrolery są zwykle dołączane do magistrali PCI, w ten sposób ładowany jest sterownik HCI. Tak to się dzieje; ładowanie odbywa się oczywiście za pomocą USB/Firewire PID/VID.

Moduły protokołu sieciowego (np. Ipv6) nie są jednak obsługiwane przez udev; zamiast tego, gdy program wywołuje socket(AF_INET6, ...), jądro bezpośrednio wywołuje modprobe (dokładniej: cokolwiek jest w /proc/sys/kernel/modprobe) z nie-wieloznacznym aliasem, net-pf-10 w przypadku IPv6, ponieważ AF_INET6 ma wartość 10. modprobe, a następnie ładuje ipv6.ko, ponieważ jest to co ma alias net-pf-10.

Podobnie dla systemów plików, próba mount -t foo spowoduje, że jądro również wywoła modprobe (ponownie, poprzez ____call_usermodehelper), tym razem z foo jako argumentem.

Dostęp do węzłów urządzeń (np. /dev/loop0, o ile już istnieje) ma taką samą strategię, jeśli loop.ko nie jest jeszcze załadowany. Jądro tutaj wymaga block-major-7-0 (ponieważ loop0 zwykle ma (7,0), por. ls -l), a loop.ko ma pasujący alias block-major-7-*.

+0

Nie ma pliku takiego jak moduły.syms, który wyświetla urządzenie, które ma być załadowane podczas startu systemu? – brokenfoot