Как написать драйвер для принтера под linux

Драйверы устройств в Linux

Часть 2: Пишем в классе наш первый драйвер для Linux

Оригинал: «Device Drivers, Part 2: Writing Your First Linux Driver in the Classroom»
Автор: Anil Kumar Pugalia
Дата публикации: December 1, 2010
Перевод: Н.Ромоданов
Дата перевода: июнь 2012 г.

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

Светлана и Пагс добрались в свой класс с опозданием и увидели, что их профессор уже начал читать лекцию. Светлана робко попросила разрешения войти. Раздраженный профессор Гопи ответил: «Входите! Вы, друзья, опять сегодня опоздали, и по какой причине»?

Пагс поспешно ответил, что они обсуждали именно ту тему, которую сегодня изучают в классе — драйверы устройств в Linux. Пагс был более, чем счастлив, когда профессор сказал: «Хорошо! Тогда что-нибудь скажите о динамической загрузке в Linux. Если вы справитесь, то я прощу вас обоих!». Пагс знал, что один из способов сделать профессора счастливым, это — покритиковать Windows.

Он объяснил: «Как известно, при обычной установке драйверов в Windows для того, чтобы их активировать, необходимо перезагрузить систему. А если это, предположим, действительно неприемлемо в случае, если это нужно делать на сервере? Вот где выигрывает Linux. В Linux можно загружать и выгружать драйверы на лету, и это активно используется сразу после загрузки системы. Кроме того, драйвер мгновенно отключается после его выгрузки. Это называется динамической загрузкой и выгрузкой драйверов в Linux «.

Это впечатлило профессора. «Хорошо! Идите на свои места, но больше не опаздывайте». Профессор продолжил лекцию: «Теперь, когда вы уже знаете, что такое динамическая загрузка и выгрузка драйверов, я, прежде, чем мы перейдем к написанию нашего первого драйверов, покажу вам, как загружать и выгружать драйвера».

Динамическая загрузка драйверов

Эти динамически загружаемые драйвера чаще всего называют модулями, которые собираются в виде отдельных модулей с расширением .ko (объект ядра). В каждой системе Linux в корне файловой системы (/) есть стандартное место для всех предварительно собранных модулей. Они организованы аналогично древовидной структуре исходных кодов ядра и находятся в директории /lib/modules/ /kernel , где результат вывода системной команды uname -r (см.рис.1).

Рис.1: Предварительно собранные модули Linux

Чтобы динамически загружать и выгружать драйверы, воспользуйтесь следующими командами, которые находятся в директории /sbin и должны выполняться с привилегиями пользователя root:

• lsmod — список модулей, загруженных в текущий момент
• insmod — добавление / загрузка указанного файла модуля
• modprobe — добавление / загрузка модуля вместе со всеми его зависимостями
• rmmod — удаление / выгрузка модуля

Давайте в качестве примера рассмотрим соответствующие драйвера файловой системы FAT. На рис.2 показан весь процесс нашего эксперимента. Файлы с модулями будут fat.ko , vfat.ko и т.д., находящиеся в директории fat (в vfat для старых версий ядра) в /lib/modules/`uname -r`/kernel/fs . Если они представлены в сжатом формате .gz , вам нужно будет распаковать их с помощью команды gunzip , прежде чем вы сможете выполнить операцию insmod .

Рис.2: Операции с модулями Linux

Модуль vfat зависит от модуля fat , так что первым должен быть загружен модуль fat.ko . Чтобы автоматически выполнить распаковку и загрузку зависимостей, воспользуйтесь командой modprobe . Обратите внимание, что когда вы пользуетесь командой modprobe , вы не должны в имени модуля указывать расширение .ko . Команда rmmod используется для выгрузки модулей.

Наш первый драйвер для Linux

Перед тем, как написать наш первый драйвер, давайте рассмотрим некоторые понятия. Драйвер никогда не работает сам по себе. Он похож на библиотеку, загружаемую из-за функций, которые будут вызваны из работающего приложения. Он написан на языке C, но в нем отсутствует функция main() . Кроме того, он будет загружаться / компоноваться с ядром, поэтому он должен компилироваться аналогично тому, как было откомпилировано ядро, и вы можете в качестве заголовочных файлов использовать только те, что есть в исходном коде ядра, а не из стандартного директория /usr/include .

Интересный факт, касающийся ядра, это то, что оно, как мы видим даже на примере нашего первого драйвера, представляет собой объектно-ориентированную реализацию на языке C. В любом драйвере есть конструктор и деструктор. Когда модуль успешно загружается в ядро, то вызывается конструктор модуля, а дескруктор модуля вызывается, когда команде rmmod удается успешно выгрузить модуль. Это в драйвере две обычные функции, разве что они называются init и exit, соответственно, и вызываются с помощью макросов module_init() и module_exit() , которые определены в заголовков ядра module.h .

