Драйверы устройств ввода
Давайте обратим наше внимание на драйверы для распространённых устройств ввода, таких как клавиатуры, мыши и сенсорные экраны. Но сначала давайте кратко рассмотрим готовый сервис для доступа к оборудованию, доступный для драйверов ввода.
Serio
Уровень serio предлагает библиотечные подпрограммы для доступа к устаревшему оборудованию ввода, такому как i8042-совместимые контроллеры клавиатуры и последовательный порт. Клавиатуры PS/2 и мыши подключаются к первому, а сенсорные контроллеры с последовательным интерфейсом подключаются к последнему. Для взаимодействия с оборудованием, обслуживаемым serio, например, для передачи команды для PS/2 мыши, предписанные процедуры обратного вызова serio регистрируются с помощью serio_register_driver() .
Чтобы добавить новый драйвер как часть serio, с помощью serio_register_port() регистрируются точки входа open() / close() / start() / stop() / write() . Для примера посмотрите drivers/input/serio/serport.c .
Как можно увидеть на Рисунке 7.1, serio — это только один из маршрутов доступа к низкоуровневому оборудованию. Некоторые драйверы устройств ввода вместо него полагаются на низкоуровневую поддержку от шинных уровней, таких как USB или SPI.
Клавиатуры
Клавиатуры бывают на любой вкус — устаревшие PS/2, USB, Bluetooth, ИК, и так далее. Каждый тип имеет специальный драйвер устройства ввода, но все используют один и тот же драйвер событий клавиатуры, обеспечивая тем самым единый интерфейс для пользователей. Драйвер событий клавиатуры, однако, имеет отличительную особенность по сравнению с другими драйверами событий: он передаёт данные другой подсистеме ядра (уровню tty), а не в пользовательское пространстве с помощью узлов /dev .
Клавиатуры ПК
Клавиатуры ПК (также называемые клавиатурами PS/2 или AT клавиатурами) взаимодействует с процессором через i8042-совместимый контроллер клавиатуры. ПК обычно имеют специальный контроллер клавиатуры, но на ноутбуках взаимодействие с клавиатурой является одной из обязанностей встроенного контроллера общего назначения (смотрите раздел «Встроенные контроллеры» в Главе 20, «Дополнительные устройства и драйверы»). Когда вы нажимаете клавишу на клавиатуре компьютера, это происходит по такому пути:
1. Контроллер клавиатуры (или встроенный контроллер) сканирует и декодирует клавиатурную матрицу и заботится о нюансах, таких как устранение дребезга контактов.
2. Клавиатурный драйвер устройства с помощью serio для каждого нажатия и отпускания клавиши читает с контроллера клавиатуры сырые коды сканирования . Разницей между нажатием и отпусканием является самый старший бит, который для последнего случая установлен. Например, нажатие на кнопку «a» даёт пару скан-кодов, 0x1e и 0x9e . Специальные кнопки экранируются с помощью 0xE0 , так что нажатие кнопки со стрелкой вправо производит последовательность ( 0xE0 0x4D 0xE0 0xCD ). Для наблюдения выходящих из контроллера скан-кодов вы можете использовать утилиту showkey (после символа → идут пояснения):
bash> showkey -s
кл-ра была в режиме UNICODE
[ если вы пробуете это под X, это может не работать, так как
X сервер также читает /dev/console ]
нажмите любую кнопку (программа завершится спустя 10с после
последнего нажатия на кнопку).
.
0x1e 0x9e → Нажатие кнопки «a»
3. Клавиатурный драйвер устройства преобразует полученные скан-коды в коды клавиш, основываясь на режиме ввода. Чтобы увидеть код клавиши, соответствующий кнопке «a»:
bash> showkey
.
код кнопки 30 нажатие → Нажатие на кнопку «a»
код кнопки 30 отпускание → Отпускание кнопки «a»
Чтобы сообщить эти коды клавиш дальше вверх, драйвер генерирует событие ввода, которое передаёт управление драйверу событий клавиатуры.
4. Драйвер событий клавиатуры берёт на себя работу по преобразованию кода клавиши в зависимости от загруженной карты кодов клавиш. (Смотрите страницы справки loadkeys и map-файлы в /lib/kbd/keymaps .) Он проверяет, является ли преобразованный код клавиш такими действиями, как переключение виртуальной консоли или перезагрузка системы. Чтобы вместо перезагрузки системы в ответ на нажатие Ctrl+Alt+Del зажглись светодиоды CAPSLOCK и NUMLOCK , добавьте в обработчик Ctrl+Alt+Del драйвера событий клавиатуры, drivers/char/keyboard.c , следующее:
static void fn_boot_it(struct vc_data *vc, struct pt_regs *regs)
<
+ set_vc_kbd_led(kbd, VC_CAPSLOCK);
+ set_vc_kbd_led(kbd, VC_NUMLOCK);
— ctrl_alt_del();
>
5. Для обычных клавиш преобразованный код нажатия отправляется ассоциированному виртуальному терминалу и дисциплине линии N_TTY . (Мы обсуждали виртуальные терминалы и дисциплины линий в Главе 6, «Драйверы последовательных портов.») drivers/char/keyboard.c делает это следующим образом:
/* Добавляем код клавиши в переключаемый буфер */
tty_insert_flip_char(tty, keycode, 0);
/* Планируем */
con_schedule_flip(tty);
Дисциплина линии N_TTY обрабатывает ввод таким образом, что полученные с помощью клавиатуры данные отображаются на виртуальной консоли и позволяет приложениям пользовательского пространства читать символы из узла /dev/ttyX , подключённого к виртуальному терминалу.
На Рисунке 7.3 показано движение данных от момента нажатия клавиши на клавиатуре, до момента его появления на виртуальной консоли. Левая половина рисунка является зависимой от оборудования, а правая половина носит общий характер. В соответствии с целью разработки подсистемы ввода, нижележащий аппаратный интерфейс является прозрачным для драйвера событий клавиатуры и уровня tty. Таким образом, ядро ввода и чётко определённые интерфейсы событий ограждают пользователей ввода от нюансов оборудования.
Рисунок 7.3. Поток данных от PS/2-совместимой клавиатуры.
USB и Bluetooth клавиатуры
Спецификациями USB, связанными с устройствами взаимодействия с человеком (HID), предусмотрен протокол, по которому для взаимодействия используются USB клавиатуры, мыши, наборы кнопок и другие периферийные устройства ввода. На Linux это осуществляется через клиентский драйвер USB usbhid , который отвечает за класс USB HID ( 0x03 ). Usbhid регистрирует себя в качестве драйвера устройства ввода. Он соответствует API ввода и сообщает о соответствующих событиях ввода подключенных HID.
Для того, чтобы понять путь кода для USB клавиатуры, вернёмся к Рисунку 7.3 и изменим аппаратно-зависимую левую половину. Заменим контроллер клавиатуры в квадратике «Оборудование ввода» на контроллер USB, serio на уровень ядра USB и квадратик «Драйвер устройства ввода» на драйвер usbhid.
Для Bluetooth клавиатуры заменим на Рисунке 7.3 контроллер клавиатуры на набор микросхем Bluetooth, serio на уровень ядра Bluetooth и квадратик «Драйвер устройства ввода» на драйвер Bluetooth hidp.
USB и Bluetooth подробно рассматриваются в Главе 11, «Универсальная последовательная шина» и в Главе 16, «Linux без проводов», соответственно.
Мыши, как и клавиатуры, бывают с разными возможностями и имеют различные варианты взаимодействия. Давайте посмотрим на обычно использующиеся.
PS/2 мышь
Мыши генерируют относительные передвижения по осям X и Y. Кроме того, они имеют одну или несколько кнопок. Некоторые из них также имеют колёсико прокрутки. Драйвер устройства ввода для устаревшей PS/2-совместимой мыши для взаимодействия с контроллером основывается на уровне serio. Драйвер событий ввода для мышей, называемый mousedev , сообщает события мыши пользовательским приложениям с помощью /dev/input/mice .
Пример драйвера: Мышь-колёсико
Чтобы получить настоящий драйвер устройства мыши, давайте преобразуем вращающееся колёсико, рассматриваемое в Главе 4, «Создание основы», в вариант обычной PS/2 мыши. «Мышь-колёсико» создаёт одномерное движение по оси Y. Повороты колёсика по часовой стрелке и против часовой стрелки создают положительные и отрицательные относительные Y координаты соответственно (как колесо прокрутки на мыши), а нажатие на колёсико приводит к событию нажатия на левую кнопку мыши. Мышь-колёсико идеально подходит для навигации по меню в таких устройствах, как смартфоны, КПК и музыкальные плееры.
Драйвер устройства мыши-колёсика, реализованный в Распечатке 7.3, работает с оконными системами, такими как X Windows. Чтобы увидеть, как драйвер заявляет о своих похожих на мышь возможностях, посмотрите на roller_mouse_init() . В отличие от драйвера вращающегося колёсика в Распечатке 4.1 Главы 4, драйверу мыши-колёсика не нужны методы read() или poll() , так как о событиях сообщается с использованием API ввода. Обработчик прерывания от колёсика roller_isr() также соответственно изменяется. Убираем служебные действия, выполняемые в обработчике прерывания, использующие очередь ожидания, спин-блокировку и процедуру store_movement() для поддержки read() и poll() .
В Распечатке 7.3, + и — в начале строк обозначают отличия от драйвера вращающего колёсика, реализованного в Распечатке 4.1 Главы 4.
Источник
Пишем свой драйвер под 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(). Она как раз и занимается тем, что перекидывает данные из пространства ядра в пользовательское.
Хочу ещё сказать пару слов о символьных устройствах.
Выполните команду ls -l /dev/sda* . Вы увидите что-то вроде:
brw-rw—- 1 root disk 8, 0 2010-10-11 10:23 /dev/sda
brw-rw—- 1 root disk 8, 1 2010-10-11 10:23 /dev/sda1
brw-rw—- 1 root disk 8, 2 2010-10-11 10:23 /dev/sda2
brw-rw—- 1 root disk 8, 5 2010-10-11 10:23 /dev/sda5
Между словом «disk» и датой есть два числа разделённых запятой. Первое число называют старшим номером устройства. Старший номер указывает на то, какой драйвер используется для обслуживания данного устройства. Каждый драйвер имеет свой уникальный старший номер.
Файлы устройства создаются с помощью команты mknod, например: mknod /dev/test c 12 . Этой командой мы создадим устройство /dev/test и укажем для него старший номер (12).
Я не буду сильно углубляться в теорию, т.к. кому интересно – тот сможет сам почитать про это подробнее. Я дам ссылку в конце.
Прежде чем начать
Нужно знать несколько «волшебных» команд:
- insmod – добавить модуль в ядро
- rmmod – соответственно, удалить
- lsmod – вывести список текущих модулей
- modinfo – вывести информацию о модуле
Для компиляции модуля нам потребуются заголовки текущего ядра.
В debian/ubutnu их можно легко поставить так (к примеру для 2.6.26-2-686):
apt-get install linux-headers-2.6.26-2-686
Либо собрать пакет для вашего текущего ядра самим: fakeroot make-kpkg kernel_headers
Исходник
#include
/* Для printk() и т.д. */
#include/* Эта частичка древней магии, которая оживляет модули */
#include/* Определения макросов */
#include#include /* put_user */
// Ниже мы задаём информацию о модуле, которую можно будет увидеть с помощью 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, воизбежание конфликтов имен.
static int major_number; /* Старший номер устройства нашего драйвера */
static int is_device_open = 0; /* Используется ли девайс ? */
static char text[ 5 ] = «test\n» ; /* Текст, который мы будет отдавать при обращении к нашему устройству */
static char * text_ptr = text; /* Указатель на текущую позицию в тексте */
// Прописываем обработчики операций на устройством
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 );
if ( major_number «Registering the character device failed with %d\n» , major_number );
return major_number;
>
// Сообщаем присвоенный нам старший номер устройства
printk( «Test module is loaded!\n» );
printk( «Please, create a dev file with ‘mknod /dev/test c %d 0’.\n» , major_number );
// Функция выгрузки модуля
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;
if ( is_device_open )
return -EBUSY;
static int device_release( struct inode *inode, struct file *file )
<
is_device_open—;
return SUCCESS;
>
device_write( struct file *filp, const char *buff, size_t len, loff_t * off )
<
printk( «Sorry, this operation isn’t supported.\n» );
return -EINVAL;
>
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;
return byte_read;
>
* This source code was highlighted with Source Code Highlighter .
Сборка модуля
Ну а теперь можем написать небольшой Makefile:
obj-m += test.o
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
И проверить его работоспособность:
root@joker:/tmp/test# make
make -C /lib/modules/2.6.26-2-openvz-amd64/build M=/tmp/test modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.26-2-openvz-amd64′
CC [M] /tmp/1/test.o
Building modules, stage 2.
MODPOST 1 modules
CC /tmp/test/test.mod.o
LD [M] /tmp/test/test.ko
make[1]: Leaving directory `/usr/src/linux-headers-2.6.26-2-openvz-amd64′
Посмотрим что у нас получилось:
root@joker:/tmp/test# ls -la
drwxr-xr-x 3 root root 4096 Окт 21 12:32 .
drwxrwxrwt 12 root root 4096 Окт 21 12:33 ..
-rw-r—r— 1 root root 219 Окт 21 12:30 demo.sh
-rw-r—r— 1 root root 161 Окт 21 12:30 Makefile
-rw-r—r— 1 root root 22 Окт 21 12:32 modules.order
-rw-r—r— 1 root root 0 Окт 21 12:32 Module.symvers
-rw-r—r— 1 root root 2940 Окт 21 12:30 test.c
-rw-r—r— 1 root root 10364 Окт 21 12:32 test.ko
-rw-r—r— 1 root root 104 Окт 21 12:32 .test.ko.cmd
-rw-r—r— 1 root root 717 Окт 21 12:32 test.mod.c
-rw-r—r— 1 root root 6832 Окт 21 12:32 test.mod.o
-rw-r—r— 1 root root 12867 Окт 21 12:32 .test.mod.o.cmd
-rw-r—r— 1 root root 4424 Окт 21 12:32 test.o
-rw-r—r— 1 root root 14361 Окт 21 12:32 .test.o.cmd
drwxr-xr-x 2 root root 4096 Окт 21 12:32 .tmp_versions
Теперь посмотрим информацию о только что скомпилированном модуле:
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)
UPD:
У некоторых может не собраться модуль через Makefile, описанный выше.
Решение:
Создаём Makefile только с одной строкой: obj-m += test.o
И запускаем сборку так:
make -C /usr/src/linux-headers-`uname -r` SUBDIRS=$PWD modules
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;
Источник
