» » » Сделаем код чище: Рекомендации по подготовке изменений в ядро Linux

 

Сделаем код чище: Рекомендации по подготовке изменений в ядро Linux

Автор: admin от 18-03-2015, 16:20, посмотрело: 295

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


Первые попытки могут и не увенчаться успехом, ниже некоторые рекомендации, чтобы снизить вероятность такого исхода. Коротко отмечу основные области возникновения проблем во время подготовки и отправки изменений:

  • Устаревшие, консервативные и специальные подсистемы ядра

  • Стиль кода и оформление изменений

  • Новизна изменения

  • Нюансы процесса



Дополнительно коротко расскажу про существующие механизмы проверки.

Подсистемы ядра



Среди всего множества подсистем ядра выделим следующие:

  • arch/

  • drivers/scsi

  • fs/ (основная часть)

  • drivers/isdn, drivers/ide и им подобные

  • drivers/staging



  • Первая — архитектурный код. Часто содержит устаревшие архитектуры или код, который требует тщательного изучения и понимания. Изменять там что-то имеет смысл только если у вас действительно есть железка, на которой можно протестировать, и реальная проблема, с которой вы боретесь.

    Вторая, SCSI, — пожалуй, самая консервативная подсистема в ядре, хотя туда и можно протащить изменения, но это самый жёсткий путь.

    Третья — основная часть поддержки файловых систем. Одна из очень специфичных и чувствительных подсистем в ядре. Мейнтейнер Al Viro за словом в карман не полезет, и если вы попытаетесь сделать что-то не подумавши, то тут уж не обижайтесь — ответ получите не из приятных.

    Четвёртая категория — изжившие подсистемы, поэтому туда принимаются только глобальные правки при смене внутреннего API.

    Пятая подсистема для Вас! Не зря же я упоминал про staging ранее. В этой подсистеме драйверы проходят инкубационный период, то есть с одной стороны необходимость наличия драйвера вызвана рынком (есть устройства, нужна поддержка), но с другой — качество кода недостаточно для включения в одну из существующих подсистем. Отличное место для пробы пера. Greg KH очень лояльный мейнтейнер, только обязательно проверяйте изменения перед отправкой, иначе расстроите его.

    CodingStyle и SubmittingPatches. Настоятельно рекомендую ознакомится с ними перед началом каких-либо действий.

    Новизна изменения



    Перед тем как делать изменения поищите, может быть кто-то уже сделал это же самое? Не имеет смысла дублировать работу. Так, например, пользователь blueboar2 оформил изменение, а оказалось, что существует более раннее, чуть ли не годичной давности. А если присмотреться, то можно найти и гораздо старее.

    Нюансы процесса


    Не унывайте, если на ваше изменение нет реакции.

    Во-первых надо учитывать, что мейнтенер может быть занят или отсутствовать.

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

    В-третьих, существует примерно раз в квартал пару недель тишины. Это так называемое merge window, иными словами окно, когда мейнтейнеры подсистем шлют накопившиеся за предыдущий цикл изменения главному, то есть Linus'у. Окно начинается ровно с момента выхода очередной стабильной версии, в скором будущем v4.0. Также необходимо учитывать, что многие мейнтейнеры перестают принимать новый код уже после -rc5 (v4.0-rc5 ожидается в понедельник 23 марта), так как им самим надо разобраться со своими деревьями.

    придёт к вам в почтовый ящик.

    Как же потестировать сборку? Вот тут мы переходим к следующим прекрасным переменным окружения при сборке, а именно W=1 C=1. Первая из них поднимает уровень предупреждений компилятора, вторая же, при установленном пакете sparse запускает статический анализатор кода. Следовательно, объединяя с -j8, получим:
    $ make C=1 W=1 -j8
    

    Перед сборкой полезным будет запуск
    $ make includecheck
    

    Он осуществит поиск дублирующихся включений одних и тех же *.h файлов.

    Теперь на руках у вас собранный модуль. Вы оформили изменения в виде *.patch файла с помощью git format-patch. Неплохо бы проверить стилистическу кода. Запустим checkpatch.pl:
    $ scripts/checkpatch.pl 00*
    total: 0 errors, 0 warnings, 43 lines checked
    
    0001-dmaengine-hsu-remove-redundant-pieces-of-code.patch has no obvious style problems and is ready for submission.
    

    Лишний раз перед отправкой убедитесь, что вы оформили всё так, как требуется. Теперь смело запускайте git send-email.

    И напоследок, для простейших изменений есть специальный адрес: trivial@kernel.org. Почитайте ещё такую статью по типу howto: Submitting (Trivial) Linux Kernel Patches.

    Источник: Хабрахабр

    Категория: Game Development, Linux

    Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
    Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

    Добавление комментария

    Имя:*
    E-Mail:
    Комментарий:
    Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
    Введите два слова, показанных на изображении: *