Программирования для linux примеры

Пишем простой модуль ядра Linux

Захват Золотого Кольца-0

Linux предоставляет мощный и обширный API для приложений, но иногда его недостаточно. Для взаимодействия с оборудованием или осуществления операций с доступом к привилегированной информации в системе нужен драйвер ядра.

Модуль ядра Linux — это скомпилированный двоичный код, который вставляется непосредственно в ядро Linux, работая в кольце 0, внутреннем и наименее защищённом кольце выполнения команд в процессоре x86–64. Здесь код исполняется совершенно без всяких проверок, но зато на невероятной скорости и с доступом к любым ресурсам системы.

Не для простых смертных

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

Ситуация ухудшается тем, что проблема необязательно проявляется сразу. Если модуль вешает систему сразу после загрузки, то это наилучший сценарий сбоя. Чем больше там кода, тем выше риск бесконечных циклов и утечек памяти. Если вы неосторожны, то проблемы станут постепенно нарастать по мере работы машины. В конце концов важные структуры данных и даже буфера могут быть перезаписаны.

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

У вас также нет доступа к стандартной библиотеке. Хотя ядро предоставляет некоторые функции вроде printk (которая служит заменой printf ) и kmalloc (работает похоже на malloc ), в основном вы остаётесь наедине с железом. Вдобавок, после выгрузки модуля следует полностью почистить за собой. Здесь нет сборки мусора.

Необходимые компоненты

Прежде чем начать, следует убедиться в наличии всех необходимых инструментов для работы. Самое главное, нужна машина под Linux. Знаю, это неожиданно! Хотя подойдёт любой дистрибутив Linux, в этом примере я использую Ubuntu 16.04 LTS, так что в случае использования других дистрибутивов может понадобиться слегка изменить команды установки.

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

И наконец, нужно хотя бы немного знать C. Рабочая среда C++ слишком велика для ядра, так что необходимо писать на чистом голом C. Для взаимодействия с оборудованием не помешает и некоторое знание ассемблера.

Установка среды разработки

На Ubuntu нужно запустить:

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

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

Начинаем

Приступим к написанию кода. Подготовим нашу среду:

Запустите любимый редактор (в моём случае это vim) и создайте файл lkm_example.c следующего содержания:

Мы сконструировали самый простой возможный модуль, рассмотрим подробнее самые важные его части:

• В include перечислены файлы заголовков, необходимые для разработки ядра Linux.
• В MODULE_LICENSE можно установить разные значения, в зависимости от лицензии модуля. Для просмотра полного списка запустите:

Мы устанавливаем init (загрузка) и exit (выгрузка) как статические функции, которые возвращают целые числа.

Обратите внимание на использование printk вместо printf . Также параметры printk отличаются от printf . Например, флаг KERN_INFO для объявления приоритета журналирования для конкретной строки указывается без запятой. Ядро разбирается с этими вещами внутри функции printk для экономии памяти стека.

В конце файла можно вызвать module_init и module_exit и указать функции загрузки и выгрузки. Это даёт возможность произвольного именования функций.

Впрочем, пока мы не можем скомпилировать этот файл. Нужен Makefile. Такого базового примера пока достаточно. Обратите внимание, что make очень привередлив к пробелам и табам, так что убедитесь, что используете табы вместо пробелов где положено.

Если мы запускаем make , он должен успешно скомпилировать наш модуль. Результатом станет файл lkm_example.ko . Если выскакивают какие-то ошибки, проверьте, что кавычки в исходном коде установлены корректно, а не случайно в кодировке UTF-8.

Теперь можно внедрить модуль и проверить его. Для этого запускаем:

Если всё нормально, то вы ничего не увидите. Функция printk обеспечивает выдачу не в консоль, а в журнал ядра. Для просмотра нужно запустить:

Вы должны увидеть строку “Hello, World!” с меткой времени в начале. Это значит, что наш модуль ядра загрузился и успешно сделал запись в журнал ядра. Мы можем также проверить, что модуль ещё в памяти:

Для удаления модуля запускаем:

Если вы снова запустите dmesg, то увидите в журнале запись “Goodbye, World!”. Можно снова запустить lsmod и убедиться, что модуль выгрузился.

Как видите, эта процедура тестирования слегка утомительна, но её можно автоматизировать, добавив:

в конце Makefile, а потом запустив:

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

Теперь у нас есть полностью функциональный, хотя и абсолютно тривиальный модуль ядра!

Немного интереснее

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

Поскольку приложениям запрещено просматривать память в пространстве ядра, для взаимодействия с ними приходится использовать API. Хотя технически есть несколько способов такого взаимодействия, наиболее привычный — создание файла устройства.

Вероятно, раньше вы уже имели дело с файлами устройств. Команды с упоминанием /dev/zero , /dev/null и тому подобного взаимодействуют с устройствами “zero” и “null”, которые возвращают ожидаемые значения.

В нашем примере мы возвращаем “Hello, World”. Хотя это не особенно полезная функция для приложений, она всё равно демонстрирует процесс взаимодействия с приложением через файл устройства.

Вот полный листинг:

Тестирование улучшенного примера

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

Теперь после запуска make test вы увидите выдачу старшего номера устройства. В нашем примере его автоматически присваивает ядро. Однако этот номер нужен для создания нового устройства.

Возьмите номер, полученный в результате выполнения make test , и используйте его для создания файла устройства, чтобы можно было установить коммуникацию с нашим модулем ядра из пространства пользователя.

