Билет №18. Переносимость операционной системы
Многие операционные системы успешно работают на различных аппаратных платформах без существенных изменений в своем составе. В ОС можно выделить достаточно компактный слой машинно-зависимых компонентов ядра и сделать остальные слои ОС общими для разных аппаратных платформ.
Если код операционной системы может быть сравнительно легко перенесен с процессора одного типа на процессор другого типа и с аппаратной плат-формы одного типа на аппаратную платформу другого типа, то такую ОС называют переносимой (portable), или мобильной.
Хотя ОС часто описываются либо как переносимые, либо как непереносимые, мобильность - это не бинарное состояние, а понятие степени. Вопрос не в том, может ли быть система перенесена, а в том, насколько легко можно это сделать. Для того чтобы обеспечить свойство мобильности ОС, разработчики должны следовать следующим правилам.
Большая часть кода должна быть написана на языке, трансляторы которого имеются на всех машинах, куда предполагается переносить систему. Такими языками являются стандартизованные языки высокого уровня. Большинство переносимых ОС написано на языке С, который имеет много особенностей, полезных для разработки кодов операционной системы, и компиляторы ко-торого широко доступны.
Объем машинно-зависимых частей кода, которые непосредственно взаимодействуют с аппаратными средствами, должен быть по возможности минимизирован. Так, например, следует всячески избегать прямого манипулирования регистрами и другими аппаратными средствами процессора. Для уменьшения аппаратной зависимости разработчики ОС должны также ис-ключить возможность использования по умолчанию стандартных конфигу-раций аппаратуры или их характеристик.
Аппаратно-зависимый код должен быть надежно изолирован в нескольких модулях, а не быть распределен по всей системе. Изоляции подлежат все части ОС, которые отражают специфику как процессора, так и аппаратной платформы в целом.
По учебнику Олифера
Если код операционной системы может быть сравнительно легко перенесен с процессора одного типа на процессор другого типа и с аппаратной платформы одного типа на аппаратную платформу другого типа, то такую ОС называют пе¬реносимой (portable), или мобильной.
Хотя ОС часто описываются либо как переносимые, либо как непереносимые, мобильность — это не бинарное состояние, а понятие степени. Вопрос не в том, может ли быть система перенесена, а в том, насколько легко можно это сделать. Для того чтобы обеспечить свойство мобильности ОС, разработчики должны следовать следующим правилам.
- Большая часть кода должна быть написана на языке, трансляторы которого имеются на всех машинах, куда предполагается переносить систему. Такими языками являются стандартизованные языки высокого уровня. Большинство переносимых ОС написано на языке С, который имеет много особенностей, полезных для разработки кодов операционной системы, и компиляторы кото¬рого широко доступны. Программа, написанная на ассемблере, является переносимой только в тех случаях, когда перенос операционной системы плани¬руется на компьютер, обладающий той же системой команд. В остальных случаях ассемблер используется только для тех непереносимых частей систе¬мы, которые должны непосредственно взаимодействовать с аппаратурой (на-пример, обработчик прерываний), или для частей, которые требуют максималь¬ной скорости (например, целочисленная арифметика повышенной точности).
- Объем машинно-зависимых частей кода, которые непосредственно взаимодейст¬вуют с аппаратными средствами, должен быть по возможности минимизиро¬ван. Так, например, следует всячески избегать прямого манипулирования ре¬гистрами и другими аппаратными средствами процессора. Для уменьшения аппаратной зависимости разработчики ОС должны также исключить возмож-ность использования по умолчанию стандартных конфигураций аппаратуры или их характеристик. Аппаратно-зависимые параметры можно «спрятать» в программно-задаваемые данные абстрактного типа. Для осуществления всех необходимых действий по управлению аппаратурой, представленной этими параметрами, должен быть написан набор аппаратно-зависимых функций. Каждый раз, когда какому-либо модулю ОС требуется выполнить некоторое действие, связанное с аппаратурой, он манипулирует абстрактными данными, используя соответствующую функцию.; из имеющегося набора. Когда* ОС пе-реносится, то изменяются только эти данные и функции, которые ими мани-пулируют. Например, в ОС Windows NT диспетчер прерываний преобразует аппаратные уровни прерываний конкретного типа процессора в стандартный набор уровней прерываний IRQL, с которыми работают остальные модули операционной системы. Поэтому при переносе Windows NT на новую плат¬форму нужно переписать, в частности, те коды диспетчера прерываний, кото¬рые занимаются отображением уровней прерывания на абстрактные уровни IRQL, а те модули ОС, которые пользуются этими абстрактными уровнями, изменений не потребуют.
- Аппаратно-зависимый код должен быть надежно изолирован в нескольких модулях, а не быть распределен по всей системе. Изоляции подлежат все час¬ти ОС, которые отражают специфику как процессора, так и аппаратной плат-формы в целом. Низкоуровневые компоненты ОС, имеющие доступ к процес¬сорно-зависимым структурам данных и регистрам, должны быть оформлены в виде компактных модулей, которые могут быть заменены аналогичными модулями для других процессоров. Для снятия платформенной зависимо¬сти, возникающей из-за различий между компьютерами разных производите¬лей, построенными на одном и том же процессоре (например, MIPS R4000), должен быть введен хорошо локализованный программный слой машинно-зависимых функций.
В идеале слой машинно-зависимых компонентов ядра полностью экранирует ос¬тальную часть ОС от конкретных деталей аппаратной платформы (кэши, кон¬троллеры прерываний ввода-вывода и т. п.), по крайней мере для того набора платформ, который поддерживает данная ОС. В результате происходит подмена реальной аппаратуры некой унифицированной виртуальной машиной, одинако¬вой для всех вариантов аппаратной платформы. Все слои операционной систе¬мы, которые лежат выше слоя машинно-зависимых компонентов, могут быть написаны для управления именно этой виртуальной аппаратурой. Таким образом, у разработчиков появляется возможность создавать один вариант машинно-не¬зависимой части ОС (включая компоненты ядра, утилиты, системные обраба¬тывающие программы) для всего набора поддерживаемых платформ (рис. 3.9).
