Linux Device Drivers 3 / Драйверы устройств Линукс (третье издание): 2.9. Выполните это в пространстве пользователя

2.9 Выполняйте это в пространстве пользователя

victor8632 10.11.10 в 12:30

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

Преимущества драйверов в пространстве пользователя:

ximen 25.10.10 в 09:25

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

victor8632 10.11.10 в 12:35

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

ximen 26.10.10 в 11:35

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

ximen 25.10.10 в 09:28

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

victor8632 10.11.10 в 12:37

Хорошо спроектированная программа драйвера может, как и драйвера в пространстве ядра, обеспечивать одновременный доступ к устройству.

victor8632 10.11.10 в 12:43

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

ximen 25.10.10 в 12:27

Например, USB драйвера могут быть написаны для пространства пользователя; см. (еще молодой) проект libusb на libusb.sourceforge.net и "gadgetfs" в исходных кодах ядра. Другим примером является X сервер: он точно знает, что оборудование может делать и что не может, и предоставляет графические ресурсы для всех X клиентов. Однако, следует отметить медленное, но неуклонное движение в сторону базирующейся на буферизации окон графической среде, где X сервер выступает только как сервер, основанный на реальных драйверах устройств пространства ядра и использующийся для фактических графических манипуляций.

victor8632 10.11.10 в 12:45

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

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

victor8632 11.11.10 в 05:52

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

ximen 25.10.10 в 09:30

Прямой доступ к памяти возможен только через отображение в память /dev/mem и только для привелигерованного пользователя.

ximen 25.10.10 в 13:30

Доступ к портам ввода/вывода возможен только после вызова ioperm или iopl. Более того, не все платформы поддерживают эти системные вызовы, а доступ к /dev/port может быть слишком медленным, чтобы быть эффективным. Доступ как к системным вызовам, так и к файлу устройства возможен только привелигерованному пользователю.

ximen 25.10.10 в 13:29

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

victor8632 11.11.10 в 06:02

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

victor8632 11.11.10 в 06:05

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

victor8632 11.11.10 в 06:14

Как видите, драйверы пользовательского пространства могут далеко не все. Тем не менее существуют довольно интересные приложения: например, поддержки SCSI сканеров (осуществляется при помощи пакета SANE) и CD писалки (осуществляется cdrecord и другим инструментарием). В обоих случаях драйвера устройств пользовательского уровня полагаются на "общий" SCSI драйвер ядра, который экспортирует SCSI функциональность низкого уровня в программы пользовательского пространства и, таким образом, позволяет управлять собственными аппаратными устройствами.

victor8632 11.11.10 в 11:56

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

victor8632 11.11.10 в 12:15