Для чего это все¶

Некоторым пользователям часто бывает необходимо включить/выключить некоторые опции в конфиге ядра.
Порой это бывает простое включение поддержки >4G на 32-битной системе(да, иногда это лучше использования amd64 профиля) или наоборот - включение режима <1G

А кому-то хочется иметь ядро ТОНКО НАСТРОЕННОЕ под его машину.

В настоящее время есть два пути использования своего конфига ядра:

• классический
• с использованием костылей настройки параметров calculate

Я предлагаю третий вариант честно подсмотренный в ebuild-е пакета busybox.
Кому интересно в busybox используется savedconfig.eclass и в случае если определен одноименный ключ - USE=savedconfig, в качестве конфига используется один из /etc/portage/savedconfig/${CATEGORY}/{${PF},${P},${PN}}, и соответственно текущий конфиг сохраняется в /etc/portage/savedconfig/${CATEGORY}/${PF}
В случае с busybox-ом /etc/portage/savedconfig/sys-apps/busybox-1.19.3-r1

Как я писал выше - я предлагаю применить подобный метод для пакета calculate-sources.
Мои наработки по этому вопросу можно увидеть тут calculate_eclass.diff
Также придется добавить одну строку в calculate-sources-${PN}.ebuild - задать EAPI="4" calculate-sources-3.3.5.diff

Что готово¶

Благодаря этим изменениям, у пакета calculate-sources появляются 4-е новых USE-флага

Я решил, что самые основные отличия машин на которых работает 32-хбитная калька - это СКОЛЬКО ПАМЯТИ УСТАНОВЛЕНО НА МАШИНЕ (intel или amd по большому счету неважно, если уж и настраивать, то придется десяток опций в USE вынести - т.е. смысл теряется. А вот НЕ использовать >3.5G RAM на машине где это возможно - имхо глупо), а значит стоит упростить доступ к этой опции без необходимости настраивать сам конфиг (через USE-ы).

Три нижеследующих ключа могут быть выбраны лишь на 32-хбитной сборке, и выбран может быть лишь один ключ. Если ни один не выбран - никаких изменений к конфиг не вносится.

• nohighmem: оптимизация модели виртуальной памяти ядра под системы с <1G физической памяти. Минус данной опции в том, что если на машине >1G памяти, использоваться будет все-равно лишь один гиг.
  Также я взял на себя смелость включить в этом режиме X86_PAE - возможность расширять виртуальную память при помощи swap до размеров >4G. К примеру при загрузке с PXE/флешки в режиме build, даже бинарное обновление(да что там обновление,даже eix-sync на системе запущенной с ключом docache) может упереться в размер tmpfs, который в свою очередь упирается в размер виртуальной памяти.
• highmem4g: Дефолтная опция для конфига ядра кальки - оптимальное значение при памяти 1G-4G.
• highmem64g: Опция на машинах, где памяти >4G. Само собой параметр X86_PAE включается для удовлетворения зависимостей.
• savedconfig: Собственно сам ключ включающий "обработку" .config-файла. Без него установка происходит в обычном режиме. Конфиг копируется из cl_kernel_config и установка проходит в штатном режиме.
  Если же ключ включен - конфиг ищется по порядку среди файлов /etc/portage/savedconfig/${CATEGORY}/{${PF},${P},${PN}}, и если не находится ни один - используется cl_kernel_config
  Детали можно подсмотреть тут:
  

  less /usr/portage/eclass/savedconfig.eclass
  ##  комменты в ebuild подсказывающие как использовать \
  ##  ... USE=savedconfig можно подсмотреть в
  less /var/db/pkg/sys-apps/busybox-*/busybox-*.ebuild
  

Также вне зависимости от выбранного конфига, при USE=savedconfig выполняется make oldconfig. Я заметил неприятную особенность в конфигах кальки для 3.* ядер - иногда новые параметры новой ревизии ядра (вроде новых драйверов на wifi-свистелки) бывают не отражены в конфиге, и как следствие - выключены. Думаю использовать дефолтное значение правильнее чем сразу отключать. Также такие "потерянные" параметры легко будет найти просмотрев логи этой операции.

Что осталось доделать¶

Собственно проверка показала, что:

• установка с USE=-savedconfig проходит аналогично стандартной установке стандартного кальковского ядра со стандартным calculate-kernel-3.eclass.
  патч заменяющий --mrproper на --use-own-config и cl_kernel_config на .config компенсируется в функции calculate-kernel-tuneconfig_src_configure (cм. строки 87-91 calculate_eclass.diff)
• При установке с USE=savedconfig почти все проходит нормально
• кроме функции calculate-kernel-tuneconfig_src_install, она почему-то не вызывается. Уж и не знаю, что я упустил, но прошу помочь разобраться с этим.
  Как видно из кода, в этой функции должно выполняться:
  • сохранение конфига в /etc/portage/savedconfig/${CATEGORY}/${PF}
  • сохранение make_oldconfig.log
  • сохранение diff-а конфигов оригинального кальковского и текущего.