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

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

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

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

P.S.
А его решение выдумать свой компьютер было абсолютно правильным. Черт возьми, он «еще тогда» предвидел появление JAVA ;-)
По поводу яда в статье не согласен — местами выглядит, скорее, как сарказм.
Хорошо. Согласен. Перестарался с оценкой. Виноват. Наверное потому, что сам все вокруг ядом поливаю, когда с CodingCtyle воюю. Увы, поправит уже не могу.
Но, на самом деле, CodingStyle вопрос привычки. С третьего раза уже проблем не возникает. Но CodingStyle это ерунда. А вот обосновать свои код… Почему именно так, а не иначе… Особенно когда он на стыке двух подсистем (а разве бывает по другому)… Ладно, это пройти надо. Однострочники и исправлением опечаток или откровенных коясков проходят легко. А вот драйвер под железку… Тут временами помимо техники еще и дипломатия нужна.
Спасибо, интересный пост, я и вправду думал, что этим занимаются супер гуру программирования и даже как то не пытался узнавать, куда мне до них. Возник такой вопрос, я так понимаю язык программирования используемый в разработке ядра — C/C++? Мне с Python там делать нечего? Просто слышал что некоторые компоненты Linux, не ядра, а в целом системы написаны Python. И еще вопрос реально ли зарабатывать? Допустим если решил посвятить себя этому, так как веб разработка приелась уже, реально ли получать деньги за разработку и поддержку Linux?
Все ядро использует только C 1989 года. И немного ассемблера.
Есть в ядре директория 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 :). Остальных схем я не знаю, но мне очень интересно как расходуются средства спонсоров. Если кто знает — напишите.
«реально ли получать деньги за разработку и поддержку Linux?» — конечно, если вы работаете к примеру в redhat :). Остальных схем я не знаю, но мне очень интересно как расходуются средства спонсоров. Если кто знает — напишите.

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

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

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

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

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

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

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

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

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


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

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


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


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


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

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


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

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


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


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


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

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

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

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


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

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

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

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

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


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

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

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


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

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


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

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

Информация

Дата основания
Местоположение
Швейцария
Сайт
veeam.com
Численность
1 001–5 000 человек
Дата регистрации

Блог на Хабре