Ядро в привилегированном режиме.

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

Ядро находится в оперативной памяти и управляет работой комп и не зависимо от того какая программа работает ядро перехватывает управление на себя.

Такой режим не может быть обеспечен без аппаратной поддержки.

User mode – пользовательский режим

Kernel mode – режим ядра( привилегированный режим )

Ядро работает в привилегированном режиме, а приложения в пользовательском режиме.

Доступ к памяти, распределение памяти, перераспределение памяти выполняется в привел режиме.

ОС могут использовать до 4 режимов (OS-2 (3реж), WIN (2реж))

Пример: Приложение работает в UM нужно записать в память –> переключается управление на ядро

Novell Netware – сервер ОС ( ядро и мод раб в привел режиме => операции в файлах выполняются быстро)

Многослойная структура ОС.

когда делят на слои, между слоями появляется интерфейс.

Сист ПО, Утилиты

Интерфейс

Ядро ОС

Интерфейс

Аппаратная часть

Интерфейс – описание как один слой связывается с друним.

Слои ядра ОС

  1. Средства аппаратной поддержки ОС (сист привилегий, прерываний, средства перекл контекстов проц, ср защиты обл памяти)
  2. Машино зависимые компоненты ОС
  3. Базовый механизм ядра
  4. Менеджеры ресурсов (упр памятью, приним реш и прогнозируют, по выд опер пам, но память выд базов мен)
  5. Интерфейсы сист вызовов (взаимод с прилож сист утилит в этом слое нах прикладной прогр интерфейс)

Типовые средства аппаратной поддержки.

  1. Средства поддержки привил режима
  2. Ср-ва трансляции адресов
  3. Ср-ва переключения процесса (ОС выполняет переключение между процессами)
  4. Сист прерываний (если с какого-либо оборудования получен сигн …)
  5. Сист таймер (быстродейств рег в который загр число и сист таймер -1 (с част процесс) (ф-я точный отсчет времени)
  6. Ср-ва защиты областей памяти

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

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

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

Во-вторых, следует учесть, в какое физическое окружение программа должна быть перенесена. Различная аппаратура требует различных решений при создании ОС. Например, ОС, построенная на 32-битовых адресах, не может быть перенесена на машину с 16-битовыми адресами (разве что с огромными трудностями).

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

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

Для легкого переноса ОС при ее разработке должны быть соблюдены следующие требования:

* Переносимый язык высокого уровня. Большинство переносимых ОС написано на языке С (стандарт ANSI X3.159-1989). Разработчики выбирают С потому, что он стандартизован, и потому, что С-компиляторы широко доступны. Ассемблер используется только для тех частей системы, которые должны непосредственно взаимодействовать с аппаратурой (например, обработчик прерываний) или для частей, которые требуют максимальной скорости (например, целочисленная арифметика повышенной точности). Однако непереносимый код должен быть тщательно изолирован внутри тех компонентов, где он используется.

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

* Изоляция платформы. Зависимость от платформы заключается в различиях между рабочими станциями разных производителей, построенными на одном и том же процессоре (например, MIPS R4000). Должен быть введен программный уровень, абстрагирующий аппаратуру (кэши, контроллеры прерываний ввода-вывода и т. п.) вместе со слоем низкоуровневых программ таким образом, чтобы высокоуровневый код не нуждался в изменении при переносе с одной платформы на другую.





©2015-2017 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.


ТОП 5 активных страниц!

...