Linux kernel development для самых маленьких


    Любой программист знает, что теоретически он может внести свой посильный вклад в развитие Linux ядра. С другой стороны, подавляющее большинство уверено, что занимаются этим исключительно небожители, а процесс контрибьюта в ядро настолько сложен и запутан, что обычному человеку разобраться в нём нет никакой возможности. А значит, и надобности.
    Сегодня мы попробуем развеять эту легенду и покажем, как абсолютно любой инженер при наличии достойной идеи, воплощённой в коде, может предложить ее на рассмотрение Linux community для включения в ядро.


    0. Подготовка


    Как и перед любой инженерной операцией, всё начинается с подготовки своего рабочего места. И первейшее здесь действие — это завести себе аккаунт с адекватным именем. В идеальном мире это будет просто транскрипция имени и фамилии. Если за учётку вроде MamkinC0d$r или Developer31337 в других местах пальцем в вас тыкать не будут, то правила LKC (Linux kernel community) такое прямо запрещают — инкогнито контрибьютить в ядро не принято.


    Далее вам понадобится место на локальной машине. Сама папка Linux со скачанными исходниками весит чуть меньше 3-х гигов. Но если ядро пробовать собирать, то вместе с модулями займёт все 30 GB.


    Захотелось собрать несколько веток? Умножаем 30 на число веток.
    И помним — скорость сборки прямо связана с количеством доступных ядер! Больше ядер — быстрее соберётся. Так что не стесняйтесь выделять под это самую мощную машину.


    1. Mail


    Самый спорный и поэтому регулярно вызывающий споры момент — это канал коммуникации с LKC. Он безальтернативно один. Почта. Причём сообщения отправляются по классике через smtp.


    Вокруг необходимости делать всё через плейнтекст в почте есть масса споров. Недавно в сети была очередная громкая статья на эту тему. Суть материала: письма — это, конечно, здорово, но пихать туда всё, включая куски кода — это вам (т.е. LKC) популярности не добавляет и даже наоборот, отпугивает новичков. С одной стороны вроде и да, если ты не можешь спокойно и структурировано изложить свои мысли в голом тексте, то в низкоуровневой разработке ловить будет особо нечего. С другой стороны, слать в письмах сорсы патчей — это даже архаизмом назвать уже сложно.


    Но, как принято в уютном мирке ядра, Линус хлопнул кулаком по столу — и все пишут письма. Возможно, буквально завтра это изменится, но на момент выхода статьи это письма и только письма.


    Какой email-client выбрать — есть рекомендации. Самым рекомендуемым почтовым агентом для LKC остаётся mutt. Да, тот самый текстовый почтовый клиент, от которого сводит олдскулы. Для начала mutt нужно поставить (я думаю, со своим пакетным менеджером вы и сами справитесь), а потом задать параметры в файле ~/.muttrc.


    #
    # folders
    #
    #set imap_authenticators="gssapi:login"
    #set ssl_starttls=yes
    set mbox_type=Maildir
    set folder="imaps://my_name@imap.my_server.ru/"
    set spoolfile="=INBOX"
    set mbox="="
    set record="=Sent"
    set postponed="=Drafts"
    set trash="=Trash"
    set imap_list_subscribed=yes 
    
    # which mailboxes to list in the sidebar
    mailboxes =INBOX =Sent =Sent/SentOld =Drafts =Templates =Trash =my/friends =my/family
    #
    # SMTP
    #
    set smtp_url="smtps://my_name@smtp.my_server.ru:my_smtp_port/"
    set from = "My Name <my_name@my_server.ru>"
    set envelope_from = "yes"

    Но почты недостаточно. Без Git никуда.


    2. Git


    Прежде чем что-то делать с исходниками ядра, нужно настроить Git. Можно конфигурировать файлы напрямую, но есть упрощающая жизнь утилита git config, через которую можно регулировать все аспекты работы Git'a.


    Внутри есть три уровня настроек: общие для всех пользователей системы и для всех репозиториев (git config --system), общие для всех репозиториев конкретного пользователя (git config --global), отдельные для каждого репозитория (git config --local).


    Глобальные настройки хранятся в /etc/gitconfig, настройки пользователя в ~/.gitconfig или ~/.config/git/config, а настройки отдельных репозиториев хранятся в файле config в каталоге .git/config.


    В общем случае будет достаточно законфигурировать файл для пользователя ~/.gitconfig. Основная идея: при отправке коммитов должно отображаться ваше корректное имя.


    [user]
        name = My Name
        email = my_name@my_server.ru
    [sendemail]
        smtpencryption = tls
        smtpserver = smtp.my_server.ru
        smtpuser = my_name@my_server.ru
        smtpserverport = 465
        confirm = always
        suppress-cc = misc-by
    [color]
        ui = auto
    [format]
        signOff = true
    [http]
        sslVerify = true
    [pull]
        rebase = false

    Примечательно, что параметр sslVerify = true препятствует работе с Git напрямую через git://git.kernel.org и форсит доступ только через https://git.kernel.org. Так, наверное, секьюрнее, хотя какого-то смысла я в этом не вижу. Но, может, чего-то не знаю?


    signOff обязателен, чтоб в коммитах была информация об авторе. По идее, надо бы, чтобы коммиты подписывались. Была тут недавно статья на эту тему.


    Отправка патча выполняется командой git send-email. У git send-email есть несколько параметров с участием smtp, которые можно (и нужно) переопределить.


    Полезный параметр --smtp-debug=1. Осуществляет логирование SMTP запросов и ответов, что помогает при разборе проблем с настройками почты. Например, я столкнулся с тем, что почтовый сервер, на котором есть у меня почтовый ящик, не поддерживает TLS. Возможны проблемы с аутентификацией, а сообщения об ошибке git send-email выдаёт не особо разнообразные и адекватные.


    Можно задавать пароль к почте через параметр --smtp-pass=p4ssw0rd или вообще захардкорить в конфиге, но это это для тех, кому терять нечего. Но если каждый раз вводить пароль лень, то есть некий хак: если username был задан (через --smtp-user или sendmail.smtpUser), а пароль не указан, тогда пароль получается через git-credential.


    Итак, окно в большой мир прорубили. Можно переходить к воплощению своей грандиозной идеи в коде.


    3. Coding


    Итак, мы готовы сделать первый шаг непосредственно в разработке — склонировать к себе репозиторий. Советую делать это сразу с указанием ветки, которая будет создана. Также отмечу, что работать лучше не над текущим состоянием в master, а над стабильной версией или кандидатом на релиз. Так вы будете более уверены, что ядро соберётся и будет как-то работать, не вызовет неожиданных конфликтов из-за изменений в других подсистемах. Поэтому всегда внимательно смотрите тэги.


    И — опять же — имя своей ветке постарайтесь дать чёткое и лаконичное. В идеальном мире оно даже может отображать суть вносимых изменений. Если вы исправляете известный баг, то хорошим тоном считается включить в название ветки номер issue.


    cd ~/ 
    git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux-<branch name>
    git checkout v5.9-rc2 -b <my new branch name>

    Операция довольно долгая, так что смело можно идти за кофе или на обед. А если попробовать ускорить процесс, отказавшись от истории, то работать с "этим" будет невозможно.


    Итак, мы получили ветку, в которой можно начинать свою разработку. Здесь всё очевидно: пишем код, собираем, тестируем, исправляем баги — и так до получения нужного результата. О том, как собирать ядро и проводить отладку, информации в сети море, так что подробно описывать весь процесс я не буду. Лишь вкратце пробежимся по нему чуть позже. Единственный нюанс, который добавлю от себя прямо сейчас: перед сборкой проверьте наличие всех необходимых программ из этого списка и их минимальные версии.


    Если бродить вслепую по гуглу не хочется, то вся максимально полезная информация по ядру сконцентрирована тут. Прочитать стоит действительно всё. Особенно правильно будет начать с How To о том, как правильно коммуницировать. Потому что мейнтейнеры, как правило, люди весьма занятые, и вникать в невнятно составленные письма им никакого интереса. Да и вам будет обидно, если из-за плохого описание ваше детище не примут в апстрим.


    И вот свой небольшой и эффективный код вы написали, отладили, всё протестировали и готовы отправлять на рассмотрение. Но не спешите этого делать. Для начала обязательно проверьтесь на code style. В этом вам поможет ./script/checkpatch.pl. Для этого сделаем патч и отправим его на проверку.


    git add --all
    git diff HEAD^ --staged >my-branch-name.patch
    ./scripts/checkpatch.pl my-branch-name.patch

    После того, как пройдёт первое удивление и вы доустановите необходимые компоненты для python2 типа ply и git (который у меня так и не установился), наступит чудесное время исправления ошибок и ворнингов. По результатам которых вы а) поймёте, что красивый код писать вы не умеете б) потеряете всякое желание что-то куда-то отправлять. Ведь даже если отбросить все шутки, ещё можно как-то смириться с тем, что длина строк ограничена 100 символами (это начиная с версии 5.7, раньше так было вообще 80). Но вот такие места оставляют неизгладимое впечатление:


    WARNING: Improper SPDX comment style for 'block/blk-filter-internal.h', please use '/*' instead
    #85: FILE: block/blk-filter-internal.h:1:
    +// SPDX-License-Identifier: GPL-2.0

    Для .h файлов строка с информацией о лицензии должна быть в ремарках / * */, а для *.c файлов должна быть в ремарках //. Такое запросто выбьет кого угодно из душевного равновесия. Вопрос: "Зачем?!" до сих пор болтается в моей голове, хотя есть вера в то, что это не просто ошибка в скриптах.


    Кстати, чтобы просто проверить один файл достаточно вызвать


    ./scripts/checkpatch.pl --file <file name> 

    Можно прикрутить этот вызов к git, чтобы автоматически запускался этот скрипт при попытке что-то зачекинить.


    Ещё важное замечание: clang-format добрался и до ядра Linux. Файл .clang-format расположился в корне ядра в кучке с другими конфигами. Но я не советую добавлять его в хук для git. Лучше всего корректно настроить среду разработки и запомнить code style. Лично мне не понравилось как он делает переносы длинных строк. Если вдруг строка оказалась длиннее допустимой, то скорее всего функция, в которой эта строка расположилась, является кандидатом на рефакторинг, и лучше его не откладывать. С другой стороны, если у вас много уже готового кода который нужно адаптировать для ядра — clang-format может сильно облегчить вам задачу.


    4. Kernel build


    Несмотря на то, что процесс описан в других статьях тут и тут, я все же повторюсь.


    По шагам процесс сборки ядра довольно прост, если не вдаваться в детали. Для начала ставим необходимые пакеты (использовался Debian 10):


    apt install libncurses-dev flex bison bc libelf-dev libssl-dev

    Это без компилятора и обычного для С/С++ разработчика набора программ.
    Запускаем конфигурацию:


    make menuconfig

    Тут есть интересный аспект: в качестве шаблона будет браться config ядра от вашего боевого ядра, которое, скорее всего, подготовлено дистрибьютером. Для Debian 10 сборка проходит успешно, если в конфиге потереть информацию о встраиваемых в ядро сертификатах.


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


    make -j <число ядер>

    Этого достаточно для проверки собираемости, но недостаточно для запуска ядра в системе, так как без модулей ядро на реальной системе практически беспомощно.


     make -j <число ядер> modules

    Если какой-то модуль не собирается, просто вырубите его в ближайшем Makefile-е (если 100% уверены, что не пытались в нём что-то улучшить). Наверняка он вам не пригодится, и тратить время на исправления смысла нет.


    Теперь можно деплоить то, что получилось, на эту же систему.


    sudo make modules_install
    sudo make install

    Хотя, конечно, экспериментировать с ядром на той же машине, где ведётся разработка — дело рискованное.


    Поэтому как минимум нужно снять снапшот, сделать резервную копию или лучше вообще выполнять отладку на другой (лучше виртуальной) машине. Но как это делать, я пока не разбирался. Если у кого есть такой опыт — пишите в комменты, добавлю в статью.


    На моей системе загрузчик после установки ядра автоматически обновился. Если у вас этого не произошло, то это делается это на Debian-подобных системах командой:


    update-grub

    Update: Как верно заметил gavk, ядро давно уже умеет собирать пакеты, причём как для deb, так и для rpm.
    Команда


    make help | grep pkg 

    выводит весь ассортимент. Так что команда


    make bindeb-pkg -j <число ядер>

    должна собрать пакет с ядром.


    5. Patches


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


    git commit --all --signoff -m "message" -m "new message line" 

    Ещё можно комментарии к коммиту дополнить в человеческом текстовом редакторе.


    git commit --amend

    И теперь его можно оформить в виде того самого письма. Правила хорошего тона, или best practice, если угодно — это 75 символов на строку.


    git format-patch <имя базовой ветки, например v5.9-rc2> --signoff --cover-letter

    В результате получите два файла. В первом 000-cover-letter.patch нужно указать заголовок письма "Subject" и основное описание патча. В описании патча пишем, для чего он создавался, кому он сделает жизнь на нашей планете лучше и каким образом. Только не словоблудим про космические корабли в Большом театре, а пишем лаконично и по делу. И не в коем случае не пишите корпоративную лабуду а-ля "Без этого патча мой бизнес встанет, меня уволят, а дети мои умрут от голода". Нет, строго по существу: "Увидел вот такую проблему вот тут, починить решил вот таким образом, исходники патча прилагаю". Всё, вы восхитительны! А если не превысили 75 символов на строку, то восхитительны в квадрате.


    А ещё один волшебный скриптик ./scripts/getmaintainers.pl <patch file> позволит узнать, кому письмо отправлять.


    И вот он, момент отправления письма, ради которого всё и затевалось:


    git send-email --to=<list of maintainers emails> ./0000-cover-letter.patch ./0001-<my commit message>.patch

    Дальше остаётся только сидеть и ждать ответного письма, где вам скорее всего скажут, что всё здорово, но надо ещё сделать вот это и поправить вот здесь. Возможно, придётся доказывать, что ваш функционал действительно новый и не создаёт дублирования. Хотя могут и сразу всё принять, сказав большое спасибо (шутка :-).


    После того, как ваш патч был принят, крайне желательно удалить свою ветку.


    git checkout master
    git branch -D <branch-name>
    git push origin --delete <branch-name>

    6. Debuging


    И чуть-чуть про отладку. Бонус "на сладкое" для начинающих разработчиков ядра, так сказать.


    Как правило, при ошибке вы получаете лог с calltrace-ом. Там указываются имена функций и смещения. Примерно вот так:


    [  457.517480] BUG: kernel NULL pointer dereference, address: 000000000000003c
    [  457.517499] RIP: 0010:tracking_submit_bio+0xac/0x140 [veeamsnap]

    Так вот, чтобы понять, в каком месте функции произошла ошибка, достаточно запустить дебагер с подгруженным в него модулем:


    gdb ./veeamsnap.ko

    Важно, чтобы в модуле сохранились символы (stripped модуль вам тут не поможет).


    Выполнив команду list


    list *tracking_submit_bio+0xac

    вы увидите строку кода, приведшую к ошибке. В случае передачи управления по неверному адресу, вы увидите следующую за ошибкой строку.


    И на этом позвольте откланяться.


    Буду рад вопросам и замечаниям в комментариях.


    P.S. Если хочется в команду наших разработчиков для решения подобных задач, у нас есть вакансия для C++ разработчика.
    А ещё у нас сейчас открыта вакансия инженера техподдержки наших продуктов для Linux. Все подробности здесь.

    Veeam Software
    Продукты для резервного копирования информации

    Комментарии 27

      0
      Картинка хороша! Можно украду?
      Все остальное тоже. Дельная статья. Правда яду многовато. Так и брызжет во все стороны. Но лучше здесь, чем в ответах списка рассылки. Там яду будет еще больше.
        +4
        Яду? Ну вообще старался воздерживаться. Даже колпачки резиновые на клыки надевал (шутка). Может разьве что кислинки чуть чуть добавил, чтоб читать было интереснее.

        А при ответах в списке рассылок, вообще взял за правило отвечать только на следующий день. Токсичность там вообще ни к чему.

        Картинка — работа наших дизайнеров — так что наверное будет собственностью. Хотя лично меня зелёные губы немного пугают.
          +6
          В любом случае статья получилась нужной и правильной. А яд в таких количествах — это точно лекарство.

          А картинка… Мне первых «Людей в черном» напомнила. Там правда маленькая девочка с учебником ядерной физики была, но… «Искусство программирования» местами пострашнее будет.
            0
            Всё так и есть ;)
              +3
              «Людей в черном» — собственно да, идея именно оттуда. А квантовую физику трудом Кнута заменили. Мне как-то лет двадцать тому назад эта книга в руки попалась. Бумажная такая, пошарпанная. Почитал там про бинарный поиск на магнитной ленте. Книга меня уже тогда поразила свой древностью. Однако я уверен, что изложенные в ней алгоритмы актуальны и по сей день.
                +1
                Многотомный «Искусство программирования» несомненно одна из тех книг, которые стоит прочесть. И не по разу. Сначала просто бегло пробежаться по основным алгоритмам (да, там есть все — стеки, очереди, одно- и много- связные списки...). Потом почитать беглый обзор — где, что, когда, почему в одних случаях лучше одно, а в других другое. Теоретически, после этого стоит вернуться и разобраться со всем «великим и ужасным» математическим аппаратом. Увы… До последнего шага я не дошел. Но все, что переводилось стоит на полке и дожидается пенсии. Видимо раньше до конца разобраться не получится.
                Впрочем, у меня есть индульгенция от автора. Он сам разрешил так читать его книгу. Дай бог здоровья Деду Кнуту. И, безусловно, ждем следующего тома. А то «ремеслом программирования» все полки завалены, а вот «искусство...» это только у него.

                P.S.
                А его решение выдумать свой компьютер было абсолютно правильным. Черт возьми, он «еще тогда» предвидел появление JAVA ;-)
                  0

                  Если инопланетное вторжение дотянулось до стражей ночи (есть перевод, но оригинал круче) с томиком Кнута, то нам уже крышка.

              +4
              По поводу яда в статье не согласен — местами выглядит, скорее, как сарказм.
                +1
                Хорошо. Согласен. Перестарался с оценкой. Виноват. Наверное потому, что сам все вокруг ядом поливаю, когда с CodingCtyle воюю. Увы, поправит уже не могу.
                Но, на самом деле, CodingStyle вопрос привычки. С третьего раза уже проблем не возникает. Но CodingStyle это ерунда. А вот обосновать свои код… Почему именно так, а не иначе… Особенно когда он на стыке двух подсистем (а разве бывает по другому)… Ладно, это пройти надо. Однострочники и исправлением опечаток или откровенных коясков проходят легко. А вот драйвер под железку… Тут временами помимо техники еще и дипломатия нужна.
              0
              Спасибо, интересный пост, я и вправду думал, что этим занимаются супер гуру программирования и даже как то не пытался узнавать, куда мне до них. Возник такой вопрос, я так понимаю язык программирования используемый в разработке ядра — C/C++? Мне с Python там делать нечего? Просто слышал что некоторые компоненты Linux, не ядра, а в целом системы написаны Python. И еще вопрос реально ли зарабатывать? Допустим если решил посвятить себя этому, так как веб разработка приелась уже, реально ли получать деньги за разработку и поддержку Linux?
                0
                Все ядро использует только C 1989 года. И немного ассемблера.
                  0
                  Есть в ядре директория scripts, так вот там обильно посыпано перловкой, но и python и bash есть. Меня впечатлила тула checkpatch, которая орфографию тоже проверят и не только.

                  WARNING: Possible repeated word: 'to'
                  #5626: FILE: drivers/block/blk-snap/snapimage.c:162:
                  + pr_err("Unable to to close snapshot image: private data is not initialized\n");


                  Так что можно многому поучиться.

                  Есть мнение, что модули для ядра можно писать на rust.

                  По поводу «супер гуру» — «не боги горшки обжигают», но уровень вхождения всё равно довольно высок.

                  «реально ли получать деньги за разработку и поддержку Linux?» — конечно, если вы работаете к примеру в redhat :). Остальных схем я не знаю, но мне очень интересно как расходуются средства спонсоров. Если кто знает — напишите.
                    0
                    «реально ли получать деньги за разработку и поддержку Linux?» — конечно, если вы работаете к примеру в redhat :). Остальных схем я не знаю, но мне очень интересно как расходуются средства спонсоров. Если кто знает — напишите.

                    Если фирма занимается производством железа на основе Linux например.
                    Причем отправлять свои фиксы в ядро выходит даже дешевле, нежели держать их у себя в своем репозитории.
                      +1
                      Есть такой момент. Я работаю именно так. По сути получая зарплату (в частности) за поддержку Linux (для нужд моей организации). И да, «протолкнуть» патч в mainline сильно лучше в плане отсутствия головной боли, чем перетаскивать его из версии в версию самостоятельно. Увы, но не со всеми железками так проходит. Как правило, железо собственной разработки никому кроме нас не интересно. Потому даже пытаться не стоит — не возьмут. Но эта тема уж больно обширна.

                      Увы, но мало кто заморачивается таким образом. Как правило берут разной степени устарелости ядро от производителя процессора или процессорного модуля. Потому даже сегодня не редкость в дикой природе ядра 2.6. Обидно. У меня на столе сегодня работающее 5.9. В производстве 4.19 (longterm). И было бы больше, если бы не специфические требования заказчика.
                  0
                  Допустим если решил посвятить себя этому, так как веб разработка приелась уже, реально ли получать деньги за разработку и поддержку Linux?

                  Да, если устроитесь в Red Hat или SUSE. Ну или в команду интела/нвидии/микрософта/Гугла/AMD/етц, отвечающую за поддержку драйверов.

                    0
                    вспоминая то, как в линукс работают драйвера для видеокарт nvidia, особенно вкупе с optimus, поперхнулся, читая ваш коммент)

                    п.с. они работают, да)) Это все хорошее, что можно сказать)
                      0
                      Тут вопрос что кому нужно — тот в то и вкладывает.

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

                      Рост Linux сейчас в остновном в облаках, в контейнерах, в телефонах, во встраиваемой технике, в области виртуализации.

                      Вот если продажи nvidea будут падать из-за того что их ПО плохо работает на популярной игровой платформе — сразу всё появится с блек-джеком и прочими прелестями :)
                    0
                    супер гуру программирования

                    Как правильно уже заметили, не надо быть супер-гуру для разработки в ядре. Но свои особенности есть. Ровно те же, что и в любой системной и низкоуровневой разработке. Самое главное в том, что тут нельзя падать и портить память. Нельзя надеяться, что при падении нагрузка уйдет на резервную ноду, а упавшая быстро перезапустится. Креш, дедлок, stall в ядре распространяется на всю систему, и встанет все. Этого не нужно бояться, просто стратегия "падаем в случае отказов" неприменима.


                    Мне с Python там делать нечего?

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


                    Но это все более специализированные случаи, у которых есть своя какая-то особая цель. А так вам нужен С. В ядре диалект 89 года, щедро приправленный gnu-расширениями, своя реализация libc. Но никакого C++. И это дает очень интересный эффект, с одной стороны порог входя в ядро высокий просто из-за его специфики, с другой стороны С — самый простой низкоуровневый язык, в нем нет каких-то вычурных конструкций, нет скрытого смысла за операциями, и он придерживает планку входа.


                    Если вы хотите посвятить себя системной разработке, то вы просто вынуждены изучить С, знать как его использовать и как отстрелить себе что-нибудь. Сейчас есть языки, где можно писать код безопаснее и не менее эффективно, тот же C++ или Rust, но 90% системного ПО уже написана и в большинстве своем там именно C. Его придется читать, понимать и изредка патчить.


                    реально ли получать деньги за разработку и поддержку Linux?

                    Реально. Но сложно, просто потому, что системной разработкой занимается кратно меньше компаний, чем тем же вебом. Именно в ядро лезут еще меньше компаний. Но они есть. И это не только гиганты вроде RedHat/Suse/Intel/AMD/Mellanox/FaceBook/etc. Но и мелкие компании тоже есть, одна из самых известных — bootlin, даже некоторые хостеры тоже ввязываются в разработку ядра. Работы больше чем кажется, но ее сложно отыскать.


                    Кстати, раз упомянул про Bootlin, очень советую их материалы и лабы для обучения разработке.

                    +1

                    Про debugging секцию хотелось бы добавить. Пугать ядро во время разработки — совершенно нормальное явление, но ядро падает целиком и остается только лог в консоли. Не всегда это удобно и не всегда этого достаточно. Зато есть просто прекрасные утилиты kdump и crash. Первая позволяет создать крашдамп, вторая — его проанализировать.


                    kdump настраивается один раз, но за него приходится платить некоторым количеством зарезервированной оперативки для хранения второго экземпляра ядра в памяти. Зато по наступлении креша дамп будет собран и система перезагрузится. Это полезно не только во время тестирования в виртуалке, но и при прогоне тестов на CI и в продакшене, когда сложно сказать, что именно триггернуло ошибку.


                    crash — утилита с набором команд, похожим на gdb.


                    Так вот, чтобы понять, в каком месте функции произошла ошибка, достаточно запустить дебагер с подгруженным в него модулем

                    Тоже самое можно сделать при помощи утилиты addr2line.

                      +1
                      Вообще в случае реального кейса собрать дамп ядра — это подвиг со стороны тех. поддержки. И даже со стороны отдела тестирования это необычная конфигурация машины. Так что часто приходится довольствоваться куском текста, который выплюнул сервак перед тем как повеситься. Так что kdump — это скорее механизм серьёзной отладки. Хотя на Red Hat и Fedora его обычно предлагают настроить при установке.

                      Ну и потом, это-ж "… для самых маленьких". Вообще, я бы и сам удовольствием почитал статью типа «Linux kernel development: отладка по взрослому». С perf-ом, KEDR-ом, удалённой отладкой по сети и прочее. Идею статьи дарю! Если кто реализует — киньте мне в личку :).
                        0
                        С perf-ом, KEDR-ом, удалённой отладкой по сети и прочее...


                        Любопытно было бы почитать. В далеком 2006'ом я занимался отладкой самых начальных этапов с GDB через последовательный порт. Если честно — не хочу. Это реально мазохизм. Полагаю, удаленная отладка по сети от такого сильно отличаться не будет. Да, по совести говоря, оно и не надо. Такие вещи нужны для реально новой платформы (допустим запустить Linux на каком-нить очередном Эльбрусе или чем-то подобном дико экзотическом). Как только ядро до определенного уровня прогрузилось можно успокаиваться и пользоваться более удобными инструментами. Той же отладочной информацией например. И да, netconsole частенько помогает.

                        Вообще было б интересно рассказать, допустим, про regmap. Крайне интересная (и удобная) подсистема для разработчиков драйверов. А сколько вариантов ждет перевода на современный лад? Так любимые самодельщиками датчики температуры на W1 давно просят перевода на Thermal. И дело-то в принципе не сложное. Сколько драйверов ждут не дождутся момента когда им наконец-то добавят нормальную возможность работы через device-tree (почти все последовательные флеши). Увы, чукча не писатель. Впрочем, ежели вдруг корону подхвачу… И то скорее всего некогда будет.

                        Очень хочется надеяться, что благодаря вашей статье хоть кто-то реально не сложные мелочи подправит. Строчка в резюме «коммитил в Linux» с указанием принятых коммитов — штука не лишняя. В ряде случаев даже глубокого знания С не надо. Просто сделать по образцу и подобию соседнего файла. И для таких вариантов статья ваша просто шикарна.
                      +3

                      Пока искал баг в usb hub, нашел баг в git. Оба патча приняли.

                        0

                        Вот так всегда оно и случается. Бабка за дедку, дедка за репку...


                        Пока разбирался, как поправить документацию (man) к пакетному менеджеру, выучил groff(7), и законтрибьютил в GNU.

                        0
                        Насчёт 80-ти символьных строк могу пояснить. Так удобнее работать в vim, открыв исходный код в нескольких вертикальных окнах (обычно два на ноутбуке и три — на большом мониторе). Когда текстовый редактор автоматически переносит длинные строки, то получается мешанина, у человека форматирование получается лучше.
                          0

                          Это кому как. У меня легко влезут три окна вряд по 160 символов в строке у каждого, и будет комфортно читать, вопреки всяким исследованиям которые утверждают что длинные строки хуже воспринимаются (да, хуже если глаз не видит всю строку сразу, но не более того).


                          Но вот то что из-за несколько длинных идентификаторов не всегда удаётся влезть в 80 символов — явно очень неудобно, и это с учётом того что времена терминалов низкого разрешения уже почти канули в лету. Хотя бы 120-140 было бы норм, но почему-то многие проекты (включая гугла) настаивают на 80, причём часто мотивировка в духе "у нас есть несколько человек у кого нет хороших мониторов, им неудобно".

                            0
                            Не то что нет хороших мониторов, а реально есть люди, программирующие на 13-ти дюймовых ноутбуках. Их легче таскать и постоянного рабочего с большим монитором у них нет.
                              0
                              Но вот то что из-за несколько длинных идентификаторов не всегда удаётся влезть в 80 символов — явно очень неудобно


                              На вкус и цвет… У меня, например, кровь из глаз льется если смотреть код, написанный подобным образом. Посмотрите сами. Масляное масло умасленное слоем масляного масла. Все прелести многословности. И STM32 и FreeRTOS. Так что субъективизм. Просто людей со взглядами как у меня среди разработчиков ядра больше.

                              А про 80 символов в строке (78 реально checkpatch ругался — чтоб 80 у diff'а было)… Вопрос привычки. Впрочем, длинное выражение в if'е всегда головная боль. Только самым правильным решением обычно будет вынести его из if'а. Понятность кода от этого обычно только выигрывает.

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

                          Самое читаемое