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