Роль драйвера устройства

Как программист, вы в состоянии делать свои выборы в своём драйвере и сделать приемлемый выбор между требуемым временем на программирование и гибкостью результата. Хотя может показаться странным, что мы называем драйвер "гибким", нам нравится это слово, потому что это подчёркивает, что роль драйвера устройства в обеспечении механизма, а не политики (создании жёстких правил).

Различие между механизмом и политикой - одна из лучших идей, стоящих за проектом Unix. Большинство проблем программирования в действительности может быть разделено на две части: "какие возможности будут обеспечены" (это механизм) и "как эти возможности могут быть использованы" (это политика, правила). Если две проблемы адресованы разным частям программы, или даже разным программам в целом, программный пакет много легче разработать и адаптировать к специфическим требованиям.

Например, управление в Unix графическим дисплеем разделено между X-сервером, который знает оборудование и предлагает унифицированный интерфейс для пользовательских программ, менеджерами окна и сессий, которые осуществляют индивидуальную политику, не зная что-либо об оборудовании. Люди могут использовать тот же оконный менеджер на разном оборудовании и разные пользователи могут запускать разные конфигурации на той же рабочей станции. Даже полностью различные настольные среды, такие как KDE и GNOME, могут сосуществовать в одной системе. Другим примером является многоуровневая сетевая структура TCP/IP: эта операционная система предлагает абстракцию сокета, которая не осуществляет политики в отношении передаваемых данных, в то время как разные серверы управляют сервисами (и связанными с ними политиками). Более того, сервера, наподобие ftpd, обеспечивают механизм передачи файлов, а пользователи могут использовать любого клиента, которого пожелают; существуют и клиенты, управляемые через командную строчку и через графический интерфейс, и кто угодно может написать новый пользовательский интерфейс для передачи файлов.

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

При написании драйверов программист должен уделить внимание фундаментальной концепции: написать код ядра для доступа к оборудованию, но не оказать давление частными правилами на пользователя, так как разные пользователи имеют разные потребности. Ваш драйвер должен обеспечивать доступ к оборудованию, оставляя задачи как использовать оборудование приложениям. Таким образом, драйвер гибок, если обеспечивает доступ к оборудованию без ограничений. Иногда, тем не менее, некоторые ограничения должны иметь место. К примеру, драйвер ввода/вывода может предоставлять только побайтный доступ к оборудованию, чтобы избежать написания дополнительного кода, необходимого для передачи отдельных битов.

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

"Гибкие" драйверы имеют типичные характеристики. Они включают поддержку синхронных и асинхронных операций, возможность быть открытыми множество раз, возможность максимально полного использования оборудования и отсутствие лишних программных уровней, чтобы оставаться простыми и свободными от ограничивающих операций. Драйверы такого сорта не только работают лучше у конечных пользователей, но также оказываются проще в написании и сопровождении. Быть свободными от ограничений - общая цель для разработчиков программного обеспечения.

Более того, многие драйверы устройств поставляются вместе с пользовательскими программами, чтобы помочь с конфигурированием и доступом к целевому устройству. Такие программы могут быть и простыми утилитами и графическими приложениями. В качестве примера можно привести программу tunelp, которая регулирует работу драйвера параллельного порта, и графическую утилиту cardctl, входящую в состав пакета PCMCIA драйвера. Часто предоставляются также клиентские библиотеки, которые обеспечивают возможности, которые нет необходимости иметь как часть самого драйвера.

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