Comments 28
Все остальное тоже. Дельная статья. Правда яду многовато. Так и брызжет во все стороны. Но лучше здесь, чем в ответах списка рассылки. Там яду будет еще больше.
А при ответах в списке рассылок, вообще взял за правило отвечать только на следующий день. Токсичность там вообще ни к чему.
Картинка — работа наших дизайнеров — так что наверное будет собственностью. Хотя лично меня зелёные губы немного пугают.
А картинка… Мне первых «Людей в черном» напомнила. Там правда маленькая девочка с учебником ядерной физики была, но… «Искусство программирования» местами пострашнее будет.
Впрочем, у меня есть индульгенция от автора. Он сам разрешил так читать его книгу. Дай бог здоровья Деду Кнуту. И, безусловно, ждем следующего тома. А то «ремеслом программирования» все полки завалены, а вот «искусство...» это только у него.
P.S.
А его решение выдумать свой компьютер было абсолютно правильным. Черт возьми, он «еще тогда» предвидел появление JAVA ;-)
Если инопланетное вторжение дотянулось до стражей ночи (есть перевод, но оригинал круче) с томиком Кнута, то нам уже крышка.
Но, на самом деле, CodingStyle вопрос привычки. С третьего раза уже проблем не возникает. Но CodingStyle это ерунда. А вот обосновать свои код… Почему именно так, а не иначе… Особенно когда он на стыке двух подсистем (а разве бывает по другому)… Ладно, это пройти надо. Однострочники и исправлением опечаток или откровенных коясков проходят легко. А вот драйвер под железку… Тут временами помимо техники еще и дипломатия нужна.
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 например.
Причем отправлять свои фиксы в ядро выходит даже дешевле, нежели держать их у себя в своем репозитории.
Увы, но мало кто заморачивается таким образом. Как правило берут разной степени устарелости ядро от производителя процессора или процессорного модуля. Потому даже сегодня не редкость в дикой природе ядра 2.6. Обидно. У меня на столе сегодня работающее 5.9. В производстве 4.19 (longterm). И было бы больше, если бы не специфические требования заказчика.
п.с. они работают, да)) Это все хорошее, что можно сказать)
Всё же несморя на значительные усилия со стороны многих разработчиков, 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.
Ну и потом, это-ж "… для самых маленьких". Вообще, я бы и сам удовольствием почитал статью типа «Linux kernel development: отладка по взрослому». С perf-ом, KEDR-ом, удалённой отладкой по сети и прочее. Идею статьи дарю! Если кто реализует — киньте мне в личку :).
С perf-ом, KEDR-ом, удалённой отладкой по сети и прочее...
Любопытно было бы почитать. В далеком 2006'ом я занимался отладкой самых начальных этапов с GDB через последовательный порт. Если честно — не хочу. Это реально мазохизм. Полагаю, удаленная отладка по сети от такого сильно отличаться не будет. Да, по совести говоря, оно и не надо. Такие вещи нужны для реально новой платформы (допустим запустить Linux на каком-нить очередном Эльбрусе или чем-то подобном дико экзотическом). Как только ядро до определенного уровня прогрузилось можно успокаиваться и пользоваться более удобными инструментами. Той же отладочной информацией например. И да, netconsole частенько помогает.
Вообще было б интересно рассказать, допустим, про regmap. Крайне интересная (и удобная) подсистема для разработчиков драйверов. А сколько вариантов ждет перевода на современный лад? Так любимые самодельщиками датчики температуры на W1 давно просят перевода на Thermal. И дело-то в принципе не сложное. Сколько драйверов ждут не дождутся момента когда им наконец-то добавят нормальную возможность работы через device-tree (почти все последовательные флеши). Увы, чукча не писатель. Впрочем, ежели вдруг корону подхвачу… И то скорее всего некогда будет.
Очень хочется надеяться, что благодаря вашей статье хоть кто-то реально не сложные мелочи подправит. Строчка в резюме «коммитил в Linux» с указанием принятых коммитов — штука не лишняя. В ряде случаев даже глубокого знания С не надо. Просто сделать по образцу и подобию соседнего файла. И для таких вариантов статья ваша просто шикарна.
Пока искал баг в usb hub, нашел баг в git. Оба патча приняли.
Вот так всегда оно и случается. Бабка за дедку, дедка за репку...
Пока разбирался, как поправить документацию (man) к пакетному менеджеру, выучил groff(7), и законтрибьютил в GNU.
Это кому как. У меня легко влезут три окна вряд по 160 символов в строке у каждого, и будет комфортно читать, вопреки всяким исследованиям которые утверждают что длинные строки хуже воспринимаются (да, хуже если глаз не видит всю строку сразу, но не более того).
Но вот то что из-за несколько длинных идентификаторов не всегда удаётся влезть в 80 символов — явно очень неудобно, и это с учётом того что времена терминалов низкого разрешения уже почти канули в лету. Хотя бы 120-140 было бы норм, но почему-то многие проекты (включая гугла) настаивают на 80, причём часто мотивировка в духе "у нас есть несколько человек у кого нет хороших мониторов, им неудобно".
Но вот то что из-за несколько длинных идентификаторов не всегда удаётся влезть в 80 символов — явно очень неудобно
На вкус и цвет… У меня, например, кровь из глаз льется если смотреть код, написанный подобным образом. Посмотрите сами. Масляное масло умасленное слоем масляного масла. Все прелести многословности. И STM32 и FreeRTOS. Так что субъективизм. Просто людей со взглядами как у меня среди разработчиков ядра больше.
А про 80 символов в строке (78 реально checkpatch ругался — чтоб 80 у diff'а было)… Вопрос привычки. Впрочем, длинное выражение в if'е всегда головная боль. Только самым правильным решением обычно будет вынести его из if'а. Понятность кода от этого обычно только выигрывает.
Linux kernel development для самых маленьких