Материал: 6261

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

116

Рисунок 7.9 - Системные вызовы стандарта POSIX

4.10 Три концепции работы с устройствами

Для того чтобы, чтобы уже созданные ФС стали доступны приложениям ОС, должны быть созданы узлы (node), которые расположены в директории /dev.

Узлы ОС могут быть созданы из пространства пользователя:

•с помощью системного вызова mknod(...) из программы на языке С;

•с помощью утилиты mknod посредством команды языка shell.

Хотя любой из указанных способов предполагает указание всего четырех параметров - имя_узла, тип_узла, старший_номер_узла и младший_номер_узла, такая ситуация создает множество проблем:

•какое имя дать узлу, чтобы оно мнемонически отображало тип устройства и было не очень длинным, для удобства работы с ним;

•какой старший номер присвоить устройству, чтобы он соответствовал типу устройства и был стандартным для этого типа устройств;

•сколько должно быть младших номеров устройства, чтобы удовлетворить все варианты использования ОС;

117

•что делать с узлами устройств, которых нет в архитектуре ЭВМ;

•как узнать момент, когда к ЭВМ устройство подключается динамически (временное подключение и отключение устройств).

Исторически, сложилось три концепции (технологии) именования и отслеживания актуальности наличия устройств: manual, udev и systemd.

Концепция manual (ручная) появилась первой. Она предполагает использование, упомянутых выше, системного вызова mknod(...) или утилиты mknod.

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

Первоначально, именование и параметры узлов придумывались разработчиками ОС и были достаточно разнообразны. Со временем, стала проводиться стандартизация, учитывающая известные типы оборудования. Например:

•почти все ОС имеют устройство консоли /dev/console;

•винчестеры, с контроллерами ATA, стали именоваться /dev/hda, /dev/hdb и

далее, а разделы, на которых фактически и создаются ФС - /dev/hda1,

/dev/hda2, …, /dev/hdb1, /dev/hdb2, …

•разделы винчестеров, с контроллерам SATA или SCSI, стали именоваться -

/dev/sda1, /dev/sda2, …, /dev/sdb1, /dev/sdb2, ...

Окончательно, процесс стандартизации завершился созданием скрипта shell — MAKEDEV, который упорядочил использование имен и других параметров узлов. Часто, найти этот скрипт можно в директории /dev или /sbin.

Замечание

Используя скрипт MAKEDEV, можно легко создать узлы с корректными именами и параметрами, но невозможно решить проблемы эффективного их использования. Особенно остро этот вопрос встал, когда корпорация Microsoft стала интенсивно призвать производителей оборудования внедрять технологию Plug and Play. Принципиальный аспект этой проблемы состоит в том, что драйвера устройств работают в пространстве ядра ОС. И хотя они могут определить факт подключения к ЭВМ нового устройства, они не предназначены для посылки сигналов процессам, работающим в режиме пользователя.

Концепция udev, реализованная в ноябре 2003 года, решила проблему внедрения

технологии Plug and Play.

Здесь следует отметить, что широкое внедрение графических оболочек ОС потребовало организовать эффективный обмен сообщениями между демонами (фоновыми процессами) рабочего стола. Для этого была разработана технология D-Bus - специальная система межпроцессного взаимодействия, которая предоставляет несколько шин (логических шин):

•системную шину, которая создается при старте демона D-Bus и обеспечивает взаимодействие демонов системных процессов;

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

118

Таким образом, при старте ОС запускается демон udevd, который, используя шину D-Bus, отслеживает подключение новых устройств и создает для них нужные узлы. Когда устройства отключается от ЭВМ, udevd удаляет соответствующие им узлы, кроме тех, которые были созданы в ручную. Одновременно, также решается

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

Концепция systemd стала внедряться с апреля 2010 года и еще не реализована многими ОС.

Ее цель — унификация взаимодействия между процессами режима пользователя.

Вчастности:

•отслеживание динамики подключения устройств (вместо udevd);

•эффективное отслеживание групп процессов, порожденных системными

вызовами fork(...) и объединенных одной прикладной целью (cgroups).

ОС УПК АСУ, для работы с узлами устройств, использует эту современную концепцию systemd.

4.11 Разделы дисков и работа с ними

Когда все ФС, на всех разделах блочных устройств созданы, работа с файловой системой ОС становится достаточно простой:

•необходимо определить точки монтирования (директори) корневой ФС ОС для подключения к ним (монтирования) нужных сопуствующих ФС и затем, правильно записать желаемую конфигурацию в файле /etc/fstab;

•выполнить команду mount -a, и желаемая структура ФС ОС будет создана

