Мобильные ОС
Автор: Пользователь скрыл имя, 02 Мая 2012 в 21:50, реферат
Краткое описание
Работа посвящена проблемам, связанным с переносом прикладных программ (ПП) между различными программно-аппаратными платформами. Под переносимостью ПП понимается возможность использования ПП на различных программно-аппаратных платформах, отличающихся по архитектуре и характеристикам, с сохранением или небольшим изменением функций ПП. Обеспечение переносимости, прежде всего, позволяет сохранить затраты, вложенные в реализацию и апробирование ПП. Переносимость ПП достигается за счет использования соответствующих стандартов.
Оглавление
Введение
Ядро и вспомогательные модули ОС
Виды зависимостей ОС
Реализация переносимости
Заключение
Список используемой литературы
Аннотации к источникам
Файлы: 1 файл
МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ
(ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ)
Кафедра прикладной информатики
Реферат по операционным системам
на тему "мобильные (переносимые) операционные системы"
Выполнил:
студент учебной группы
06-322
Горбунов И.В.
Проверил:
преподаватель каф. 609
Терентьев М.Н.
Москва, 2010
Содержание
1.
Введение
3
2.
Ядро и вспомогательные модули ОС
5
3.
Виды зависимостей ОС
7
4.
Реализация переносимости
13
5.
Заключение
17
6.
Список используемой литературы
18
7.
Аннотации к источникам
18
Введение
Без программного обеспечения любой компьютер — просто бесполезная груда
железа. Именно благодаря программам он может хранить, обрабатывать и искать
информацию и решать множество других важных задач, для которых он
предназначен. Самая главная программа на компьютере — операционная система,
которая управляет всеми системными ресурсами и обеспечивает основу для работы
прикладных программ. ОС представляет собой комплекс управляющих и
обрабатывающих программ, которые, с одной стороны, выступают
как интерфейс между устройствами вычислительной системы и прикладными
программами, а с другой — предназначены для управления устройствами,
управления вычислительными процессами, эффективного
распределения вычислительных ресурсов между вычислительными процессами и
организации надёжных вычислений. В целом система должна скрывать множество
проблем, связанных с низкоуровневой работой аппаратной части компьютера.
Основные функции, возложенные на ОС:
• Выполнение по запросу программ тех достаточно элементарных (низкоуровневых)
действий, которые являются общими для большинства программ и часто
встречаются почти во всех программах (ввод и вывод данных, запуск и остановка
других программ, выделение и освобождение дополнительной памяти и др.)
•
Управление оперативной памятью (распределение между процессами,
организация виртуальной памяти)
• Загрузка программ в оперативную память и их выполнение
•
Стандартизованный доступ к периферийным устройствам (устройства ввода-
вывода)
•
Управление доступом к данным на энергонезависимых носителях (таких
как жёсткий диск, оптические диски и др.), организованным в той или
иной файловой системе
• Обеспечение пользовательского интерфейса
• Сетевые операции, поддержка стека сетевых протоколов
Любая сложная система должна иметь понятную и рациональную структуру, то
есть разделяться на части — модули, имеющие вполне законченное функциональное
назначение с четко оговоренными правилами взаимодействия. Ясное понимание роли
каждого отдельного модуля существенно упрощает работу по модификации и
развитию системы. Напротив, сложную систему без хорошей структуры чаще проще
разработать заново, чем модернизировать.
Функциональная сложность операционной системы неизбежно приводит к
сложности ее архитектуры, под которой понимают структурную организацию ОС на
основе различных программных модулей. Обычно в состав ОС входят исполняемые и
объектные модули стандартных для данной ОС форматов, библиотеки разных типов,
модули исходного текста программ, программные модули специального формата
(например, загрузчик ОС, драйверы ввода-вывода), конфигурационные файлы, файлы
документации, модули справочной системы и т.д.
Большинство современных операционных систем представляют собой хорошо
структурированные модульные системы, способные к развитию, расширению и
переносу на новые платформы. Какой-либо единой архитектуры ОС не существует, но
существуют универсальные подходы к структурированию ОС.
Операционная система является сердцевиной сетевого программного
обеспечения, она создает среду для выполнения приложений и во многом определяет,
какими полезными для пользователя свойствами эти приложения будут обладать. В
связи с этим рассмотрим требования, которым должна удовлетворять современная
ОС.
Ясно, что главным требованием предъявляемым к операционной системе,
является возможность выполнения главных функций: эффективного управления
ресурсами для прикладных программ и предоставление удобного интерфейса
пользователю. Современная ОС, как правило, должна реализовывать
мультипрограммную обработку, виртуальную память, свопинг, поддерживать
многооконный интерфейс, а также выполнять многие другие, совершенно
необходимые функции. Кроме этих функциональных требований к операционным
системам предъявляются не менее важные рыночные требования. К этим требованиям
относятся:
Расширяемость. Код должен быть реализован таким образом, чтобы
можно было легко внести различные дополнения и изменения, если это потребуется, и
при этом не нарушить целостность системы.
Мобильность
1
. Код должен легко переноситься с процессора одного типа
на процессор другого типа и с аппаратной платформы (которая включает наряду с
типом процессора и способ организации всей аппаратуры компьютера) одного типа на
платформу другого типа.
Надежность и отказоустойчивость. Система должна быть защищена
как от внутренних, так и от внешних ошибок, сбоев и отказов - ее действия должны
быть всегда предсказуемыми, а приложения не должны быть в состоянии наносить
вред ОС.
Совместимость. ОС должна иметь средства для выполнения
прикладных программ, написанных для других операционных систем. Кроме того,
пользовательский интерфейс должен быть совместим с существующими системами и
стандартами. Одним из аспектов совместимости является способность ОС выполнять
программы, написанные для более ранних версий данной операционной системы и
для другой аппаратной платформы.
Безопасность. ОС должна иметь средства защиты ресурсов одних
пользователей от других.
Производительность. Операционная система должна обладать настолько
хорошим быстродействием и временем реагирования, насколько это позволяет
аппаратная платформа, на которой она установлена.
1
Под мобильностью операционной системы понимается возможность её использования на
различных программно-аппаратных платформах, отличающихся по архитектуре и
характеристикам, с сохранением или небольшим изменением функций ( архитектура процессора —
это некий набор свойств и качеств, присущий целому семейству процессоров, как правило,
выпускаемому в течение многих лет )
Ядро и вспомогательные модули ОС
Наиболее общим подходом к структуризации операционной системы является
разделение всех ее модулей на две группы:
•
ядро — модули, выполняющие основные функции ОС;
•
модули, выполняющие вспомогательные функции ОС.
Модули ядра выполняют такие базовые функции ОС, как управление
процессами, памятью, устройствами ввода-вывода и т. п. Ядро составляет сердцевину
операционной системы, без него ОС является полностью неработоспособной и не
сможет выполнить ни одну из своих функций.
В состав ядра входят функции, решающие внутрисистемные задачи
организации вычислительного процесса, такие как переключение контекстов,
загрузка/выгрузка станиц, обработка прерываний. Эти функции недоступны для
приложений. Вспомогательные модули ОС оформляются либо в виде приложений
(утилиты и системные обрабатывающие программы), либо в виде библиотек
процедур. Они служат для поддержки приложений, создавая для них так называемую
прикладную программную среду. Приложения могут обращаться к ядру с запросами
— системными вызовами — для выполнения тех или иных действий, например для
открытия и чтения файла, вывода графической информации на дисплей, получения
системного времени и т. д. Функции ядра, которые могут вызываться приложениями,
образуют интерфейс прикладного программирования — API.
При наличии аппаратной поддержки режимов с разными уровнями
полномочий устойчивость ОС может быть повышена путем выполнения функций
ядра в привилегированном режиме, а вспомогательных модулей ОС и приложений —
в пользовательском. Это дает возможность защитить коды и данные ОС и приложений
от несанкционированного доступа. ОС может выступать в роли арбитра в спорах
приложений за ресурсы.
Ядро, являясь структурным элементом ОС, в свою очередь, может быть
логически разложено на следующие слои (начиная с самого нижнего):
машинно-зависимые компоненты ОС;
базовые механизмы ядра;
менеджеры ресурсов;
интерфейс системных вызовов.
В многослойной системе каждый слой обслуживает вышележащий слой,
выполняя для него некоторый набор функций, которые образуют межслойный
интерфейс. На основе функций нижележащего слоя следующий вверх по иерархии
слой строит свои функции — более сложные и более мощные, которые, в свою
очередь, оказываются примитивами для создания еще более мощных функций
вышележащего слоя. Многослойная организация ОС существенно упрощает
разработку и модернизацию системы.
Функции, выполняемые модулями ядра, являются наиболее часто
используемыми функциями операционной системы, поэтому скорость их выполнения
определяет производительность всей системы в целом. Для обеспечения высокой
скорости работы ОС все модули ядра или большая их часть постоянно находятся в
оперативной памяти, то есть являются резидентными.
Ядро является движущей силой всех вычислительных процессов в
компьютерной системе, и крах ядра равносилен краху всей системы. Поэтому
разработчики операционной системы уделяют особое внимание надежности кодов
ядра, в результате процесс их отладки может растягиваться на многие месяцы.
Виды зависимостей ОС
Любая ОС для решения своих задач взаимодействует с аппаратными
средствами компьютера, а именно: средствами поддержки привилегированного
режима и трансляции адресов, средствами переключения процессов и защиты
областей памяти, системой прерываний и системным таймером. Это делает ОС
машинно-зависимой, привязанной к определенной аппаратной платформе.
Машинно-зависимые компоненты ОС
Одна и та же операционная система не может без каких-либо изменений
устанавливаться на компьютерах, отличающихся типом процессора или/и способом
организации всей аппаратуры. В модулях ядра ОС не могут не отразиться такие
особенности аппаратной платформы, как количество типов прерываний и формат
таблицы ссылок на процедуры обработки прерываний, состав регистров общего
назначения и системных регистров, состояние которых нужно сохранять в контексте
процесса, особенности подключения внешних устройств и многие другие.
Однако опыт разработки операционных систем показывает: ядро можно
спроектировать таким образом, что только часть модулей будут машинно-
зависимыми, а остальные не будут зависеть от особенностей аппаратной платформы.
В хорошо структурированном ядре машинно-зависимые модули локализованы и
образуют программный слой, естественно примыкающий к слою аппаратуры - такая
локализация машинно-зависимых модулей существенно упрощает перенос
операционной системы на другую аппаратную платформу.
Объем машинно-зависимых компонентов ОС зависит от того, насколько велики
отличия в аппаратных платформах, для которых разрабатывается ОС. Например, ОС,
построенная на 32-битовых адресах, для переноса на машину с 16-битовыми
адресами должна быть практически переписана заново. Одно из наиболее очевидных
отличий — несовпадение системы команд процессоров — преодолевается достаточно
просто. Операционная система программируется на языке высокого уровня, а затем
соответствующим компилятором вырабатывается код для конкретного типа
процессора. Однако во многих случаях различия в организации аппаратуры
компьютера лежат гораздо глубже и преодолеть их таким образом не удается.
Например, однопроцессорный и двухпроцессорный компьютеры требуют применения
в ОС совершенно разных алгоритмов распределения процессорного времени.
Аналогично отсутствие аппаратной поддержки виртуальной памяти приводит к
принципиальному различию в реализации подсистемы управления памятью. В таких
случаях не обойтись без внесения в код операционной системы специфики
аппаратной платформы, для которой эта ОС предназначается.
Для уменьшения количества машинно-зависимых модулей производители
операционных систем обычно ограничивают универсальность машинно-независимых
модулей. Это означает, что их независимость носит условный характер и
распространяется только на несколько типов процессоров и созданных на основе этих
процессоров аппаратных платформ. По этому пути пошли, например, разработчики
ОС Windows NT, ограничив количество типов процессоров для своей системы
четырьмя и поставляя различные варианты кодов ядра для однопроцессорных и
многопроцессорных компьютеров.
Особое место среди модулей ядра занимают низкоуровневые драйверы
внешних устройств. С одной стороны эти драйверы, как и высокоуровневые
драйверы, входят в состав менеджера ввода-вывода, то есть принадлежат слою ядра,
занимающему достаточно высокое место в иерархии слоев. С другой стороны,
низкоуровневые драйверы отражают все особенности управляемых внешних
устройств, поэтому их можно отнести и к слою машинно-зависимых модулей. Такая
двойственность низкоуровневых драйверов еще раз подтверждает схематичность
модели ядра со строгой иерархией слоев.
Для компьютеров на основе процессоров Intel x86/Pentium разработка
экранирующего машинно-зависимого слоя ОС несколько упрощается за счет
встроенной в постоянную память компьютера базовой системы ввода-вывода —
BIOS. BIOS содержит драйверы для всех устройств, входящих в базовую
конфигурацию компьютера: жестких и гибких дисков, клавиатуры, дисплея и т. д. Эти
драйверы выполняют весьма примитивные операции с управляемыми устройствами,
например чтение группы секторов данных с определенной дорожки диска, но за счет
этих операций экранируются различия аппаратных платформ персональных
компьютеров и серверов на процессорах Intel разных производителей. Разработчики
операционной системы могут пользоваться слоем драйверов BIOS как частью
машинно-зависимого слоя ОС, а могут и заменить все или часть драйверов BIOS
компонентами ОС.
Аппаратная зависимость и переносимость ОС
Многие операционные системы успешно работают на различных аппаратных
платформах без существенных изменений в своем составе. Во многом это объясняется
тем, что, несмотря на различия в деталях, средства аппаратной поддержки ОС
большинства компьютеров приобрели сегодня много типовых черт, а именно эти
средства в первую очередь влияют на работу компонентов операционной системы. В
результате в ОС можно выделить достаточно компактный слой машинно-зависимых
компонентов ядра и сделать остальные слои ОС общими для разных аппаратных
платформ.
Типовые средства аппаратной поддержки ОС
Четкой границы между программной и аппаратной реализацией функций ОС
не существует — решение о том, какие функции ОС будут выполняться программно, а
какие аппаратно, принимается разработчиками аппаратного и программного
обеспечения компьютера. Тем не менее практически все современные аппаратные
платформы имеют некоторый типичный набор средств аппаратной поддержки ОС, в
который входят следующие компоненты:
средства поддержки привилегированного режима;
средства трансляции адресов;
средства переключения процессов;
система прерываний;
системный таймер.
Средства поддержки привилегированного режима обычно основаны на
системном регистре процессора, часто называемом «словом состояния» машины или
процессора. Этот регистр содержит некоторые признаки, определяющие режимы
работы процессора, в том числе и признак текущего режима привилегий. Смена
режима привилегий выполняется за счет изменения слова состояния машины в
результате прерывания или выполнения привилегированной команды. Число градаций
привилегированности может быть разным у разных типов процессоров, наиболее
часто используются два уровня (ядро-пользователь) или четыре (например, ядро-
супервизор- выполнение- пользователь у платформы VAX или 0-1-2-3 у процессоров
Intel x86/Pentium). В обязанности средств поддержки привилегированного режима
входит выполнение проверки допустимости выполнения активной программой
инструкций процессора при текущем уровне привилегированности.
Средства трансляции адресов выполняют операции преобразования
виртуальных адресов, которые содержатся в кодах процесса, в адреса физической
памяти. Таблицы, предназначенные при трансляции адресов, обычно имеют большой
объем, поэтому для их хранения используются области оперативной памяти, а
аппаратура процессора содержит только указатели на эти области. Средства
трансляции адресов используют данные указатели для доступа к элементам таблиц и
аппаратного выполнения алгоритма преобразования адреса, что значительно ускоряет
процедуру трансляции по сравнению с ее чисто программной реализацией.
Средства переключения процессов предназначены для быстрого сохранения
контекста приостанавливаемого процесса и восстановления контекста процесса,
который становится активным. Содержимое контекста обычно включает содержимое
всех регистров общего назначения процессора, регистра флагов операций (то есть
флагов нуля, переноса, переполнения и т. п.), а также тех системных регистров и
указателей, которые связаны с отдельным процессом, а не операционной системой,
например указателя на таблицу трансляции адресов процесса. Для хранения
контекстов приостановленных процессов обычно используются области оперативной
памяти, которые поддерживаются указателями процессора.
Переключение контекста выполняется по определенным командам процессора,
например по команде перехода на новую задачу. Такая команда вызывает
автоматическую загрузку данных из сохраненного контекста в регистры процессора,
после чего процесс продолжается с прерванного ранее места.
Система прерываний позволяет компьютеру реагировать на внешние события,
синхронизировать выполнение процессов и работу устройств ввода-вывода, быстро
переходить с одной программы на другую. Механизм прерываний нужен для того,
чтобы оповестить процессор о возникновении в вычислительной системе некоторого
непредсказуемого события или события, которое не синхронизировано с циклом
работы процессора. Примерами таких событий могут служить завершение операции
ввода-вывода внешним устройством (например, запись блока данных контроллером
диска), некорректное завершение арифметической операции (например, переполнение
регистра), истечение интервала астрономического времени. При возникновении
условий прерывания его источник (контроллер внешнего устройства, таймер,
арифметический блок процессора и т. п.) выставляет определенный электрический
сигнал. Этот сигнал прерывает выполнение процессором последовательности команд,
задаваемой исполняемым кодом, и вызывает автоматический переход на заранее
определенную процедуру, называемую процедурой обработки прерываний. В
большинстве моделей процессоров отрабатываемый аппаратурой переход на
процедуру обработки прерываний сопровождается заменой слова состояния машины
(или даже всего контекста процесса), что позволяет одновременно с переходом по
нужному адресу выполнить переход в привилегированный режим. После завершения
обработки прерывания обычно происходит возврат к исполнению прерванного кода.
Прерывания играют важнейшую роль в работе любой операционной системы,
являясь ее движущей силой. Действительно, большая часть действий ОС
инициируется прерываниями различного типа. Даже системные вызовы от
приложений выполняются на многих аппаратных платформах с помощью
специальной инструкции прерывания, вызывающей переход к выполнению
соответствующих процедур ядра (например, инструкция int в процессорах Intel или
SVC в мэйнфреймах IBM).
Системный таймер, часто реализуемый в виде быстродействующего регистра-
счетчика, необходим операционной системе для выдержки интервалов времени. Для
этого в регистр таймера программно загружается значение требуемого интервала в
условных единицах, из которого затем автоматически с определенной частотой
начинает вычитаться по единице. Частота «тиков» таймера, как правило, тесно
связана с частотой тактового генератора процессора. (Не следует путать таймер ни с
тактовым генератором, который вырабатывает сигналы, синхронизирующие все
операции в компьютере, ни с системными часами — работающей на батареях
электронной схеме, — которые ведут независимый отсчет времени и календарной
даты.) При достижении нулевого значения счетчика таймер инициирует прерывание,
которое обрабатывается процедурой операционной системы. Прерывания от
системного таймера используются ОС в первую очередь для слежения за тем, как
отдельные процессы расходуют время процессора. Например, в системе разделения
времени при обработке очередного прерывания от таймера планировщик процессов
может принудительно передать управление другому процессу, если данный процесс
исчерпал выделенный ему квант времени.
Совместимость и множественные прикладные среды
В то время как многие архитектурные особенности операционных систем
непосредственно касаются только системных программистов, концепция
множественных прикладных сред непосредственно связана с нуждами конечных
пользователей — возможностью операционной системы выполнять приложения,
написанные для других операционных систем. Такое свойство операционной системы
называется совместимостью.
Двоичная совместимость и совместимость исходных текстов
Необходимо различать совместимость на двоичном уровне и совместимость на
уровне исходных текстов. Приложения обычно хранятся в ОС в виде исполняемых
файлов, содержащих двоичные образы кодов и данных. Двоичная совместимость
достигается в том случае, когда можно взять исполняемую программу и запустить ее
на выполнение в среде другой ОС.
Совместимость на уровне исходных текстов требует наличия
соответствующего компилятора в составе программного обеспечения компьютера, на
котором предполагается выполнять данное приложение, а также совместимости на
уровне библиотек и системных вызовов. При этом необходима перекомпиляция
имеющихся исходных текстов в новый исполняемый модуль.
Совместимость на уровне исходных текстов важна в основном для
разработчиков приложений, в распоряжении которых эти исходные тексты всегда
имеются. Но для конечных пользователей практическое значение имеет только
двоичная совместимость, так как только в этом случае они могут использовать один и
тот же коммерческий продукт, поставляемый в виде двоичного исполняемого кода, в
различных операционных средах и на различных машинах. Для пользователя,
купившего в свое время пакет (например, Lotus 1-2-3) для MS-DOS, важно, чтобы он
мог запускать этот полюбившийся ему пакет без каких-либо изменений и на своей
новой машине, работающей под управлением, например, Windows NT.
Обладает ли новая ОС двоичной совместимостью или совместимостью
исходных текстов с существующими операционными системами, зависит от многих
факторов. Самый главный из них — архитектура процессора, на котором работает
новая ОС. Если процессор использует тот же набор команд (возможно, с некоторыми
добавлениями) и тот же диапазон адресов, тогда двоичная совместимость может быть
достигнута довольно просто. Для этого достаточно соблюдения следующих условий:
•
вызовы функций API, которые содержит приложение, должны
поддерживаться данной ОС;
•
внутренняя структура исполняемого файла приложения должна
соответствовать структуре исполняемых файлов данной ОС.
Гораздо сложнее достичь двоичной совместимости операционным системам,
предназначенным для выполнения на процессорах, имеющих разные архитектуры.
Помимо соблюдения приведенных выше условий необходимо организовать эмуляцию
двоичного кода.
Пусть, например, требуется выполнить DOS-программу для IBM PC-
совместимого компьютера на компьютере Macintosh. Компьютер Macintosh построен
на основе процессора Motorola 680x0, а компьютер IBM PC — на основе процессора
Intel 80x86. Процессор Motorola имеет архитектуру (систему команд, состав регистров
и т. п.), отличную от архитектуры процессора Intel, поэтому ему непонятен двоичный
код DOS-программы, содержащей инструкции этого процессора. Для того чтобы
компьютер Macintosh смог интерпретировать машинные инструкции, которые ему
изначально непонятны, на нем должно быть установлено специальное программное
обеспечение — эмулятор.
Эмулятор должен последовательно выбирать каждую двоичную инструкцию
процессора Intel, программным способом дешифрировать ее, чтобы определить, какие
действия она задает, а затем выполнять эквивалентную подпрограмму, написанную в
инструкциях процессора Motorola. Так как к тому же у процессора Motorola нет в
точности таких же регистров, флагов и внутреннего арифметико-логического
устройства, как в Intel, он должен также имитировать (эмулировать) все эти элементы
с использованием своих регистров или памяти. Состояние эмулируемых регистров и
флагов после выполнения каждой команды должно быть абсолютно таким же, как и в
реальном процессоре Intel.
Это простая, но очень медленная работа, так как одна команда процессора Intel
исполняется значительно быстрее, чем эмулирующая его последовательность команд
процессора Motorola.
Трансляция библиотек
Выходом в таких случаях является использование так называемых прикладных
программных сред. Одной из составляющих, формирующих прикладную
программную среду, является набор функций интерфейса прикладного
программирования API, которые операционная система предоставляет своим
приложениям. Для сокращения времени на выполнение чужих программ прикладные
среды имитируют обращения к библиотечным функциям.
Эффективность этого подхода связана с тем, что большинство сегодняшних
программ работают под управлением GUI (графических интерфейсов пользователя)
типа Windows, Mac или UNIX Motif, при этом приложения тратят большую часть
времени, производя некоторые хорошо предсказуемые действия. Они непрерывно
выполняют вызовы библиотек GUI для манипулирования окнами и для других
связанных с GUI действий. Сегодня в типичных программах 60-80 % времени
тратится на выполнение функций GUI и других библиотечных вызовов ОС. Именно
это свойство приложений позволяет прикладным средам компенсировать большие
затраты времени, потраченные на покомандное эмулирование программы. Тщательно
спроектированная программная прикладная среда имеет в своем составе библиотеки,
имитирующие внутренние библиотеки GUI, но написанные на «родном» коде. Таким
образом достигается существенное ускорение выполнения программ с API другой
операционной системы. Иногда такой подход называют трансляцией для того, чтобы
отличать его от более медленного процесса эмулирования кода по одной команде за
раз.
Например, для Windows-программы, работающей на Macintosh, при
интерпретации команд процессора Intel 80x86 производительность может быть очень
низкой. Но когда производится вызов функции GUI открытия окна, модуль ОС,
реализующий прикладную среду Windows, может перехватить этот вызов и
перенаправить его на перекомпилированную для процессора Motorola 680x0
подпрограмму открытия окна. В результате на таких участках кода скорость работы
программы может достичь (а возможно, и превзойти) скорость работы на своем
«родном» процессоре.
Чтобы программа, написанная для одной ОС, могла быть выполнена в рамках
другой ОС, недостаточно лишь обеспечить совместимость API. Концепции,
положенные в основу разных ОС, могут входить в противоречие друг с другом.
Например, в одной операционной системе приложению может быть разрешено
непосредственно управлять устройствами ввода-вывода, в другой — эти действия
являются прерогативой ОС. Каждая операционная система имеет свои собственные
механизмы защиты ресурсов, свои алгоритмы обработки ошибок и исключительных
ситуаций, особую структуру процесса и схему управления памятью, свою семантику
доступа к файлам и графический пользовательский интерфейс. Для обеспечения
совместимости необходимо организовать бесконфликтное сосуществование в рамках
одной ОС нескольких способов управления ресурсами компьютера.
Реализация переносимости
Требование переносимости кода тесно связано с расширяемостью.
Расширяемость позволяет улучшать операционную систему, в то время как
переносимость дает возможность перемещать всю систему на машину,
базирующуюся на другом процессоре или аппаратной платформе, делая при этом по
возможности небольшие изменения в коде. Хотя ОС часто описываются либо как
переносимые, либо как непереносимые, переносимость - это не бинарное состояние.
Вопрос не в том, может ли быть система перенесена, а в том, насколько легко можно
это сделать. Написание переносимой ОС аналогично написанию любого
переносимого кода - нужно следовать некоторым правилам.
Во-первых, большая часть кода должна быть написана на языке, который
имеется на всех машинах, куда вы хотите переносить систему. Обычно это означает,
что код должен быть написан на языке высокого уровня, предпочтительно
стандартизованном, например, на языке С. Программа, написанная на ассемблере, не
является переносимой, если только вы не собираетесь переносить ее на машину,
обладающую командной совместимостью с вашей.
Во-вторых, следует учесть, в какое физическое окружение программа должна
быть перенесена. Различная аппаратура требует различных решений при создании
ОС. Например, ОС, построенная на 32-битовых адресах, не может быть перенесена на
машину с 16-битовыми адресами (разве что с огромными трудностями).
В-третьих, важно минимизировать или, если возможно, исключить те части
кода, которые непосредственно взаимодействуют с аппаратными средствами.
Зависимость от аппаратуры может иметь много форм. Так, например, следует
всячески избегать прямого манипулирования регистрами и другими аппаратными
средствами процессора.
В-четвертых, если аппаратно зависимый код не может быть полностью
исключен, то он должен быть изолирован в нескольких хорошо локализуемых
модулях. Для уменьшения аппаратной зависимости разработчики ОС должны также
исключить возможность использования по умолчанию стандартных конфигураций
аппаратуры или их характеристик. Для осуществления всех необходимых действий по
управлению аппаратурой, представленной этими параметрами, должен быть написан
набор аппаратно-зависимых функций. Каждый раз, когда какому-либо модулю ОС
требуется выполнить некоторое действие, связанное с аппаратурой, он манипулирует
абстрактными данными, используя соответствующую функцию из имеющегося
набора. Аппаратно-зависимый код не должен быть распределен по всей системе.
Изоляции подлежат все части ОС, которые отражают специфику как процессора, так и
аппаратной платформы в целом. Низкоуровневые компоненты ОС, имеющие доступ к
процессору - зависимым структурам данных и регистрам, должны быть оформлены в
виде компактных модулей, которые могут быть заменены аналогичными модулями
для других процессоров. Для снятия платформенной зависимости, возникающей из-за
различий между компьютерами разных производителей, построенными на одном и
том же процессоре (например, MIPS R4000), должен быть введен хорошо
локализованный программный слой машинно-зависимых функций. Например, можно
спрятать аппаратно-зависимую структуру в программно-задаваемые данные
абстрактного типа. Другие модули системы будут работать с этими данными, а не с
аппаратурой, используя набор некоторых функций. Когда ОС переносится, то
изменяются только эти данные и функции, которые ими манипулируют.
Например, в ОС Windows NT диспетчер прерываний преобразует аппаратные
уровни прерываний конкретного типа процессора в стандартный набор уровней
прерываний IRQL, с которыми работают остальные модули операционной системы.
Поэтому при переносе Windows NT на новую платформу нужно переписать, в
частности, те коды диспетчера прерываний, которые занимаются отображением
уровней прерывания на абстрактные уровни IRQL, а те модули ОС, которые
пользуются этими абстрактными уровнями, изменений не потребуют.
В идеале слой машинно-зависимых компонентов ядра полностью экранирует
остальную часть ОС от конкретных деталей аппаратной платформы (кэши,
контроллеры прерываний ввода-вывода и т. п.), по крайней мере для того набора
платформ, который поддерживает данная ОС. В результате происходит подмена
реальной аппаратуры некой унифицированной виртуальной машиной, одинаковой для
всех вариантов аппаратной платформы. Все слои операционной системы, которые
лежат выше слоя машинно-зависимых компонентов, могут быть написаны для
управления именно этой виртуальной аппаратурой. Таким образом, у разработчиков
появляется возможность создавать один вариант машинно-независимой части ОС
(включая компоненты ядра, утилиты, системные обрабатывающие программы) для
всего набора поддерживаемых платформ (рис. 3.9).
Рис. 3.9. Перенос операционной системы на разные аппаратные платформы
Еще одним методом решения проблемы переносимости являются принципы и
технологии открытых систем. Открытая система - это система, реализующая
открытые спецификации на интерфейсы, службы и форматы данных, достаточные для
того, чтобы обеспечить:
• возможность переноса прикладных программ, разработанных должным образом, с
минимальными изменениями на широкий диапазон программно-аппаратных
платформ;
• совместную работу с другими ПП на локальных и удаленных платформах;
• взаимодействие с пользователями в стиле, облегчающем последним переход от одной
программно-аппаратной платформе к другой (мобильность пользователей)
Основой, обеспечивающей возможность реализации открытых систем, является
совокупность стандартов, с помощью которых унифицируется взаимодействие аппаратуры и
всех компонент программной среды: языки программирования, средства ввода/вывода,
графические интерфейсы и т.п.
Одним из средств обеспечения совместимости
программных и пользовательских интерфейсов является соответствие стандартам
POSIX. POSIX (Portable Operating System Interface for Unix — Переносимый
интерфейс операционных систем Unix) — набор стандартов, описывающих
интерфейсы между операционной системой и прикладной программой. Его
использование позволяет создавать программы в стиле UNIX, которые могут легко
переноситься из одной ОС в другую. Стандарт создан для обеспечения
совместимости различных UNIX-подобных операционных систем и переносимости
прикладных программ на уровне исходного кода, но может быть использован и для
не-Unix систем.
Задачи:
• содействовать облегчению переноса кода прикладных программ на иные
платформы;
• способствовать определению и унификации интерфейсов заранее при
проектировании, а не в процессе их реализации;
• сохранить по возможности и учитывать все главные, созданные ранее и
используемые прикладные программы;
• определять необходимый минимум интерфейсов прикладных программ, для
ускорения создания, одобрения и утверждения документов;
• развивать стандарты в направлении обеспечения коммуникационных сетей,
распределенной обработки данных и защиты информации;
• рекомендовать ограничивать использование бинарного (объектного) кода для
приложений в простых системах.
Стандарт состоит из четырёх основных разделов:
•
Основные определения — список основных определений и соглашений,
используемых в спецификациях, и список заголовочных файлов языка Си, которые
должны быть предоставлены соответствующей стандарту системой;
•
Оболочка и утилиты — описание утилит и командной оболочки sh, стандарты
регулярных выражений;
•
Системные интерфейсы — список системных вызовов языка Си;
• Обоснование — объяснение принципов, используемых в стандарте;
Соответствие стандартам POSIX также является средством обеспечения
совместимости программных и пользовательских интерфейсов. Во второй половине
80-х правительственные агентства США начали разрабатывать POSIX как стандарты
на поставляемое оборудование при заключении правительственных контрактов в
компьютерной области. POSIX - это "интерфейс переносимой ОС, базирующейся на
UNIX". POSIX - собрание международных стандартов интерфейсов ОС в стиле UNIX.
Использование стандарта POSIX (IEEE стандарт 1003.1 - 1988) позволяет создавать
программы стиле UNIX, которые могут легко переноситься из одной системы в
другую.
Заключение
Для легкого переноса ОС при ее разработке должны быть соблюдены
следующие требования:
•
Переносимый язык высокого уровня. Большинство переносимых ОС
написано на языке С стандарта ANSI 1989. Разработчики выбирают С потому, что он
стандартизован и что С-компиляторы широко доступны. Низкоуровневые языки
(ассемблер) используются только для тех частей системы, которые должны
непосредственно взаимодействовать с аппаратурой (при обработке прерываний) или
для частей, которые требуют максимальной скорости (целочисленная арифметика
повышенной точности). Однако непереносимый код должен быть тщательно
изолирован внутри тех модулей, где он используется.
•
Изоляция платформы. Зависимость от платформы заключается в
различиях между рабочими станциями разных производителей, построенными на
одном и том же процессоре. Должен быть введен программный уровень,
абстрагирующий аппаратуру (кэши, контроллеры прерываний ввода-вывода и т. п.)
вместе со слоем низкоуровневых программ таким образом, чтобы код высокого
уровная не нуждался в изменении при переносе с одной платформы на другую.
Некоторые низкоуровневые части системы должны иметь доступ к процессорно-
зависимым структурам данных и регистрам. Однако код, который делает это, должен
содержаться в небольших модулях, которые могут быть заменены аналогичными
модулями для иных процессоров.
•
Принцип независимости программ от внешних устройств. Этот принцип
в настоящее время реализуется в подавляющем большинстве современных
операционных систем общего назначения. Он заключается в том, что связь программ
с конкретными устройствами производится не на уровне трансляции программ, а в
период планирования ее исполнения. При работе с новым устройством для работы с
данными не требуется новая компиляция. Это позволяет одинаково осуществлять
действия по управлению внешними устройствами независимо от конкретных
характеристик. Смена носителя и данных, размещенных на нем, не принесет каких-
либо изменений в программу, если в системе реализован принцип независимости.
Список используемой литературы
1.
Таненбаум Э. Операционные системы. Разработка и реализация. /
Э. Таненбаум, А. Вудхалл — 3-е изд. - СПб.: Питер, 2007
2.
Корниенко В.Н. Тестрирование переносимости прикладных программ /
В. Н. Корниенко, А. Я. Олейников, В.А. Черепенин ; Институт радиотехники и
электроники РАН — 2010
3.
Олифер Н.А. Сетевые операционные системы / Н.А. Олифер,
В.Г. Олифер - СПб.: Питер, 2001
Аннотации к источникам
1.
В книге подробно описываются процессы и межпроцессорное
взаимодействие, семафоры, мониторы, передача сообщений, алгоритмы работы
планировщика, ввод/вывод, разрешение тупиковых ситуаций, драйверы устройств,
алгоритмы управления памятью, разработка файловых систем, а также затрагиваются
вопросы безопасности и защиты данных.
2.
Работа посвящена проблемам, связанным с переносом прикладных
программ (ПП) между различными программно-аппаратными платформами. Под
переносимостью ПП понимается возможность использования ПП на различных
программно-аппаратных платформах, отличающихся по архитектуре и
характеристикам, с сохранением или небольшим изменением функций ПП.
Обеспечение переносимости, прежде всего, позволяет сохранить затраты, вложенные
в реализацию и апробирование ПП. Переносимость ПП достигается за счет
использования соответствующих стандартов.
3.
Эта книга - не о конкретной системе и даже не о конкретном типе
операционных систем. Она рассматривает фундаментальные концепции и принципы
построения, справедливые для большинства известных на сегодня операционных
систем.
Информация о работе Мобильные ОС