Работа в пространстве пользователя

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

•Наиболее важные устройства не могут оперировать в пользовательском пространстве, в том числе, но не только, сетевые интерфейсы и блочные устройства.

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

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