3. Монолитная архитектура

Монолитная архитектура операционной системы

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

Заметим, что монолитную архитектуру имели самые первые поколения операционных систем.

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

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

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

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

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

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

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

Проблема расширяемости операционной системы

Под расширяемостью понимают возможность добавлять в операционную систему новую функциональность без изменения уже существующих компонентов системы.

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

Действительно, операционная система обычно живет довольно долго, например UNIX существует уже более 30 лет, Windows NT – более 10 лет. За время жизни операционной системы неизбежно появляется новое периферийное оборудование, поддержка которого не закладывалась в систему при ее проектировании. Тем не менее, для успешного существования на рынке, операционная система должна быстро реагировать на появление нового оборудования и обеспечивать его поддержку. Примером может служить появление и широкое распространение накопителей на компакт-дисках или Flash-памяти.

Помимо развития аппаратных средств ЭВМ, быстро развиваются технологии программирования, что также требует от операционной системы соответствующей поддержки. Например, в последние годы во многие операционные системы введена поддержка легковесных процессов (потоков, нитей) и процессов реального времени.

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

Наличие в составе операционной системы монолитного ядра, реализующего базовую функциональность всей операционной системы, существенно затрудняет введение в систему новой функциональности. Компоненты ядра сильно связаны между собой, причем обычно даже нет четких границ между различными подсистемами ядра. Введение новой функциональности почти наверняка потребует множества модификаций существующих компонентов ядра, что повлечет необходимость отладки сложного и весьма объемного кода ядра.

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

Проблема переносимости операционной системы

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

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

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

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

2. реализовать код всех аппаратно независимых модулей операционной системы на языке высокого уровня, так как низкоуровневый язык (ассемблер) сам является аппаратно зависимым.

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

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

Проблема совместимости операционной системы

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

Необходимость организации совместимости операционных систем объясняется следующим. У пользователей обычно скапливается некоторая библиотека прикладных программ, в приобретение которых были вложены некоторые средства. Немаловажным является и тот факт, что пользователь уже умеет работать с этими программами, ведь обучение требует времени, а часто и материальных затрат. Поэтому пользователь не примет операционную систему, не совместимую с его старыми программами. Следовательно, если производитель операционной системы заинтересован в ее продвижении, он должен позаботиться о вопросах совместимости.

Заметим, что если пользователь даже готов перейти на новые прикладные программы, в первое время после появления новой операционной системы таких программ может еще не быть, и пользователю придется использовать старые программы (вспомните историю развития Windows).

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

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

Двоичная совместимость – это способность операционной системы загружать исполняемые файлы, первоначально предназначенные для другой операционной системы, и нормально исполнять представленные в них программы.

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

Таким образом, задача обеспечения совместимости с системой B сводится к задаче расширения функциональности операционной системы A. Но если система A имеет монолитное ядро, введение в нее новой исполнительной системы будет весьма трудоемким и, кроме того, снизит стабильность работы системы.