3.2. Переносимость ос

Операционная система называется переносимой ОС (portable), или мобильной, если ее код может быть сравнительно легко перенесен с процессора одного типа на процессор другого типа и с аппаратной платформы одного типа на аппаратную платформу другого типа.

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

1. Подавляющая часть кода должна быть написана на языке, трансляторы которого имеются на всех машинах, куда предполагается переносить систему. Такими языками, например, являются стандартизи-рованные языки высокого уровня. Большинство переносимых ОС написано на языке C, который имеет много особенностей, полезных для разработки кодов ОС, и компиляторы которого широко доступны. Языки низкого уровня не подходят для решения подобных задач. Так, программа, написанная на ассемблере, является переносимой только в том случае, когда перенос ОС предполагается на компьютер, обладающий той же системой команд. В остальных случаях ассемблер используется только для тех непереносимых частей ОС, которые должны непосредственно взаимодействовать с аппаратурой (например, для обработчика прерываний), или частей, требующих максимальной производительности (например, для целочисленной арифметики повышенной точности).

2. Объем машинно-зависимых частей кода, непосредственно взаимодействующих с аппаратными средствами, должен быть по возможности минимизирован. Всегда следует избегать прямого манипулирования регистрами и другими аппаратными средствами процессора. Для уменьшения аппаратной зависимости разработчики ОС должны также исключить возможность использования по умолчанию стандартных конфигураций аппаратуры или их характеристик. Аппаратно-зависимые параметры можно “спрятать” в программно-задаваемые пользователем данные абстрактного типа. Для осуществления всех необходимых действий по управлению аппаратурой, представленной этими параметрами, должен быть написан набор аппаратно-зависимых функций. Каждый раз, когда какому-либо модулю ОС требуется выполнить некоторое действие, связанное с аппаратурой, он манипулирует абстрактными данными, используя соответствующую функцию из имеющегося набора. Когда ОС переносится, то соответственно изменяются только эти данные и функции, которые ими манипулируют. Например, в ОС Windows NT диспетчер прерываний преобразует аппаратные уровни прерываний конкретного типа процессора в стандартный набор уровней прерываний IRQL, с которым работают остальные модули ОС. Поэтому при переносе Windows NT на новую аппаратную платформу необходимо переписать те коды диспетчера прерываний, которые, в частности, занимаются отображением уровней прерывания на абстрактные уровни IRQL, а модули ОС, пользующиеся этими абстрактными уровнями, изменений не потребуют. Более того, в Windows NT любой ресурс системы, одновременно задействованной более чем в одном процессе, включая файлы, совместно используемую память и физические устройства, реализован в виде объекта и управляется рядом функций. Такой подход сокращает число преобразований, которые необходимо внести в ОС в процессе ее эксплуатации. Если, скажем, изменилось что-то в аппаратуре, то все, что необходимо сделать – это заменить соответствующий объект. Аналогично, если требуется поддержка новых ресурсов, то надо только добавить новый объект, не меняя при этом остального кода ОС. Наиболее фундаментальное отличие между объектом и обыкновенной структурой данных заключается в том, что внутренняя структура данных объекта скрыта от наблюдения. Вы должны вызвать объектную функцию для того, чтобы получить данные из объекта или поместить данные в объект. Вы не можете непосредственно изменять данные, находящиеся внутри объекта. Это отделяет средства реализации объекта от кода, который только использует его, такая техника позволяет легко изменять впоследствии реализацию объектов.

3. Аппаратно-зависимый код должен быть надежно изолирован в нескольких модулях, а не быть распределен по системе. Изоляции подлежат все части ОС, которые отражают специфику как процессора в отдельности, так и используемой аппаратной платформы в целом. Низкоуровневые компоненты ОС, имеющие доступ к процессорно-зависимым структурам данных и регистрам, должны быть в обязательном порядке оформлены в виде компактных логически обособленных модулей, которые могут быть заменены аналогичными по выполняемым функциям модулями для других процессоров. Для снятия платформенной зависимости, возникающей из-за различий между компьютерами разных производителей, построенными на одном и том же процессоре, должен быть введен хорошо локализованный программный слой машинно-зависимых функций с четко оговоренным межслойным интерфейсом.

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

Рис. 8. Перенос операционной системы на разные аппаратные платформы