Файловый интерфейс

В главе4 мы рассмотрели интерфейс т. н. независимой или виртуальной

Файловой системы, обеспечивающей унифицированный интерфейс работы

С различными типами физических файловых систем (например, ufs или s5fs),имеющих разные внутренние структуры и возможности. При этом подходе

используется унифицированный формат метаданных активных

файлов которые хранятся в памяти (в in-core — таблице индексных дескрипторов) и

не зависят от конкретной реализации файловой системы. Эти

объекты получили название виртуальных индексных дескрипторов или vnode

Для каждого vnode определен набор абстрактных операций, которые

реализованы функциями реальных файловых систем. Например, vnode файла

расположенного в файловой системе s5fs, адресует вектор операций

коммутатор файловых систем, FSS) sSfsops, содержащий конкрет-ie Функции этой файловой системы — s5f s_close (), s5fs_open () или s5fs_unlink;).

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

Однако такой схеме недостает традиционного для UNIX изящества. Спе~

циальный файл устройства не является обычным файлом системы ufs.

Факчески все операции со специальным файлом устройства выполняются

драйвером и не зависят от типа файловой системы. Поэтому было бы

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

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

элемента коммутатора устройств. После первоначального открытия файла, когда создается vnode, все запросы, связанные со специальным

файлом устройства, проходят через vnode файловой системы specfs.

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

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

Решение данной проблемы рассмотрим на конкретном примере Допустим, процесс вызывает функцию ореп(2) для специального файла устройства /dev/kmem для работы с виртуальной памятью ядра. Функция трансляции имени файловой системы ufs — ufs_lookup() сначала откроет inode файла /dev, а затем, прочитав каталог, обнаружит inode файла kmem, при этом будет размещен vnode этого файла. Однако ufs_lookup() определит, что тип этого файла ifchr, т. е. специальный файл символьного устройства. Поэтому вместо функции ufs_open(), бессмысленного для этого типа файла, будет вызвана специальная функция файловой системы specfs, которая создаст собственный индексный дескриптор описываемой структурой snode (от special mode), для этого файла, если таковой уже не находится в памяти. Согласно стандартной процедуре, также будет создан и виртуальный индексный дескриптор vnode, который будет указывать на вектор операций specops, которые специально предназначены для работы с драйверами устройств. Например, функции spec_open (), speс_read() или spec_write () в свою очередь вызовут соответствующие точки входа драйвера — функции ххореn(), xxread() или xxwrite(). После этого функции ufs_open() будет передан адрес этого vnode, который она, в свою очередь, передаст системному вызову ореп(2). В результате, ореп(2) вернет процессу файловый дескриптор, адресующий vnode файловой с темы specfs, а не vnode файла /dev/kmem. Таким образом, все дальнейшие операции с /dev/kmem будут перехватываться файловой системой spec Схема связи процесса с этим vnode приведена на рис. 5.4.

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

Для решения этой проблемы файловая система specfs предусматривает наличие дополнительного snode, позволяющего контролировать доступ к

конкретному устройству. Этот объект, получивший название общего snode

(common snode), является единственным интерфейсом доступа к драйверу

устройства, Для каждого устройства (драйвера устройства) существует

Ценный common snode, который создается при первом доступе к

устройству. Каждый специальный файл устройства, в свою очередь, имеет

собственный snode в файловой системе specfs и, соответствующий ему