Руководство по сборке ядра Linux: результирующий двоичный файл в 10 раз больше, чем предварительно скомпилированные двоичные файлы

Я использую Linux Mint 13 MATE 32bit, я пытаюсь построить ядро ​​(в первую очередь для опыта и для удовольствия).

На данный момент мне нравится строить его с той же конфигурацией, что и с предварительно скомпилированным ядром, поэтому, во-первых, я установил предварительно скомпилированное ядро ​​3.16.0-031600rc6 с kernel.ubuntu.com , загрузив его успешно.

Затем я загрузил ядро ​​3.16.rc6 из kernel.org , распаковал его, настроил его на использование конфигурации из существующего предварительно скомпилированного ядра:

$ make oldconfig 

Он ничего не спрашивал, поэтому в предварительно скомпилированном ядре содержится вся необходимая информация. Затем я его построил (потребовалось около 6 часов):

 $ make 

А затем установите:

 $ sudo make modules_install install 

Затем я загрузился в свое скомпилированное вручную ядро, и он работает, однако процесс загрузки несколько медленнее. Но потом я узнал, что все двоичные файлы ( /boot/initrd.img-3.16.0-rc6 и все модули *.ko в /lib/modules/3.16.0-rc6/kernel примерно в 10 раз больше, чем initrd.img-3.16.0-rc6 скомпилированные версии! Скажем, initrd.img-3.16.0-rc6 составляет 160 658 665 байт, но предварительно скомпилированный initrd.img-3.16.0-031600rc6-generic составляет 16 819 611 байт. Каждый модуль *.ko также больше.

Почему это? Я не указал никаких специальных опций для сборки (я набрал точно такие же команды, как я упоминал выше). Как построить его «правильно»?

  • kgdb не возвращает управление gdb
  • Почему загрузка с SD-карты с моим пользовательским ядром приводит к «VFS: не удается открыть корневое устройство»?
  • Процессы ядра и демоны?
  • Диски SATA ssd
  • Ошибка ядра CentOS 2.6.32-431.el6.x86_64
  • Мониторинг, когда чтение / запись по метаданным или mmaped-файлы попадают на диск
  • Может ли ядро ​​гостевой виртуальной машины KVM быть более поздним, чем его хост? (Когда аппаратная пересылка действует)
  • Блок «Оверлей дерева устройств» уведомляет и загружает детей дважды
  • 2 Solutions collect form web for “Руководство по сборке ядра Linux: результирующий двоичный файл в 10 раз больше, чем предварительно скомпилированные двоичные файлы”

    Несмотря на то, что file говорит, он, как оказалось, является отладкой символов. Поток об этом на LKML заставил меня попробовать:

     make INSTALL_MOD_STRIP=1 modules_install 

    И низко и созерцать, сравнение из каталога /lib/modules/xxx ; до:

     > ls -hs kernel/crypto/anubis.ko 112K kernel/crypto/anubis.ko 

    И после:

     > ls -hs kernel/crypto/anubis.ko 16K kernel/crypto/anubis.ko 

    Более того, общий размер каталога (с использованием того же .config ), о котором сообщалось du -h составил от 185 МБ до 13 МБ.

    Имейте в виду, что помимо использования дискового пространства это не так важно, как может показаться. Отладочные символы не загружаются во время нормальной работы, поэтому фактический размер каждого модуля в памяти, вероятно, идентичен независимо от размера файла .ko . Я думаю, что единственное существенное различие, которое он будет делать, – это размер файла initramfs , и единственная разница, которую он будет делать, – это время, необходимое для распаковки fs. То есть, если вы используете несжатые initramfs, это не имеет значения.

    strip --strip-all также работает, и file сообщает их правильно, как stripped любом случае. Почему это говорит, что он not stripped на дистрибутивы, остается загадкой.

    После вашего make oldconfig сделайте make vmlinuz . Я думаю, вы обнаружите, что предварительно скомпилированное ядро ​​является «исполняемым bzImage», что означает, что он сжат на диске. Если вы внимательно следите за загрузочными сообщениями, вы увидите, что он очень быстро разжат ядро ​​в этом процессе.

    Linux и Unix - лучшая ОС в мире.