Co dokładnie robi „make oldconfig” w pliku makefile jądra Linuksa?

Czy ktoś może wyjaśnić, co dokładnie robi docelowy "oldconfig" w pliku makefile jądra Linuksa? Widzę, że jest to odniesienie w niektórych dokumentach kompilacji, ale nigdy nie wyjaśniłem, co dokładnie robi.

Czyta istniejący .configplik i pyta użytkownika o opcje w bieżącym źródle jądra, których nie ma w pliku. Jest to przydatne podczas pobierania istniejącej konfiguracji i przenoszenia jej do nowego jądra.

Przed uruchomieniem make oldconfigmusisz skopiować plik konfiguracyjny jądra ze starszego jądra do katalogu głównego nowego jądra.

Możesz znaleźć kopię starego pliku konfiguracyjnego jądra w działającym systemie pod adresem /boot/config-3.11.0. Alternatywnie, kod źródłowy jądra ma konfiguracje w plikachlinux-3.11.0/arch/x86/configs/{i386_defconfig / x86_64_defconfig}

Jeśli źródło twojego jądra znajduje się pod adresem /usr/src/linux:

cd /usr/src/linux
cp /boot/config-3.9.6-gentoo .config
make oldconfig

Podsumowanie

Jak wspomniał Ignacio , aktualizuje .configza Ciebie po zaktualizowaniu źródła jądra, np git pull. Z.

Stara się zachować istniejące opcje.

Posiadanie odpowiedniego skryptu jest pomocne, ponieważ:

• mogły zostać dodane nowe opcje lub usunięte

• format konfiguracyjny Kconfig jądra ma opcje, które:

  • implikujcie się nawzajem za pośrednictwem select
  • zależy od innego przez depends

  Te relacje opcji sprawiają, że ręczne rozwiązywanie konfiguracji jest jeszcze trudniejsze.

Zmodyfikujmy ręcznie plik .config, aby zrozumieć, jak rozwiązuje on konfiguracje

Najpierw wygeneruj domyślną konfigurację za pomocą:

make defconfig

Teraz .configręcznie edytuj wygenerowany plik, aby emulować aktualizację jądra i uruchom:

make oldconfig

zobaczyć, co się stanie. Kilka wniosków:

1. Linie typu:

   # CONFIG_XXX is not set
   

   nie są zwykłymi komentarzami, ale faktycznie wskazują, że parametr nie jest ustawiony.

   Na przykład, jeśli usuniemy wiersz:

   # CONFIG_DEBUG_INFO is not set
   

   i biegnij make oldconfig, zapyta nas:

   Compile the kernel with debug info (DEBUG_INFO) [N/y/?] (NEW)
   

   Po zakończeniu .configplik zostanie zaktualizowany.

   Jeśli zmienisz dowolny znak w linii, np. Na # CONFIG_DEBUG_INFO, to się nie liczy.

2. Linie typu:

   # CONFIG_XXX is not set
   

   są zawsze używane do zaprzeczenia własności, chociaż:

   CONFIG_XXX=n
   

   jest również rozumiana jako negacja.

   Na przykład, jeśli usuniesz # CONFIG_DEBUG_INFO is not seti odpowiesz:

   Compile the kernel with debug info (DEBUG_INFO) [N/y/?] (NEW)
   

   z N, plik wyjściowy zawiera:

   # CONFIG_DEBUG_INFO is not set
   

   i nie:

   CONFIG_DEBUG_INFO=n
   

   Ponadto, jeśli ręcznie zmodyfikujemy linię, aby:

   CONFIG_DEBUG_INFO=n
   

   i uruchom make oldconfig, a następnie linia zostanie zmodyfikowana do:

   # CONFIG_DEBUG_INFO is not set
   

   bez oldconfigpytania nas.

3. Konfiguracje, których zależności nie są spełnione, nie pojawiają się w .config. Wszyscy inni to robią.

   Na przykład ustaw:

   CONFIG_DEBUG_INFO=y
   

   i biegnij make oldconfig. Będzie ona teraz zwrócić się do nas na: DEBUG_INFO_REDUCED, DEBUG_INFO_SPLITitp configs.

   Te właściwości nie pojawiły się defconfigwcześniej.

   Jeśli spojrzymy poniżej, lib/Kconfig.debuggdzie są zdefiniowane, zobaczymy, że zależą one od DEBUG_INFO:

   config DEBUG_INFO_REDUCED
       bool "Reduce debugging information"
       depends on DEBUG_INFO
   

   Więc kiedy DEBUG_INFObył wyłączony, w ogóle się nie pojawili.

4. Konfiguracje, które są selectedwłączone, są ustawiane automatycznie bez pytania użytkownika.

   Na przykład, jeśli CONFIG_X86=yi usuniemy wiersz:

   CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
   

   i uruchom make oldconfig, linia zostanie odtworzona bez pytania nas, w przeciwieństwie do DEBUG_INFO.

   Dzieje się tak, ponieważ arch/x86/Kconfig zawiera:

   config X86
       def_bool y
       [...]
       select ARCH_MIGHT_HAVE_PC_PARPORT
   

   i wybierz wymusza, aby ta opcja była prawdziwa. Zobacz też: /unix/117521/select-vs-depends-in-kernel-kconfig

5. Konfiguracje, których ograniczenia nie są spełnione, są proszone o podanie.

   Na przykład defconfigustawiliśmy:

   CONFIG_64BIT=y
   CONFIG_RCU_FANOUT=64
   

   Jeśli edytujemy:

   CONFIG_64BIT=n
   

   i biegnij make oldconfig, zapyta nas:

   Tree-based hierarchical RCU fanout value (RCU_FANOUT) [32] (NEW)
   

   Dzieje się tak, ponieważ RCU_FANOUTjest zdefiniowany init/Kconfigjako:

   config RCU_FANOUT
       int "Tree-based hierarchical RCU fanout value"
       range 2 64 if 64BIT
       range 2 32 if !64BIT
   

   Dlatego bez 64BITwartości maksymalna to 32, ale 64ustawiliśmy na .config, co spowodowałoby, że byłaby niespójna.

Bonusy

make olddefconfigustawia każdą opcję na ich wartość domyślną bez pytania interaktywnego. Uruchamia się automatycznie, makeaby zapewnić .configspójność w przypadku ręcznej modyfikacji, tak jak my. Zobacz też: /server/116299/automatically-answer-defaults-when-doing-make-oldconfig-on-a-kernel-tree

make alldefconfigjest podobny make olddefconfig, ale akceptuje również fragment konfiguracji do scalenia. Ten cel jest używany przez merge_config.shskrypt: https://stackoverflow.com/a/39440863/895245

A jeśli chcesz zautomatyzować .configmodyfikację, nie jest to zbyt proste: jak nieinteraktywnie włączyć funkcje w pliku .config jądra Linuksa?

Aktualizuje starą konfigurację o nowe / zmienione / usunięte opcje.

Z tej strony :

Make oldconfig pobiera plik .config i przepuszcza go przez reguły plików Kconfig i tworzy plik .config, który jest zgodny z regułami Kconfig. Jeśli brakuje wartości CONFIG, make oldconfig zapyta o nie.

Jeśli plik .config jest już zgodny z regułami znajdującymi się w Kconfig, to make oldconfig w zasadzie nie działa.

Jeśli miałbyś uruchomić make oldconfig, a następnie make oldconfig po raz drugi, to drugie nie spowoduje żadnych dodatkowych zmian.

To tortura. Zamiast dołączać ogólny plik konfiguracyjny, powodują one, że trafisz powrót 9000 razy, aby go wygenerować.