Операционная система UNIX - Робачевский Андрей Михайлович

Этот подход, используемый в большинстве современных версий UNIX, требует соответствующей архитектуры файлового интерфейса к драйверам устройств. Как уже обсуждалось, доступ к периферии в UNIX осуществляется с помощью специальных файлов устройств, расположенных в корневой файловой системе некоторого типа, например ufs. В соответствии с архитектурой виртуальной файловой системы, все операции с этими файлами будут обслуживаться соответствующими функциями реальной файловой системы, в данном случае — ufs.

Однако такой схеме недостает традиционного для UNIX изящества. Специальный файл устройства не является обычным файлом системы ufs. Фактически все операции со специальным файлом устройства выполняются драйвером и не зависят от типа файловой системы. Поэтому было бы логичнее отобразить операции vnode не на вектор файловой системы, а непосредственно на коммутатор устройств.

Современные системы ветви System V используют для этого специальный тип файловой системы, называемый devfs или specfs.[52] Для этого типа файловой системы все операции vnode адресуют соответствующие функции требуемого элемента коммутатора устройств. После первоначального открытия файла, когда создается vnode, все запросы, связанные со специальным файлом устройства, проходят через vnode файловой системы specfs.

В то же время открытие файла, например с помощью системного вызова open(2), предусматривает ряд операций, реализованных реальной файловой системой, в которой находится специальный файл устройства (в нашем примере ufs). Одной из таких операций является трансляция имени, которая не может быть реализована файловой системой specfs, по существу являющейся виртуальной.

Решение данной проблемы рассмотрим на конкретном примере. Допустим, процесс вызывает функцию open(2) для специального файла устройства /dev/kmem для работы с виртуальной памятью ядра. Функция трансляции имени файловой системы ufs — ufs_lookup() сначала откроет inode файла /dev, а затем, прочитав каталог, обнаружит inode файла kmem, при этом будет размещен vnode этого файла. Однако ufs_lookup() определит, что тип этого файла IFCHR, т.е. специальный файл символьного устройства. Поэтому вместо функции ufs_open(), бессмысленной для этого типа файла, будет вызвана специальная функция файловой системы specfs, которая создаст собственный индексный дескриптор, описываемой структурой snode (от special inode), для этого файла, если таковой уже не находится в памяти. Согласно стандартной процедуре, также будет создан и виртуальный индексный дескриптор vnode, который будет указывать на вектор операций specops, которые специально предназначены для работы с драйверами устройств. Например, функции spec_open(), spec_read() или spec_write() в свою очередь вызовут соответствующие точки входа драйвера — функции <i>xx</i>open(), <i>xx</i>read() или <i>xx</i>write(). После этого функции ufs_open() будет передан адрес этого vnode, который она, в свою очередь, передаст системному вызову open(2). В результате, open(2) вернет процессу файловый дескриптор, адресующий vnode файловой системы specfs, а не vnode файла /dev/kmem. Таким образом, все дальнейшие операции с /dev/kmem будут перехватываться файловой системой specfs. Схема связи процесса с этим vnode приведена на рис. 5.4.

Рис. 5.4. Связь процесса с файлом /dev/kmem после его открытия

Однако изложенная схема является неполной и имеет ряд существенных недостатков. Дело в том, что драйвер конкретного устройства может адресоваться несколькими специальными файлами устройств, возможно, расположенными в различных физических файловых системах. В этом случае ядро бессильно определить фактическое число связей прикладных процессов с данным устройством, что может потребоваться, например, при вызове функции <i>xx</i>close(), когда все процессы закончили работу с устройством.

Для решения этой проблемы файловая система specfs предусматривает наличие дополнительного snode, позволяющего контролировать доступ к конкретному устройству. Этот объект, получивший название общего snode (common snode), является единственным интерфейсом доступа к драйверу устройства. Для каждого устройства (драйвера устройства) существует единственный common snode, который создается при первом доступе к устройству. Каждый специальный файл устройства, в свою очередь, имеет собственный snode в файловой системе specfs и соответствующий ему vnode, а также inode физической файловой системы, где расположен специальный файл устройства, и соответствующий ему vnode.

Для связи всех этих индексных дескрипторов между собой snode имеет два поля: s_commonvp, указывающее на common snode, и s_realvp, указывающее на vnode специального файла устройства файловой системы, где расположен последний.

Использование тех или иных vnode и связанных с ними inode или snode зависит от конкретных операций, выполняемых процессом с устройством. Большинство из этих операций не зависят от имени специального файла устройства и, соответственно, от реальной файловой системы, в которой он расположен. Эти операции выполняются через vnode, соответствующий common snode. Однако существует ряд операций, выполнение которых зависит от конкретного специального файла устройства, через который процесс взаимодействует с драйвером. Примером может служить проверка прав доступа при открытии специального файла устройства, которые расположены в vnode/inode реальной файловой системы. В этом случае используется vnode соответствующего специального файла устройства.

Схема описанной архитектуры приведена на рис. 5.5.

Рис. 5.5. Доступ к устройству через различные специальные файлы

Клоны

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

Во многих случаях использование различных младших номеров позволяет нескольким процессам осуществлять одновременную независимую работу с устройством (или псевдоустройством). Каждый младший номер при этом соответствует логическому драйверу, поддерживающему собственные структуры данных при работе с конкретным процессом. Типичным примером могут служить псевдотерминалы. В таких случаях процессу требуется получить доступ к устройству, при этом его не интересует его младший номер, поскольку различие в младших номерах не отражает различие в функциональности. Типичным примером являются сетевые протоколы, чаще всего реализованные в виде соответствующих драйверов. Сетевые соединения, основанные на одном и том же протоколе (и, следовательно, работающие с одним и тем же драйвером), используют различные младшие номера для доступа к драйверу. Это позволяет драйверу обеспечивать обработку нескольких сетевых соединений, для каждого из которых поддерживаются собственные структуры данных. Если процессу необходимо установить сетевую связь, ему безразлично, какой младший номер будет у драйвера, главное, чтобы он еще не использовался.