По следам моей первой публикации хочу сделать небольшую заметку об изменении файлов i386_defconfig или x86_64_defconfig, входящих в поставку исходников ядра Linux.
В комментариях к той публикации пользователи интересовались, почему не редактировать .config? В масштабах комментария я не смог дать там развёрнутый ответ.
Так вот, начнём с того, в чём разница между .config и *_defconfig. Внимательный пользователь, набрав команду
wc -l .config arch/x86/configs/{i386,x86_64}_defconfig
369 arch/x86/configs/i386_defconfig
368 arch/x86/configs/x86_64_defconfig
4709 total
может легко обнаружить, что разница файлов примерно в 10 (!) раз.
Что же делает make *_defconfig? Собственно ничего супер особенного. Важные действия перечислим ниже:
- Удаляет опции, которые устарели или отстутствуют в текущей версии ядра
- Строит дерево зависимостей для опции
- Применяет правила по умолчанию ко всем опциям, которые были указаны в конфигурации по умолчанию и по зависимостям
- Транслирует это всё в файл .config
make savedefconfig, вот тут чуть более подробно.
Таким образом это не просто копия файла.
Возвращаясь к редактированию исходной версии *_defconfig. Какие преимущества?
- Минимум изменений, которые нужно вносить, остальное за нас сделают скрипты
- Всегда можно увидеть разницу со стабильной базой (
git diff)
Недостатки?
- Неудобно в редких случаях делать
git bisect - Нужен собственный локальный бранч (что может быть как достоинством, так и недостатком)
В списке я намекнул уже, что стандартная практика редактирования файлов в Git'е подразумевает создание собственного бранча. Туда мы накапливаем собственные изменения. Для меня достоинства перевесили недостатки, поэтому я не вижу ничего предосудительного в том, чтобы редактивать *_defconfig.
Каковы ваши практики?
Автор: andy_shev
