Драйверы устройств в Linux
Часть 2: Пишем в классе наш первый драйвер для Linux
Оригинал: «Device Drivers, Part 2: Writing Your First Linux Driver in the Classroom»
Автор: Anil Kumar Pugalia
Дата публикации: December 1, 2010
Перевод: Н.Ромоданов
Дата перевода: июнь 2012 г.
Светлана и Пагс добрались в свой класс с опозданием и увидели, что их профессор уже начал читать лекцию. Светлана робко попросила разрешения войти. Раздраженный профессор Гопи ответил: «Входите! Вы, друзья, опять сегодня опоздали, и по какой причине»?
Пагс поспешно ответил, что они обсуждали именно ту тему, которую сегодня изучают в классе — драйверы устройств в Linux. Пагс был более, чем счастлив, когда профессор сказал: «Хорошо! Тогда что-нибудь скажите о динамической загрузке в Linux. Если вы справитесь, то я прощу вас обоих!». Пагс знал, что один из способов сделать профессора счастливым, это — покритиковать Windows.
Он объяснил: «Как известно, при обычной установке драйверов в Windows для того, чтобы их активировать, необходимо перезагрузить систему. А если это, предположим, действительно неприемлемо в случае, если это нужно делать на сервере? Вот где выигрывает Linux. В Linux можно загружать и выгружать драйверы на лету, и это активно используется сразу после загрузки системы. Кроме того, драйвер мгновенно отключается после его выгрузки. Это называется динамической загрузкой и выгрузкой драйверов в Linux «.
Это впечатлило профессора. «Хорошо! Идите на свои места, но больше не опаздывайте». Профессор продолжил лекцию: «Теперь, когда вы уже знаете, что такое динамическая загрузка и выгрузка драйверов, я, прежде, чем мы перейдем к написанию нашего первого драйверов, покажу вам, как загружать и выгружать драйвера».
Динамическая загрузка драйверов
Рис.1: Предварительно собранные модули Linux
Чтобы динамически загружать и выгружать драйверы, воспользуйтесь следующими командами, которые находятся в директории /sbin и должны выполняться с привилегиями пользователя root:
Рис.2: Операции с модулями Linux
Наш первый драйвер для Linux
Сборка нашего первого драйвера
Подведем итог
Команда lsmod должна вам сообщить о том, что драйвер ofd загружен.
Пишем свой драйвер под Linux
Хочу признаться сразу, что я вас отчасти обманул, ибо драйвер, если верить википедии — это компьютерная программа, с помощью которой другая программа (обычно операционная система) получает доступ к аппаратному обеспечению некоторого устройства. А сегодня мы создадим некую заготовку для драйвера, т.к. на самом деле ни с каким железом мы работать не будем. Эту полезную функциональность вы сможете добавить сами, если пожелаете.
То, что мы сегодня создадим, корректнее будет назвать LKM (Linux Kernel Module или загрузочный модуль ядра). Стоит сказать, что драйвер – это одна из разновидностей LKM.
Писать модуль мы будем под ядра линейки 2.6. LKM для 2.6 отличается от 2.4. Я не буду останавливаться на различиях, ибо это не входит в рамки поста.
Мы создадим символьное устройство /dev/test, которое будет обрабатываться нашим модулем. Хочу сразу оговориться, что размещать символьное устройство не обязательно в каталоге /dev, просто это является частью «древнего магического ритуала».
Немного теории
Если кратко, то LKM – это объект, который содержит код для расширения возможностей уже запущенного ядра Linux. Т.е. работает он в пространстве ядра, а не пользователя. Так что не стоит экспериментировать на рабочем сервере. В случае ошибки, закравшейся в модуль, получите kernel panic. Будем считать, что я вас предупредил.
Модуль ядра должен иметь как минимум 2 функции: функцию инициализации и функцию выхода. Первая вызывается во время загрузки модуля в пространство ядра, а вторая, соответственно, при выгрузке его. Эти функции задаются с помощью макроопределений: module_init и module_exit.
Стоит сказать несколько слов о функции printk(). Основное назначение этой функции — реализация механизма регистрации событий и предупреждений. Иными словами эта функция для записи в лог ядра некой информации.
Т.к. драйвер работает в пространстве ядра, то он отграничен от адресного пространства пользователя. А нам хотелось бы иметь возможность вернуть некий результат. Для этого используется функция put_user(). Она как раз и занимается тем, что перекидывает данные из пространства ядра в пользовательское.
Хочу ещё сказать пару слов о символьных устройствах.
Между словом «disk» и датой есть два числа разделённых запятой. Первое число называют старшим номером устройства. Старший номер указывает на то, какой драйвер используется для обслуживания данного устройства. Каждый драйвер имеет свой уникальный старший номер.
Я не буду сильно углубляться в теорию, т.к. кому интересно – тот сможет сам почитать про это подробнее. Я дам ссылку в конце.
Прежде чем начать
Для компиляции модуля нам потребуются заголовки текущего ядра.
В debian/ubutnu их можно легко поставить так (к примеру для 2.6.26-2-686):
apt-get install linux-headers-2.6.26-2-686
Либо собрать пакет для вашего текущего ядра самим: fakeroot make-kpkg kernel_headers
Исходник
// Ниже мы задаём информацию о модуле, которую можно будет увидеть с помощью Modinfo
MODULE_LICENSE( «GPL» );
MODULE_AUTHOR( «Alex Petrov
» );
MODULE_DESCRIPTION( «My nice module» );
MODULE_SUPPORTED_DEVICE( «test» ); /* /dev/testdevice */
#define SUCCESS 0
#define DEVICE_NAME «test» /* Имя нашего устройства */
// Поддерживаемые нашим устройством операции
static int device_open( struct inode *, struct file * );
static int device_release( struct inode *, struct file * );
static ssize_t device_read( struct file *, char *, size_t, loff_t * );
static ssize_t device_write( struct file *, const char *, size_t, loff_t * );
// Прописываем обработчики операций на устройством
static struct file_operations fops =
<
.read = device_read,
.write = device_write,
.open = device_open,
.release = device_release
>;
// Функция загрузки модуля. Входная точка. Можем считать что это наш main()
static int __init test_init( void )
<
printk( KERN_ALERT «TEST driver loaded!\n» );
// Регистрируем устройсво и получаем старший номер устройства
major_number = register_chrdev( 0, DEVICE_NAME, &fops );
// Сообщаем присвоенный нам старший номер устройства
printk( «Test module is loaded!\n» );
// Функция выгрузки модуля
static void __exit test_exit( void )
<
// Освобождаем устройство
unregister_chrdev( major_number, DEVICE_NAME );
printk( KERN_ALERT «Test module is unloaded!\n» );
>
// Указываем наши функции загрузки и выгрузки
module_init( test_init );
module_exit( test_exit );
static int device_open( struct inode *inode, struct file *file )
<
text_ptr = text;
static int device_release( struct inode *inode, struct file *file )
<
is_device_open—;
return SUCCESS;
>
static ssize_t device_read( struct file *filp, /* include/linux/fs.h */
char *buffer, /* buffer */
size_t length, /* buffer length */
loff_t * offset )
<
int byte_read = 0;
if ( *text_ptr == 0 )
return 0;
Сборка модуля
Ну а теперь можем написать небольшой Makefile:
И проверить его работоспособность:
Посмотрим что у нас получилось:
Теперь посмотрим информацию о только что скомпилированном модуле:
root@joker:/tmp/test# modinfo test.ko
filename: test.ko
description: My nice module
author: Alex Petrov
license: GPL
depends:
vermagic: 2.6.26-2-openvz-amd64 SMP mod_unload modversions
Ну и наконец установим модуль в ядро:
root@joker:/tmp/test# insmod test.ko
Посмотрим есть ли наш модуль с списке:
root@joker:/tmp/test# lsmod | grep test
И что попало в логи:
root@joker:/tmp/test# dmesg | tail
[829528.598922] Test module is loaded!
[829528.598926] Please, create a dev file with ‘mknod /dev/test c 249 0’.
Наш модуль подсказываем нам что нужно сделать.
Последуем его совету:
root@joker:/tmp/test# mknod /dev/test c 249 0
Ну и наконец проверим работает ли наш модуль:
root@joker:/tmp/test# cat /dev/test
Наш модуль не поддерживает приём данных со стороны пользователя:
root@joker:/tmp/test# echo 1 > /dev/test
bash: echo: ошибка записи: Недопустимый аргумент
Посмотрим что что скажет модуль на наши действия:
root@joker:/tmp/test# dmesg | tail
[829528.598922] Test module is loaded!
[829528.598926] Please, create a dev file with ‘mknod /dev/test c 249 0’.
[829747.462715] Sorry, this operation isn’t supported.
root@joker:/tmp/test# rmmod test
И посмотрим что он нам скажет на прощание:
root@joker:/tmp/test# dmesg | tail
[829528.598922] Test module is loaded!
[829528.598926] Please, create a dev file with ‘mknod /dev/test c 249 0’.
[829747.462715] Sorry, this operation isn’t supported.
[829893.681197] Test module is unloaded!
Удалим файл устройства, что бы он нас не смущал:
root@joker:/tmp/test# rm /dev/test
Заключение
Дальнейшее развитие этой «заготовки» зависит только от вас. Можно превратить её в настоящий драйвер, который будет предоставлять интерфейс к вашему девайсу, либо использовать для дальнейшего изучения ядра Linux.
Только что в голову пришла совершенно безумная идея сделать sudo через файл устройства. Т.е. посылаем в /dev/test команду и она выполняется от имени root.
Литература
И под конец дам ссылку на книгу заклинаний LKMPG (Linux Kernel Module Programming Guide)
UPD2:
Поправил ошибки в исходнике.
Парсер глючит и сохраняет ‘MODULE_DEscriptION( «My nice module» );’. Естественно в module_description все буквы заглавные.
UPD3:
segoon прислал несколько поправок к посту:
1) В функции device_open() находится race condition:
static int device_open( struct inode *inode, struct file *file )
<
text_ptr = text;
Русские Блоги
Написать простой драйвер под Linux
В этой статье сначала описывается пример драйвера, который можно протестировать и запустить, а затем обсуждаются элементы шаблона драйвера в Linux и процесс выполнения от приложения к драйверу в Linux. Я считаю, что описание от мелкого до глубокого, от конкретных примеров до абстрактной теории, для начинающих легче начать с двери, управляемой Linux.
1. Простой пример драйвера
Файл драйвера hello.c
При печати с использованием printk добавление «KERN_EMERG» к параметрам может обеспечить вывод информации для печати на консоль. Поскольку printk print разделен на 8 уровней, верхний уровень выводится на консоль, а нижний уровень выводится в файл журнала.
Makefile требуется для компиляции драйвера
Для компиляции файла драйвера необходим подходящий make-файл, потому что при компиляции драйвера нужно знать файл заголовка ядра, правила компиляции и т. Д.
Тестовый верхний код приложения hellotest.c
В верхнем тестовом случае сначала откройте файл устройства, а затем запишите данные на устройство. Таким образом, будут вызваны соответствующие функции xxx_open и xxx_write в драйвере, и информация о печати драйвера может быть использована для определения, действительно ли соответствующая функция выполняется должным образом.
Во-вторых, пример теста диска
Общий метод тестирования состоит в том, чтобы скомпилировать драйвер и тестовое приложение верхнего уровня, загрузить драйвер и вызвать драйвер через приложение верхнего уровня и, наконец, выгрузить драйвер.
1. Скомпилируйте драйвер
Создайте команду, напрямую вызовите Makefile для компиляции hello.c и, наконец, сгенерируйте «hellomodule.ko».
2. Скомпилируйте приложение верхнего уровня
С помощью этой команды вы можете скомпилировать приложение hellotest верхнего уровня.
3. Загрузите драйвер
Когда insmod загружает драйвер, вызывается функция hello_init (), и распечатанная отладочная информация выглядит следующим образом.
Кроме того, вы можете увидеть загруженные модули в «/ proc / devices».
4. Создайте узел
Хотя драйвер hellomodule.ko был загружен, и загруженный модуль HelloModule также отображается в файле / proc / devices, этот модуль не может использоваться, поскольку в каталоге устройств / dev нет соответствующего файла устройства. Поэтому вам необходимо создать узел устройства.
Номер основного устройства модуля HelloModule в / proc / devices равен 231. Когда узел создается, файл устройства / dev / hellodev подключается к номеру основного устройства. Таким образом, когда приложение манипулирует файлом / dev / hellodev, оно обнаружит модуль HelloModule.
Разница между / proc / devices и / dev
5. Вызов драйвера приложения верхнего уровня
Приложение hellotest сначала открывает файл «/ dev / hellodev», а затем записывает переменную val в этот файл. В течение этого периода будут вызваны функции hello_open и hello_write в базовом драйвере. Ниже приведены результаты работы hellotest.
6. Удалите драйвер
Когда insmod удаляет драйвер, он вызывает функцию hello_exit (), и печатная информация об отладке выглядит следующим образом.
Суммируйте последовательность операций модуля:
(1) Зарегистрируйте модуль с помощью команды insmod
(2) Создайте файл устройства «xxx» в каталоге / dev с помощью команды mknod и установите соединение с модулем через основной номер устройства.
(3) Прикладной уровень управляет базовым модулем через файл устройства / dev / xxx
Три, диск шаблон
1. Заголовочные файлы
init.h определяет функции, связанные с инициализацией и выходом драйвера
kernel.h определяет часто используемые прототипы функций и определения макросов
module.h определяет функции, переменные и макросы, связанные с модулем ядра
2. Функция инициализации
Когда драйвер загружается в ядро, эта функция инициализации будет выполняться автоматически.
Функция инициализации используется для инициализации модуля, как следует из названия. Обычно используемая функция заключается в регистрации функции через register_chrdev. Ядро выделяет часть памяти (массив) для хранения набора функций символьного устройства.Функция register_chrdev заполнит содержимое hello_flops в позиции HELLO_MAJOR этого массива, которое должно зарегистрировать адрес функции функции HelloModule для набора памяти управления устройством.
Метафора изображения, по-видимому, заключается в том, что операционная система предоставляет множество вешалок для одежды, а зарегистрированное устройство похоже на повешение одежды на определенной вешалке для одежды. На одежде много карманов, как будто каждый модуль имеет множество функциональных программных интерфейсов. Очевидно, что если вы хотите использовать определенную функцию устройства, вы можете сначала найти соответствующую вешалку для одежды, затем найти соответствующий карман, вызвать соответствующую функцию и выполнить действие.
3. Выход из функции
Когда драйвер удален, функция выхода будет выполнена автоматически, выполнив некоторые понятные задачи.
При загрузке драйвера мы регистрировали соответствующие функции функции модуля в памяти устройства управления. При удалении драйвера необходимо очистить пространство памяти, занимаемое этим модулем. Таким образом, при регистрации других устройств остается больше места для выбора.
Метафора изображения заключается в том, что при выгрузке диска одежда снимается с вешалки, так что вешалка становится пустой.
4. Информация об авторских правах
Ядро Linux выпущено в соответствии с GPL, и драйвер Linux также должен предоставлять информацию об авторских правах, в противном случае система выдаст предупреждение при загрузке в ядро.
5. Функциональная функция
View Code
В-четвертых, процесс выполнения от приложения верхнего уровня до драйвера нижнего уровня
1. Иерархическая структура системы Linux
2. Процесс выполнения от приложения верхнего уровня до драйвера нижнего уровня
Возьмем функцию «open (» / dev / hellodev «, O_RDWR)» в качестве примера для иллюстрации.
(1) Приложение использует функцию открытия, предоставляемую библиотекой, чтобы открыть файл устройства, представляющий hellodev.
(2) Библиотека выполняет swi-инструкцию в соответствии с параметрами, переданными функцией open, что приведет к сбоям в работе процессора и попаданию в ядро.
(3) Функция обработки исключений ядра находит соответствующий драйвер в соответствии с этими параметрами.
(4) Выполните соответствующий драйвер.
(5) Верните дескриптор файла в библиотеку, а затем в приложение.
3. Характеристики исполнения водителя
В отличие от прикладных программ, драйвер никогда не запускается активно, он пассивен: он инициализируется в соответствии с требованиями прикладной программы, а чтение и запись выполняется в соответствии с требованиями прикладной программы. Драйвер загружается в ядро, просто говоря ядру: «Я здесь, я могу выполнять эти задания», и когда эти задания запускаются, это зависит от приложения.
Драйвер работает в «пространстве ядра», которое является частью «доверия» системы. Ошибки драйвера могут привести к сбою всей системы.
«Полное руководство по разработке приложений для встроенного Linux»
Русские Блоги
Скомпилируйте загруженный драйвер в ядро ядра (linux)
Первый, основной способ компиляции драйвера в ядро
Есть два способа скомпилировать драйвер в ядро под linux:
1) Статическая компиляция
2) Динамическая компиляция
Статическая компиляция заключается в интеграции исходного кода загруженного драйвера в исходный код ядра ядра, а затем в настройке соответствующих параметров через графический интерфейс.После настройки параметров сохраните и выйдите, затем скомпилируйте и, наконец, скомпилированный, интегрированный и используемый для записи Записанный файл здесь будет называться uImage.
Выберете ли вы статическую компиляцию или динамическую компиляцию, зависит от ваших потребностей.
Один, статическая компиляция
Я только подробно объясняю, как добавить соответствующие параметры модуля в графический интерфейс. Шаги, предшествующие графическому интерфейсу (make menuconfig), были опущены. Перед этим я просмотрел множество руководств, поэтому я не буду повторять их здесь.
1. О скачанных драйверах
2) Модификация связанных файлов исходного кода драйвера
В исходном коде драйвера нужно изменить только 2 файла:
Kconfig
Файл Kconfig используется для описания информации о связанных параметрах графического интерфейса, например о том, какому типу атрибутов выбора соответствует этот параметр (<> (Д / Н / М), [] [Д / Н ]…), Например, описание информации, относящейся к этой опции и т. Д., Если Kconfig отсутствует, вы должны создать его самостоятельно. Возьмите модуль Wi-Fi в качестве примера. После создания добавьте контент, который вы хотите добавить, следующим образом (если Kconfig уже существует, не изменяйте его):
Kconfig
Добавьте следующий код в последнюю строку Kconfig:
Makefile изменяется следующим образом:
После изменения вышеуказанных файлов, когда вы введете команду make menuconfig в терминале telminal и снова войдете в графический интерфейс, вы увидите, что появились соответствующие параметры (как показано ниже). Расположение параметра связано с путем к исходному коду вашего драйвера.Чем глубже путь к драйверу в исходном коде ядра, тем глубже соответствующий путь к параметру в графическом интерфейсе. 
Выберите опцию справки, чтобы просмотреть информацию описания:
Два, динамическая компиляция
Вот все же в качестве примера возьмем модуль Wi-Fi. После загрузки соответствующего исходного кода драйвера вам нужно только изменить Makefile. Основные изменения заключаются в следующем:
как скомпилировать драйвер?
здравствуйте! есть платка с at91rm9200, на ней крутится линукс, по i2c подключен l3g4200 и надо чтоб в ядре был его драйвер. сам драйвер написан, ссылка вот http://www.st.com/internet/com/SOFTWARE_RESOURCES/SW_COMPONENT/SW_DRIVER/l3g4. а как его внедрить в ядро? верней его надо скомпилировать, а потом через menuconfig подключить видимо и скомпилировать ядро(это я научился).
Перемещено JB из Development
стоп. во-первых, должна быть какая то папка в исходниках ядра, где собираются все модули. так? во-вторых, откуда мне взять мейкфайл для того чтобы скомпилировать исходник?
Это обрезок какой-то, а не драйвера.
попробуйте сделать как /usr/src/kernels/linux-3.0/drivers/sfi
или я опять что то не понял?
http://pastebin.com/EdyeucmR
вот это сохрани как Makefile и напиши в консоли make без аргументов, всё
вообще я не понял. ядро у меня 2.6.30 стоит на проце, это на компьютере стоит 3.0.0-12. может это поможет, как изменить то?
кроме linux device drivers есть какие нибудь книги по данной тематике. или еще надо читать документацию на ядро?
все равно не работает. вообщем в топку, буду читать linux device drivers и писать с нуля
Тоже машинка на этом проце и та же ИС гироскопа. Собрать драйвер удалось, делалось примерно таким же Makefile’ом, но с make указывались переменные ARCH=arm CROSS_COMPILE=arm-unknown-linux-uclibcgnueabi- (поскольку кросс-компиляция).
Скопировал на целевую систему, в домашнюю папку, делаю:
%insmod l3g4200d.ko
%lsmod
Module Size Used by
l3g4200d 6456 0
%ls /sys/bus/i2c/drivers
ev_driver dummy l3g4200d rtc-ds1672
%ls /sys/bus/i2c/devices/
0-0068
Таким образом мы видим, что драйвер включился в ядро, появился в каталоге /sys/bus/i2c/drivers, но в каталоге /sys/bus/i2c/devices/, где он тоже по логике должен был быть, его нету (0-0068 это часы реального времени rtc-ds1672, драйвер был встроен в ядро).
Что значит вся эта картина? ИС либо драйвер работают некорректно? Или я что-то недонастраивал и эту ситуацию можно как-то поправить? Спасибо.