С учетом вышесказанного это полный код нашего первого драйвера; назовем его ofd.c. Обратите внимание, что отсутствует заголовок stdio.h (заголовок пользовательского пространства), вместо него мы используем аналог kernel.h (заголовок пространства ядра). Функция printk() эквивалентна функции printf() . Кроме того, для обеспечения совместимости версии модуля с ядром, в которое будет загружен модуль, добавлен заголовок version.h . С помощью макроса MODULE_* заполняется информация, относящаяся к модулю, которая будет использована как «подпись» модуля.

Сборка нашего первого драйвера

Т.к. у нас есть код на языке C, настало время его скомпилировать и создать файл модуля ofd.ko . Для этого мы используем систему сборки ядра. В приведенном ниже файле Makefile происходит обращение к системе сборки ядра из исходных кодов, а файл Makefile ядра, в свою очередь, обращается к файлу Makefile нашего нового драйвера с тем, чтобы собрать драйвер.

Чтобы собрать драйвер для Linux, у вас в системе должен быть исходный код ядра (или, по крайней мере, заголовки ядра). Предполагается, что исходный код ядра будет находиться в директории /usr/src/linux . Если в вашей системе он находится в каком-нибудь другом месте, то укажите это место в переменной KERNEL_SOURCE в файле Makefile .

Когда есть код на языке C ( ofd.c ) и готов файл Makefile , то все, что нам нужно сделать для сборки нашего первого драйвера ( ofd.ko ), это вызвать команду make .

Подведем итог

Как только у нас будет файл ofd.ko , мы в роли пользователя root или с помощью команды sudo выполним обычные действия.

Команда lsmod должна вам сообщить о том, что драйвер ofd загружен.

Пока студенты экспериментировали со своим первым модулем, прозвенел звонок, сообщивший об окончании урока. Профессор Гопи подвел итог: «В настоящий момент мы не увидели ничего, кроме того, что модуль lsmod сообщил о загрузке драйвера. Куда выводит информацию команда printk ? Найдите это самостоятельно на лабораторных занятиях и познакомьте меня с своими выводами. Также учтите, что наш первый драйвер будет шаблоном для любого драйвера, который можно написать для Linux. Написание специализированных драйверов это всего лишь вопрос о том, чем будет заполнен конструктор и деструктор драйвера. Поэтому дальнейшее изучение будет представлять собой расширение данного драйвера с целью получить драйвер с конкретными функциональными возможностями».

Источник

[Реквест подсказки]Самостоятельное написание драйвера под linux

Здравствуйте! Некое время назад попал ко мне замечательный модем Г-Link DU-562M, который на офсайте имеет драйвер под виндовс, который на офсайте производителя чипа (conexant) имеет ссылку на сайт с платным закрытым драйвером под линукс (или со «свободными» 28,8 Кб/сек). И хоть lsusb его показывает, как устройство он работать не хочет.

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

>1. Прочитать url(). Там описание типов потоков данных в usb и как что робит

2. Вызубрить учебник book() — там нет лишней информации, которая будет занимать некоторое время твоего обучения..

3. Вот учебник по assembler’у — ass(), там в пятой главе как раз обращения к устройствам и выделение памяти.

4. Если что в личку написал свой мыл, можешь задавать вопросы, потому что мне тоже интересно развитие всего что с СПО связано(или иные мотивы, либо без них :)).

Из знаний: php на уровне «могу сайт сбацать». mYsql — «могу в phpMA войти и таблицу создать». bash — «могу скрипт создать, сам все проверит, обновит, логи покажет и удалит хоум, если нужно». В профессиональном программировании — «0.1».

http://lwn.net/Kernel/LDD3/
Сам правда драйвера не писал, но хочется, а времени нет.

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

При наличии документации все довольно просто, можно даже LDD особо не читать, достаточно найти пимерно такой-же драйвер и перезаточить его под конкретное железо.

Си не знаете? Тогда стоит прочитать Брайан Керниган, Деннис Ритчи «Язык программирования C». В любом случае не повредит.

И ищите спеки на модем. Если их нет, то придется слушать юсб-трафик и реверс-инженерить. Возможно, что это будет сложновато.

Я хочу написать драйвер для своего принтера canon IP1700. Где мне искать документацию к нему?

При современных ценах на железо, нет профита в написании драйверов для Г-поделий производителей, не дающих спеки на свои Г-поделки.

Хочешь скилл прокачать, напиши что-то полезное, а Г-поделку отдай врагам.

> Вот учебник по assembler’у — ass(), там в пятой главе как раз отлов констант вроде 28800 и вызовов sleep, как все это править или заменять на nop.

Самому бы такую книжку

Два месяца назад начал писать драйвер для USB сканера Canon LiDE 70 (далее csl70). До этого имел нормальный опыт программирования только на Делфях под окнами (собственно писать начал, как только на линукс и перешёл). Дрова пришлось писать на основе логов УСБ сниффера. Сейчас дописываю фрон-энд.

