Добавлен: 29.10.2018
Просмотров: 47976
Скачиваний: 190
12.3. Реализация
1071
этом работоспособность прикладных программ. Как было показано в разделе 9.7.7,
разработчики начинавшие этот проект, просто допустили в системном вызове access
ошибку, с которой приходится мириться до сих пор.
12.3. Реализация
Мы обсудили пользовательский интерфейс и интерфейс системных вызовов. Теперь
пора обсудить вопрос реализации операционной системы. В следующих разделах мы
изучим некоторые общие концептуальные вопросы, относящиеся к стратегиям реали-
зации. После этого рассмотрим некоторые примеры низкоуровневой техники, которая
часто бывает полезной.
12.3.1. Структура системы
Вероятно, первым решением, которое должны принять разработчики системы, явля-
ется решение о том, какой должна быть структура системы. Основные варианты мы
изучили в разделе 1.7, но рассмотрим их и здесь. Монолитное неструктурированное
устройство на самом деле представляет собой неудачную идею, подходящую разве
что крошечной операционной системе для, например, тостера, но даже в этом случае
ее использование спорно.
Многоуровневые системы
Разумный подход, установившийся с годами, заключается в создании многоуровне-
вых систем . Система THE, разработанная Э. Дейкстрой (см. табл. 1.3), была первой
многоуровневой системой. У операционных систем UNIX и Windows 8 также есть
многоуровневая структура, но уровни в них в большей степени представляют собой
способ описания системы, чем фактический руководящий принцип, использованный
при ее построении.
При создании новой системы разработчики должны сначала очень тщательно выбрать
уровни и определить функциональность каждого из них. Нижний уровень всегда
должен пытаться скрыть самые неприятные особенности аппаратуры, как это делает
уровень HAL. Вероятно, следующий уровень должен обрабатывать прерывания, за-
ниматься переключением контекста и работать с блоком управления памятью MMU,
так что выше этого уровня код оказывается в основном машинно независимым. На еще
более высоких уровнях все зависит от вкусов и предпочтений разработчиков. Один ва-
риант заключается в том, чтобы уровень 3 управлял потоками, включая планирование
и синхронизацию потоков (рис. 12.1). При этом начиная с уровня 4 мы получаем пра-
вильные потоки, которые нормально планируются и синхронизируются при помощи
стандартного механизма (например, мьютексов).
На уровне 4 мы обнаружим драйверы устройств, каждый из которых работает как от-
дельный поток, со своими состоянием, счетчиком команд, регистрами и т. д., возможно
(но не обязательно), в адресном пространстве ядра. Такое устройство может суще-
ственно упростить структуру ввода-вывода, потому что когда возникает прерывание,
оно может быть преобразовано в системный вызов unlock на мьютексе и обращение
к планировщику, чтобы (потенциально) запустить новый готовый поток, который был
1072
Глава 12. Разработка операционных систем
Рис. 12.1. Одна из возможных структур современной многоуровневой
операционной системы
блокирован мьютексом. Этот подход используется в системе MINIX, но в операцион-
ных системах UNIX, Linux и Windows 8 обработчики прерываний реализованы как
независимая часть системы, а не потоки, которые сами могут управляться планировщи-
ком, приостанавливаться и т. д. Поскольку основная сложность любой операционной
системы заключается во вводе-выводе, заслуживает внимания любой способ сделать
его более удобным для обработки и более инкапсулированным.
Над уровнем 4 мы, скорее всего, обнаружим виртуальную память, одну или несколь-
ко файловых систем и обработчики системных вызовов. Уровни сфокусированы на
предоставлении служб приложениям. Если виртуальная память расположена на более
низком уровне, чем файловые системы, то блочный кэш может быть выгружаемым, что
позволяет менеджеру виртуальной памяти динамически определять, как следует рас-
пределять физическую память между страницами пользователей и страницами ядра,
включая кэш. Подобным образом работает операционная система Windows 8.
Экзоядра
Хотя у многоуровневых структур есть много сторонников среди разработчиков систем,
существует также другой лагерь, придерживающийся противоположной точки зрения
(Engler et al., 1995). Их точка зрения базируется на сквозном аргументе (Saltzer et al.,
1984). Эта концепция заключается в том, что если что-либо должно быть выполнено
самой пользовательской программой, то неэффективно выполнять это и на нижнем
уровне.
Рассмотрим применение этого принципа к удаленному доступу к файлам. Если система
заботится о том, чтобы файлы не были повреждены, она должна считать для каждого
записываемого файла контрольную сумму и хранить ее вместе с файлом. Когда файл
пересылается по сети, вместе с файлом пересылается также его контрольная сумма,
которая проверяется по получении файла принимающей стороной. Если контрольные
суммы не совпадают, файл пересылается снова.
Проверка контрольной суммы является более аккуратным методом, чем использование
надежной сети. Она позволяет помимо ошибок, возникающих при передаче файла по
сети, перехватывать также ошибки чтения или записи на диск, ошибки памяти, про-
граммные ошибки в маршрутизаторах и т. д. Сквозной аргумент утверждает, что при
этом использование надежной сети перестает быть необходимым, так как в конечной
точке (у получающего процесса) есть достаточно информации, чтобы проверить
правильность полученного файла самостоятельно. Единственный довод в пользу ис-
12.3. Реализация
1073
пользования в данном случае надежного сетевого протокола заключается в повышении
эффективности обработки сетевых ошибок на более низком уровне.
Сквозной аргумент может быть расширен почти до пределов всей операционной си-
стемы. Он утверждает, что операционная система не должна делать того, что пользо-
вательская программа может сделать сама. Например, зачем нужна файловая система?
Почему бы не позволить пользователю просто читать и писать участки диска защищен-
ным способом? Конечно, большинству пользователей нравится работать с файлами, но,
согласно сквозному аргументу, файловая система должна быть библиотечной процеду-
рой, которую можно скомпоновать с любой программой, нуждающейся в файлах. Этот
подход позволяет различным программам использовать различные файловые системы.
Такая цепь рассуждений приводит к выводу, что операционная система должна только
обеспечивать безопасное распределение ресурсов (например, процессорного времени
или дисков) среди соревнующихся за них пользователей. Экзоядро представляет собой
операционную систему, построенную в соответствии со сквозным аргументом (Engler
et al., 1995).
Микроядерные системы «клиент–сервер»
Компромиссом между операционной системой, которая делает все, и операционной
системой, не делающей ничего, является операционная система, делающая кое-что.
Результатом такого дизайна является схема микроядра, при которой большая часть
операционной системы представляет собой серверные процессы, работающие на уров-
не пользователя (рис. 12.2). Такое устройство обладает наибольшей модульностью
и гибкостью по сравнению с другими схемами. Предел гибкости заключается в том,
чтобы каждый драйвер устройства также работал в виде пользовательского процесса,
полностью защищенного от ядра и других драйверов, но даже необходимость запуска
драйверов устройств в ядре является дополнением к модульности.
Когда драйверы устройств находятся в ядре, они могут обращаться к регистрам
аппаратных устройств напрямую. Если они не находятся в ядре, нужен некий ме-
ханизм предоставления им этого доступа. Если аппаратура это позволяет, то каж-
дому драйверному процессу может быть предоставлен доступ только к нужным
ему устройствам ввода-вывода. Например, если регистры устройств ввода-вывода
отображаются на адресное пространство памяти, то у каждого драйверного процесса
может быть страница памяти, на которую отображаются регистры соответствующе-
го устройства, но не другие страницы. Если же пространство портов ввода-вывода
частично защищено, каждому драйверу может быть разрешен доступ к нужной ему
порции этого пространства.
Рис. 12.2. Модель «клиент–сервер»
1074
Глава 12. Разработка операционных систем
Даже если аппаратная поддержка недоступна, этой идеей все равно можно воспользо-
ваться. Для этого нужен новый системный вызов, доступный только для драйверных
процессов. Для работы этот системный вызов пользуется списком пар (порт, значе-
ние). Ядро сначала проверяет, владеет ли процесс всеми портами в списке. Если да,
то оно копирует в порты соответствующие значения для инициализации устройства
ввода-вывода. Подобный системный вызов может быть использован для чтения портов
ввода-вывода.
Такой метод защищает структуры данных ядра от изучения и повреждения их драй-
верами устройств, что по большей части хорошо. Возможно создание аналогичного
набора вызовов, позволяющих драйверам устройств читать и писать таблицы ядра, но
только под контролем ядра и с его одобрения.
Главная проблема такого подхода, и проблема микроядер вообще, заключается в сниже-
нии производительности, вызываемом дополнительными переключениями контекста.
Однако практически вся работа по созданию микроядер была выполнена много лет
назад, когда центральные процессоры были значительно медленнее. Сегодня не так
уж много приложений, использующих каждую каплю мощности процессора, которые
не могут смириться с малейшей потерей производительности. В конце концов, когда
работает текстовый редактор или веб-браузер, центральный процессор простаивает
около 95 % времени. Если операционная система, основанная на микроядре, превра-
щает систему с процессором, работающим на частоте 3,5 ГГц, в надежную систему,
аналогичную по производительности системе с частотой 3 ГГц, мало кто из пользо-
вателей станет жаловаться. Если вообще заметит какую-либо разницу. Большинство
пользователей были просто счастливы всего несколько лет назад, когда приобрели
свой предыдущий компьютер с потрясающей тогда частотой процессора 1 ГГц. К тому
же не совсем ясно, будет ли стоимость межпроцессного обмена данными по-прежнему
такой же большой проблемой, если ядра перестанут быть дефицитным ресурсом. Если
у каждого драйвера устройства и у каждого компонента операционной системы будет
собственное, выделенное ядро, переключений контекста в ходе межпроцессного обмена
данными не станет. Кроме того, кэши, предсказатели ветвлений и TLB-буферы всегда
будут под рукой и готовыми работать на полной скорости. В работе Hruby et al. (2013)
был представлен ряд экспериментов по высокопроизводительной операционной си-
стеме, основанной на микроядре.
Стоит заметить, что, несмотря на низкую популярность микроядер на настольных
компьютерах, они весьма широко используются в сотовых телефонах, промышленных,
встроенных и военных системах, где абсолютным требованием выступает очень высо-
кая надежность. Кроме того, OS X компании Apple, работающая на всех компьютерах
Mac и Macbook, состоит из модифицированной версии FreeBSD, запущенной поверх
модифицированной версии микроядра Mach.
Расширяемые системы
В обсуждавшихся ранее системах «клиент–сервер» идея заключалась в том, чтобы
вынести за пределы ядра столько, сколько возможно. Противоположный подход за-
ключается в том, чтобы поместить больше модулей в ядро, но защищенным способом.
Ключевое слово здесь, разумеется, «защищенным». Некоторые механизмы защиты
предназначаются для импортирования апплетов по Интернету, но они в той же мере
применимы для установки чужеродного кода в ядро. Самыми важными из них явля-
12.3. Реализация
1075
ются песочницы и программы с электронной подписью, так как интерпретацию при-
менять в ядре непрактично.
Конечно, сама расширяемая система не является методом структурирования опера-
ционной системы. Однако, начав с минимальной системы, состоящей в основном из
механизма защиты, и постепенно добавляя к ядру защищенные модули, пока не будет
достигнута требуемая функциональность, можно создать минимальную систему для
конкретного приложения. При таком подходе новая операционная система может вы-
краиваться под каждое новое приложение благодаря включению только тех элементов,
которые необходимы для данного приложения. Примером такой системы является
Paramecium (Van Doorn, 2001).
Потоки ядра
Еще один вопрос, имеющий отношение к данной теме независимо от выбора структур-
ной модели, — это системные потоки. Иногда бывает удобно позволить потокам ядра
существовать отдельно от пользовательских процессов. Эти потоки могут работать
в фоновом режиме, записывая «грязные» страницы на диск, занимаясь свопингом
процессов и т. д. На самом деле ядро само может целиком состоять из таких потоков.
Когда пользователь обращается к системному вызову, пользовательский поток не вы-
полняется в режиме ядра, а блокируется и передает управление потоку ядра, который
принимает управление для выполнения работы.
Помимо потоков ядра, работающих в фоновом режиме, большинство систем также
запускают в фоновом режиме множество процессов-демонов. Хотя они и не являются
частью операционной системы, они часто выполняют «системные» функции. Это мо-
жет быть получение и отправка электронной почты, а также обслуживание различных
запросов удаленных пользователей, как, например, FTP или веб-страницы.
12.3.2. Механизм и политика
Еще один принцип, наряду с принципами минимализма и структурированности
помогающий добиться архитектурной согласованности, заключается в отделении
механизма от политики . Если поместить механизм в операционную систему, а по-
литику оставить пользовательским процессам, система может остаться неизменной,
даже если появляется потребность в изменении политики. Даже если модуль, зани-
мающийся политикой, должен располагаться в ядре, он должен быть по возможности
изолирован от механизма, чтобы изменения в модуле политики не влияли на модуль
механизма.
Чтобы представить границу между механизмом и политикой отчетливее, рассмотрим
два примера из реального мира. В качестве первого примера возьмем большую ком-
панию, у которой есть отдел заработной платы, ответственный за выплату жалованья
сотрудникам. У него есть компьютеры, программное обеспечение, бланки, договорен-
ность с банками, а также другие механизмы, требующиеся для фактической выплаты
зарплаты. Однако политика — принятие решений о том, кто и сколько получит, —
полностью отделена и является прерогативой управления. Отдел заработной платы
просто выполняет порученную ему работу.
В качестве второго примера рассмотрим ресторан. Он обладает механизмом для об-
служивания посетителей, включая столы, посуду, официантов, полную оборудования