для последующей эксплуатации.

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

Ситуация обостряется и становится критичной, когда необходимо провести модернизацию свзанную с:

•динамическим подключением других («не родных») ФС;

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

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

•размер ядра ОС значительно увеличивается;

•время разработки и последующей отладки ПО модулей становится неприемлемо большим.

В1985 году, компания Sun Microsystems для ОС SunOS предложила VFS — Virtual File System (File System Switch) - Виртуальнаую Файловую Систему.

119

Виртуальная файловая система VFS:

Суть идеи — расположить VFS между приложениями и конкретными файловыми системами на внешних носителях. Это позволяет пользовательского интерфеса для ФС разных типов сконцентрировать в одном месте, что создает утифицированный эталон для разработки драйверов ОС.

Таким образом, VFS обеспечивает унифицированный программный интерфейс к

услугам файловой системы, причем безотносительно к тому, какой тип файловой системы (vfat, ext2fs, nfs и другие) имеется на конкретном физическом носителе.

Врезультате, VFS:

•упрощает процесс создания драйверов ФС, что повышает их надежность;

•сокращает время разработки, что создает конкурентные преимущества самой ОС;

•уменьшает время отладки и исправления ошибок, что повышает актуальность их применения.

Влюбом случае, возможность применения тех или иных типов ФС зависит как от потребности самих вычислительных систем, реализованных на ПО ОС, так и от возможности правильного управления имеющимися ФС. Все равно, основу уравления ФС составляют утилиты mount и umount, которые мы рассмотрим в следующем подразделе.

4.12 Монтирование и демонтирование устройств

Монтирование файловой системы — подключение конкретного раздела внешнего блочного устройства к конкретному каталогу ФС, в видимой пользователю общей части дерева корневой ФС.

Дентирование файловой системы — отключение конкретного раздела внешнего блочного устройства от конкретного каталога ФС, в видимой пользователю общей части дерева корневой ФС.

Общее правило монтирования/демонтирования ФС:

•монтирование осуществляется командой mount с указанием узла ФС и директории монтирования, при этом: старое содержимое директории становится невидимым, а монтируемая ФС — видимой;

•демонтирование осуществляется командой umount с указанием или узла ФС или директории монтирования, при этом: старое содержимое директории

становится видимым, а демонтируемая ФС — невидимой;

Простейший общий вид команды монтирования:

mount -t Тип Устройство Директория;

Например, монтирование устройства /dev/sda2, типа ext2 в каталог /mnt, выглядит так:

$

mount -t ext2 /dev/sda2 /mnt

$

 

120

Команда mount, без параметров, выдает список монтированных в данный момент устройств:

/dev/sda5

on /

type ext4 (rw,errors=remount-ro)

proc

on /proc

type proc (rw,noexec,nosuid,nodev)

sysfs

on /sys

type sysfs (rw,noexec,nosuid,nodev)

none

on /sys/fs/fuse/connections type fusectl (rw)

…....

 

 

/dev/sda2

on /mnt

type ext2 (rw)

Команда umount, для указанного примера, может быть выполнена в двух вариантах:

umount /dev/sda2; umount /mnt;

Замечание

Информация о действиях команды mount оперативно заносится в файл /etc/mtab в формате:

Устройство on Каталог type Тип (Опции)

Для централизованного управления монтированием ФС, используется файл

/etc/fstab. Структура файла имеет вид:

Устройство Каталог Тип Опции fs_freq fs__passno

где

fs_freq — определяет, должна ли создаваться резервная копия этого раздела с помощью команды dump; значение 0 отменяет dump;

fs__passno — указывает в какую очередь данная ФС проверяется на целостность, при запуске Linux: 0 — проверка не требуется; 1 — для корневой ФС; 2 — для других ФС.

Демонстрационный пример /etc/fstab:

#/etc/fstab: static file system information.

#Use 'blkid' to print the universally unique identifier for a

#device; this may be used with UUID= as a more robust way to name devices

#that works even if disks are added and removed. See fstab(5).

#

 

 

 

 

 

# <file system> <mount point>

<type> <options>

<dump>

<pass>

# / was on /dev/sda2 during installation

 

 

/dev/sda4

/

ext2

errors=remount-ro

0

1

# swap was on /dev/sda6 during installation

 

 

/dev/sda6

none

swap

sw

0

0

/dev/fd0

/media/floppy0

auto

rw,user,noauto,exec,utf8 0

0

Замечание

Исторически, опции, с которыми монтируются ФС, создавались разработчиками разных ФС.

Источник: https://studfile.net/preview/16438529/