Как у меня всё шло:
1. Разобраться как робит УСБ.
2. Несколько разных логов сниффером захватываешь. Пишешь прогу которая преобразует логи в читаемый вид.
Можно пробовать данные из лога передавать на устройство (для сканера — просто, для модема — х3, т.к. ответная реакция может быть иная, в зависимости от ответа какого-нибудь провайдера)
Ищешь закономерности в логе. Данные которые идут через УСБ могут представлять собой команды, данные, либо и то и другое одновременно в одном пакете. Например для csl70 данные передаваемые через УСБ в BULK пакете «01 46 01 00» означают читать(01) значение регистра 46. «00 46 01 00 22» — записать(00) в 46-ой регистр значение 22. Т.е. сначала надо разобраться со смыслом передаваемых пакетов.
Далее написал «детранслятор», который преобразует логи в вид наподобие
..
getreg(46)
setreg(46,22)
..
По сути создаешь свой мини-скриптовый язык.
3. Далее ищешь крупные закономерности. Например серия записей в регистры определяет ширину сканируемой картинки, или адрес в ОЗУ сканера для чтения\записси данных.
Улучшаешь детранслятор, чтоб он определял эти крупные функции.
И так до тех пор, пока всё не будет удобночитаемо.
Можно уже экспериментировать со значениями передаваемых данных, и последовательностью передаваемых команд.

4. Когда всё ясно, и больше узнавать НЕ`ЧЕГО, то можно скрипты перетаскивать на с \ с++ или др. язык.

PS. Использовать лучше libusb1, чтоб с ядром не заморачиваться. Видмо придётся ещё разбираться с созданием всяких интерфесов\устройств — tun и т.п. — в этом не разбираюсь, подсказать не могу. Если доки на модем найдутся — то отлично.

Спасибо! Не ожидал что столько полезной информации без троллинга здесь можно найти.. Гугл однообразные ответы без субъективной практики дает, в нем подобного искать — замучаешься. Еще раз спасибо! Теперь есть стимул.

А насчет Г-поделок: устройство есть, почему оно должно место в кладовке занимать? Менять железо из-за особенностей ПО — виндовс вей с их запросами на ОЗУ и место под солнцем на жестком, не так ли?

> почему оно должно место в кладовке занимать?

Избавляйся от плюшкинизма, подарить врагу — самое оно

Источник

Как написать свой первый Linux device driver

Здравствуйте, дорогие хабрачитатели.

Цель данной статьи — показать принцип реализации драйверов устройств в системе Linux, на примере простого символьного драйвера.

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

Это моя первая статья, пожалуйста не судите строго!

Получилось слишком много букв, поэтому я принял решение разделить статью на три части:

Часть 1 — Введение, инициализация и очистка модуля ядра.
Часть 2 — Функции open, read, write и trim.
Часть 3 — Пишем Makefile и тестируем устройство.

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

Подготовительные работы

Спасибо Kolyuchkin за уточнения.

Символьный драйвер (Char driver) — это, драйвер, который работает с символьными устройствами.
Символьные устройства — это устройства, к которым можно обращаться как к потоку байтов.
Пример символьного устройства — /dev/ttyS0, /dev/tty1.

К вопросу про проверсию ядра:

Драйвер представляет каждое символьное устройство структурой scull_dev, а также предостовляет интерфейс cdev к ядру.

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

Для наглядности посмотрите на картинку.

Для регистрации устройства, нужно задать специальные номера, а именно:

MAJOR — старший номер (является уникальным в системе).
MINOR — младший номер (не является уникальным в системе).

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

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

В ядре есть специальные макросы module_init/module_exit, которые указывают путь к функциям инициализации/удаления модуля. Без этих определений функции инициализации/удаления никогда не будут вызваны.

Здесь будем хранить базовую информацию об устройстве.

Последним этапом подготовительной работы будет подключение заголовочных файлов.
Краткое описание приведено ниже, но если вы хотите копнуть поглубже, то добро пожаловать на прекрасный сайт: lxr

Инициализация

Теперь давайте посмотрим на функцию инициализации устройства.

Первым делом, вызывая alloc_chrdev_region мы регистрируем диапазон символьных номеров устройств и указываем имя устройства. После вызовом MAJOR(dev) мы получаем старший номер.
Далее проверяется вернувшееся значение, если оно является кодом ошибки, то выходим из функции. Стоит отметить, что при разработке реального драйвера устройства следует всегда проверять возвращаемые значения, а также указатели на любые элементы (NULL?).

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

Выделяем память, делая вызов функции kmalloc и обязательно проверяем указатель на NULL.

Стоит упомянуть, что вместо вызова двух функций kmalloc и memset, можно использовать один вызов kzalloc, который выделят область памяти и инициализирует ее нулями.

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

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

Выше были представлены структуры scull_dev и cdev, которые реализуют интерфейс между нашим устройством и ядром. Функция scull_setup_cdev выполняет инициализацию и добавление структуры в систему.

Удаление

Функция scull_cleanup_module вызывается при удалении модуля устройства из ядра.
Обратный процесс инициализации, удаляем структуры устройств, освобождаем память и удаляем выделенные ядром младшие и старшие номера.

С удовольствием выслушаю конструктивную критику и буду ждать feedback’a.

Если вы нашли ошибки или я не правильно изложил материал, пожалуйста, укажите мне на это.
Для более быстрой реакции пишите в ЛС.

Источник