Что плохого в изменении *_defconfig при работе с исходниками ядра Linux

По следам моей первой публикации хочу сделать небольшую заметку об изменении файлов i386_defconfig или x86_64_defconfig, входящих в поставку исходников ядра Linux.

В комментариях к той публикации пользователи интересовались, почему не редактировать .config? В масштабах комментария я не смог дать там развёрнутый ответ.

Так вот, начнём с того, в чём разница между .config и *_defconfig. Внимательный пользователь, набрав команду

wc -l .config arch/x86/configs/{i386,x86_64}_defconfig

Вывод

3972 .config

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.

Каковы ваши практики?

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.