(в этом примере замените MAJOR значением, полученным в результате выполнения make test или dmesg )

Параметр c в команде mknod говорит mknod, что нам нужно создать файл символьного устройства.

Теперь мы можем получить содержимое с устройства:

или даже через команду dd :

Вы также можете получить доступ к этому файлу из приложений. Это необязательно должны быть скомпилированные приложения — даже у скриптов Python, Ruby и PHP есть доступ к этим данным.

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

Заключение

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

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

Источник

5 причин, по которым я люблю программировать в Linux

Linux — это отличная платформа для занятий программированием. На нашей стороне — логичность, высокая эффективность, лёгкость работы с исходным кодом.

В 2021 году Linux выглядит как никогда привлекательно. Я собираюсь написать материалы, в которых расскажу о 21 способе использования Linux. А в этой статье я хочу поговорить о том, почему так много программистов выбирают Linux.

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

Оказалось, что Linux — это отличная платформа для программистов, и для начинающих, и для опытных. Нельзя сказать, что Linux необходима для того, чтобы писать программы. Успешные разработчики пользуются самыми разными платформами. Но у Linux есть много такого, что она может предложить разработчикам. Кое о чём из этого я и хочу рассказать.

1. Логичность Linux

Linux построена вокруг идеи автоматизации. Основные приложения Linux совершенно осознанно сделаны такими, чтобы их можно было бы, как минимум, запустить из терминала, указав дополнительные опции. А часто их можно и полностью использовать тоже из терминала. Эту идею иногда ошибочно считают чем-то вроде примитивной модели организации вычислений, так как существует распространённое (и неправильное) мнение о том, что писать программы, работающие из терминала, это значит — прилагать абсолютный минимума усилий к тому, чтобы получить работающее приложение. Это — печальный результат непонимания того, как работает программный код, но многие из нас периодически страдают таким вот непониманием. Мы думаем, что больше — это всегда лучше, поэтому приложение, содержащее 1000 строк кода должно быть в 100 раз лучше, чем приложение, содержащее 10 строк кода. Так? Но правда заключается в том, что, при прочих равных условиях, лучше выбрать приложение, отличающееся большей гибкостью, при этом то, из скольких строк кода оно состоит, значения не имеет.

В Linux решение некоей задачи вручную может занять, например, час. То же самое можно, воспользовавшись подходящими инструментами командной строки, сделать буквально за минуту, а возможно — и за меньшее время, если прибегнуть к GNU Parallel. Для того чтобы к этому привыкнуть, нужно определённым образом изменить взгляд на то, как именно работают компьютеры, нужно научиться мыслить не так, как прежде. Например, если задача заключается в том, чтобы добавить к 30 PDF-файлам обложки, можно решить, что приемлемая последовательность действий будет выглядеть так:

1. Открыть PDF-файл в редакторе.
2. Открыть файл с обложкой.
3. Присоединить PDF-файл к файлу с обложкой.
4. Сохранить полученный документ в виде нового PDF-файла.
5. Повторить эти действия при обработке остальных старых файлов (а вот новые файлы, полученные из старых, обрабатывать уже не нужно).

Эта последовательность действий вполне согласуется со здравым смыслом, и хотя в ней много неприятных повторений, она позволяет достичь цели. В Linux, правда, можно организовать работу гораздо разумнее. Процесс размышлений над этой задачей, учитывающий возможности Linux, похож на процесс размышлений над «ручным» способом решения задачи. А именно, всё начинается с поиска последовательности действий, необходимых для получения нужного результата. Проведя некоторые изыскания, можно узнать о команде pdftk-java , а потом выйти на простое решение:

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

Тут представлен подход к размышлениям над задачами, несколько отличающийся от обычного, так как «код», который мы пишем, обрабатывает данные не так, как мы привыкли. Обычно мы ограничены представлениями о последовательной ручной обработке данных. Но выход за границы старых представлений важен для того чтобы позже писать соответствующий код. А побочным полезным эффектом такого «выхода» является получение возможности писать более эффективные программы, чем раньше.

2. Возможности по управлению связями кода

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

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

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

Надо признать, подобным вещам нельзя научиться, просто пользуясь Linux. Можно счастливо писать код в хорошей IDE и никогда даже не задумываться о том, какая версия некоей библиотеки была установлена, или о том, где именно находятся какие-то заголовочные файлы. Но Linux ничего не скрывает от программиста. Очень просто углубиться в недра системы, найти в ней то, что нужно, и прочитать соответствующий код.

3. Удобство работы с существующим кодом

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

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

4. Прямой доступ к периферии

Я, после того, как разрабатывал на Linux программы для медиакомпаний, иногда принимаю как должное возможность доступа к периферийным устройствам. Например, при подключении к Linux-компьютеру видеокамеры можно загрузить входящие данные из /dev/video0 или из подобного устройства. Всё что нужно, можно найти в /dev , и это — всегда кратчайший путь из точки A в точку B.

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

5. Хорошо продуманные абстракции

Linux, в то же время, даёт нам и разумный набор слоёв абстракции, применимых в ситуациях, когда прямой доступ к чему либо или ручное написание некоего кода может вылиться в больший объём работы, чем тот, к которому готов программист. Много удобных инструментов можно найти в Qt и Java, есть целые стеки вспомогательных технологий, вроде Pulse Audio, Pipewire и gstreamer. Linux стремится к тому, чтобы её пользователи могли бы заниматься программированием, и не скрывает этого.

Итоги

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

Какой ОС вы пользуетесь при написании программ?

Источник