45 Билет

Управление устройствами

Драйверы устройств либо записывают принятые данные во входную очередь, либо получают данные из выходной очереди. Администратор Dev определяет, в каком случае требуется завершить передачу, требуется ли отображение вводимых данных на дисплее и т.д. Для обеспечения высокой степени реактивности Администратор Dev должен выполняться с достаточно высоким приоритетом. Обычно администратору Dev не приходится сильно загружать процессор, поэтому он незначительно влияет на общую производительность системы. Драйверы, подобно любым другим процессам QNX, могут выполняться с различными приоритетами в зависимости от особенностей обслуживаемых ими технических средств. Управление устройствами на низшем уровне реализовано посредством вызова соответствующего драйвера по входу ioctl. Общий набор ioctl-команд поддерживается большинством драйверов, используемых непосредственно Администратором Dev. Кроме того, процессы QNX могут через Dev выдавать драйверам ioctl-команды, ориентированные на устройства (посредством функции Си qnx_ioctl()).

Консоль QNX

Системными консолями управляет процесс Dev.con. Консоль - это совокупность видеоадаптера, монитора и системной клавиатуры. В системе QNX имеется возможность организации параллельной работы посредством виртуальных консолей. Драйвер консоли Dev.con обычно выполняет обработку нескольких наборов очередей ввода/вывода к Администратору Dev, что позволяет процессам пользователя иметь набор периферийных устройств с именами /dev/con1, /dev/con2 и т.д. С точки зрения приложения одновременно используется несколько консолей.

Драйвер консоли QNX выполняется как обычный процесс. Вводимые с клавиатуры данные преобразуются обработчиком прерываний клавиатуры и помещаются непосредственно во входную очередь. Выходные данные принимает и отображает драйвер Dev.con, пока он существует в качестве процесса.

Устройства с последовательным интерфейсом

Последовательными коммуникационными каналами управляет процесс Dev.ser. Этот драйвер может управлять несколькими физическими каналами, работая с периферийными устройствами, которые имеют имена /dev/ser1, dev/ser2 и т.д.

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

ls /dev/ser*

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

Устройства с параллельным интерфейсом

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

ls /dev/par*

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

Dev.par является примером управляемого полностью без прерываний сервера ввода/вывода. Обычно этот процесс находится в RECEIVE-блокированном состоянии, ожидая появления данных в своей выходной очереди, и запускается администратором Dev. Когда данные становятся доступными для печати, Dev.par начинает выполняться в цикле активного ожидания (с относительно низким адаптивным приоритетом), ожидая приема данных принтером. Такой низкоприоритетный цикл активного ожидания не влияет на общую производительность системы, а в среднем обеспечивает максимально возможную пропускную способность для устройства с параллельным интерфейсом.

Производительность подсистемы периферийных устройств

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

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

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

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