5.1.Общие понятия
В книге [16] известного специалиста по операционным Э. Таненбаума приводятся 8 причин, по которым так сложно спроектировать ОС.
Современные операционные системы имеют громоздкий программный код. Все версии UNIX имеют более 1 млн. строк исходного кода. Операционная система Windows 2000 состоит из 29 млн. строк кода. Даже очень квалифицированный разработчик не в состоянии осознать даже малую часть этого кода. Разделить же ОС на отдельные независимые части (как это практикуется при разработке других систем) в силу их особенности не представляется возможным. Поэтому результаты часто оказываются далёкими от оптимальных.
Поддержка параллельного выполнения независимых и в то же время вынужденных взаимодействовать между собой процессов является очень сложной задачей.
Необходимость защиты от несанкционированного вмешательства в работу операционной системы ставит разработчиков перед дилеммой: либо выделить значительные ресурсы на эту праведную борьбу и создать непробиваемую систему за счет интересов «законопослушных» пользователей, либо ограничиться минимальными затратами на построение защитных редутов, не гарантирующих достаточной безопасности. Найти приемлемый компромисс для системы, состояния которой постоянно меняются, крайне сложно.
Надзор за работой пользователей должен быть строгим и в то же время доброжелательным. Разумеется, всегда найдутся недовольные пользователи – главное, чтобы их число не превысило критическое.
Разработчики должны сделать все возможное, чтобы обеспечить долгую жизнь операционной системы (ОС слишком сложны и дорого достаются, чтобы их готовить к короткой жизни).
У разработчиков ОС часто нет четкого представления о том, как будет использоваться их система. Поэтому в их задачу должно входить обеспечение достаточной степени универсальности.
Одно из основополагающих требований к современным системам – это переносимость на разные аппаратные платформы.
От операционной системы часто требуется совместимость с предыдущими версиями. Разработчики, наверное, много бы дали, чтобы избавиться от груза своих прошлых ошибок, но положение обязывает, и порой диктует решения не свободные от противоречий.
Из перечня этих трудностей следует, что шансы на успешную разработку новой универсальной операционной системы есть только у хорошо организованной команды, состоящей из специалистов высокой квалификации, хотя бы некоторые из которых уже имеют опыт создания ОС.
Однако этот вывод совсем не означает, что энтузиасты-одиночки и малые коллективы программистов полностью отстранены от такого интересного занятия, как проектирование операционных систем. Имеется, по крайней мере, две области, в которых их усилия (при соответствующей организации) могут оказаться полезными и для общества, и для них.
Для современной ситуации характерно массовое использование микропроцессоров в различных областях. В этом случае строго определена область применения и цель разработки соответствующей ОС. Это существенно упрощает проектирование операционных систем, а количество вариантов столь велико, что работой могут быть обеспечены все желающие её получить.
При развитии производства возрастает спрос на промышленные контроллеры, которые (как и все системы управления) должны осуществлять свои функции в режиме реального времени. Их диапазон – от простейших вычислительных систем до сложных и очень сложных, что создает идеальные условия для роста профессионализма в области программирования этих контроллеров. Учитывая соотношение стоимости аппаратных и программных средств, целесообразно осуществлять их программирование, начиная с создания операционной системы.
Проектирование операционной системы для контроллеров в общих чертах можно осуществлять по следующему плану:
в качестве платформы выбрать юридически чистую (свободную для распространения) операционную систему;
разработать программную многозадачную надстройку, которая, по сути дела представляет собой библиотеку, поддерживающую разработку и сопровождение программ в РВ;
используя для связи с аппаратными средствами в основном возможности исходной ОС, тем не менее перекрыть её наиболее «одиозные» драйверы и прерывания, не дающие возможности работать в реальном времени (например, осуществлять обработку ввода данных с клавиатуры таким образом, чтобы время ожидания нажатия клавиши отдавалось в распоряжение процессора).
Особенности работы контроллеров позволяют многозадачную оболочку использовать в режиме «сеанса» (Рис. 5 .11). В этом режиме все процессы одновременно запускаются и после сеанса заканчиваются. Сеанс по времени хорошо вписывается в рабочую смену. Такой режим имеет операционная система OS/2, которая, кстати, нашла свое применение в банкоматах.
Примером таких надстроек являются разработки фирмы On Time Informatik: RTKernel и RTKernel 32. Они предназначены для разработки программного обеспечения в реальном времени, использующего в IBM PC совместимых промышленных контроллеров в среде MS Dos. Эта среда была выбрана по следующим соображениям:
MS DOS является компактной ОС;
легко перестраиваема;
имеет свободное распространение.
Рис. 5.11. Сеанс
Задачи в этой системе являются обычными Паскаль-процедурами или CИ-функциями без параметров, методы создания которых ни чем не отличаются от обычных. При старте запускается одна программа main, которая содержит мультизадачную систему реального времени. После обращения к ядру этой системы путем вызова функций библиотеки RTKernel на основе main формируется главная функция приложения (по сути дела, администратор сеанса). Далее главная задача с помощью функций RTKernel преобразует Паскаль-процедуры или CИ-функции в задачи реального времени (Рис. 5 .12). При этом каждая задача регистрируется в системе как процесс, которому присваивается приоритет и выделяется собственная область стека.
Рис. 5.12. Структура СРВ
В RTKernel 32 примерно такая же схема загрузки и принцип работы. Тем не менее, есть одно принципиальное отличие надстройки для 32–х разрядных приложений от предыдущей – разделение операционной среды на две: среду разработки и среду выполнения (см. разд. 1.4). Это обстоятельство, усложняя разработку этой ОС – надстройки, делает её более мощной. Однако можно определить достаточно широкий класс задач, которые вполне могли быть решены в рамках 16–ти разрядной RTKernel. «Первые пробы пера» целесообразно начинать с разработки именно таких относительно простых систем.
Можно высказать утверждение, что многозадачная система – это такая однозадачная система, в которой роль единственной программы выполняет ядро. Во всяком случае, это утверждение справедливо по отношению к многозадачной надстройке. Она имеет простое ядро, которое практически не тратит на себя системные ресурсы и не может заблокировать работу в реальном времени (см. разд. 1.6). Разумеется, снижается защищенность ОС, но так ли это важно для системы, которая, в основном, предназначена для работы с промышленным оборудованием, а не с многочисленными пользователями, которые имеют разноплановые жизненные интересы. Для таких систем, по понятным соображениям, более актуальна защита корпуса.