2.9 Выполнение в пользовательском пространстве

Перевод с английского на русский

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Переведено на сайте www.notabenoid.com
http://notabenoid.com/book/11832/38209
Внимание! Этот перевод, возможно, ещё не готов,
так как модераторы установили для него статус
"перевод редактируется"