Записки программиста

По традиции, при изучении нового языка программирования первой пишется программа, показывающая сообщение «Hello world». В мире электроники есть аналогичная традиция, только вместо вывода сообщения нужно помигать светодиодом. При изучении модулей ядра Linux (часть 1, часть 2) мы как-то обошли стороной этот важнейший этап. Пришло время исправиться, и написать модуль, мигающий светодиодом.

Бывает так, что ошибка в коде воспроизводится лишь при определенном стечение обстоятельств. Эти обстоятельства могут быть довольно сложными, особенно если приложение распределенное и каждый его экземпляр состоит из N процессов. Подцепиться отладчиком к правильному процессу в правильный момент времени практически невозможно. В подобных случаях я использую один незамысловатый прием, речь о котором и пойдет далее.

Недавно мы научились основам написания модулей ядра Linux. Впрочем, рассмотренные тогда примеры были совсем простые, можно даже сказать, что игрушечные. Сегодня мы напишем модуль поинтереснее. Он будет создавать в каталоге /dev символьное устройство, с которым можно взаимодействовать из юзерспейса.

Вопрос ковыряния ядра Linux впервые поднимался в этом блоге еще в далеком 2016-м году. Мы научились собирать ядро из исходников и цепляться к нему отладчиком. Но на этом все и заглохло. Тогда найти актуальную информацию по разработке ядерного кода в Linux, да еще и в удобоваримом виде, было проблемой. Я предпочел дождаться появления свежих книг по теме, а пока заняться изучением чего-то другого. И вот, спустя пять лет, такие книги были опубликованы. В связи с чем я решил попробовать написать пару модулей ядра, и посмотреть, как пойдет.

Ранее в этом блоге многократно упоминались чипы производства компании FTDI, такие, как FT232RL и FT2232HL — смотри заметки раз, два и далее по ссылкам. В частности, было сказано, что этими чипами можно управлять с компьютера, что позволяет использовать их, например, в качестве программатора. При этом чипы FTDI поддерживают несколько режимов работы. Далее будет рассмотрен, пожалуй, самый простой режим под названием bitbang.

Народная мудрость гласит, что правильно сделать шифрование в своем приложении крайне непросто. Свой велосипед почти наверняка будет содержать крайне неочевидные простому смертному дефекты, которые последние 20 лет исправлялись в существующих криптографических пакетах. Поэтому в любой непонятной ситуации нужно использовать готовые наработки, такие, как OpenSSL, LibreSSL, GPG или OTR. Но что делать, если для вашей конкретной задачи нет готового решения? Например, вы реализуете шифрование на уровне страниц для вашей СУБД, или вам нужно шифровать короткие сообщения, передаваемые с помощью NRF24L01 в самопальном IoT-проекте. В данном случае у вас действительно может не быть большого выбора. Но, по крайней мере, вы можете уменьшить шанс появления существенных дефектов в вашем приложении, используя проверенные временем алгоритмы и режимы шифрования.

Благодаря наличию исключений, язык C++ позволяет разделить основную логику приложения и обработку ошибок, не мешая их в одну кучу. Что есть очень хорошо. Однако теперь по коду нельзя с уверенностью сказать, где может быть прервано его исполнение. Отсюда возникает опасность утечки ресурсов. Проблема эта решается при помощи деструкторов и идиомы RAII. Впрочем, придерживаться этой идиомы становится проблематично при использовании указателей. Особенно при использовании их не как членов класса, а просто как переменных в методах. На наше с вами счастье, в стандартной библиотеке языка есть умные указатели (smart pointers), придуманные именно для этого случая. Поскольку на C++ я пишу не регулярно, то иногда забываю некоторые нюансы использования умных указателей, в связи с чем решил вот набросать небольшую шпаргалку.

Программисты, как правило, не очень любят писать тесты. Но куда сильнее они не любят писать документацию. Тесты хотя бы представляют собой программы, а документация — это что? Просто текст. Вот пусть кто-нибудь другой его и пишет, технические писатели например! Впрочем, если речь идет не о пользовательской документации, а об описании классов и методов, предназначенном для других программистов, тут откосить вряд ли удастся. К счастью, есть Doxygen, способный существенно помочь со столь неприятной для многих работой.

Помните, как когда-то мы писали простой TCP-сервер на C, а потом разбирали типичные ошибки? Описанный в этих статьях подход прекрасно работает, но только до тех пор, пока количество одновременно обслуживаемых соединений невелико — условно, пара сотен. Если же вам нужно обслуживать 10 или 50 тысяч соединений (так называемая проблема C10K), программу нужно писать совершенно иначе. Давайте разберемся, почему так, и как же нужно писать.

Некоторое время назад мы научились сериализовывать классы в языке C++ в формат JSON при помощи библиотеки RapidJSON. Формат JSON хорош тем, что он текстовый, а значит может быть прочитан человеком, что удобно при той же отладке. Плох же JSON тем, что никак не проверяет соответствие данных какой-либо схеме. Кроме того, этот формат крайне неэффективен, как минимум, потому что сериализованные объекты хранят имена всех ключей. Наконец, при работе с RapidJSON нам пришлось руками писать методы toJSON и fromJSON. Всех этих недостатков лишен формат Protobuf, с которым мы сегодня и познакомимся.