Rambler's
Top100

Разработка операционных систем. Выпуск 5

Автор: lonesome [TSH/Digital Daemons]
Дата: 26.05.2003
Раздел: Разработка ОС

ПРЕДЫДУЩИЙ ВЫПУСК      СЛЕДУЮЩИЙ ВЫПУСК

Разработка операционных систем

Выпуск 5

Сегодня в номере:

Работа над ашипками

В прошлом, четвертом выпуске, рассказывая о функции 0x02 прерывания int 0x13 BIOS, я сказал:
"Эта функция нам понадобится только для чтения с дискеты, поэтому можно считать, что номер цилиндра находится в CL, а номер сектора - в CH"

Читать эту фразу следует наоборот - номер цилиндра в CH, а номер сектора - в CL. То есть касательно дискет, таблица параметров для этой функции выглядит вот так:

Представление данных на дисках (продолжение)

В предыдущем выпуске я не упомянул два важных момента:

Отсчет головок, цилиндров ведется с нуля, а секторов с единицы. То есть загрузочный (первый) сектор дискеты - это:
0 (головка) : 0 (цилиндр) : 1 (сектор)
И в дальнейшем, говоря о конкретных секторах на диске я буду использовать представление адреса сектора в виде 3 чисел - X:X:X.

Обычная дискета 1.44 содержит 2880 секторов, 160 цилиндров и 2 головки (точнее головки содержит не дискета, а дисковод). Каждый цилиндр дискеты содержит 18 секторов, а каждая головка - 80 цилиндров.

Системы защиты современных процессоров как краеугольный камень концепции построения операционных систем

Хороший получился заголовок, солидный... Но действительно, все современные операционные системы выглядят именно так, как они выглядят, лишь потому, что во всех современных процессорах (по крайней мере во всех получивших распространение) используются одни и те же принципы защиты. Защита процессора - это совокупность приемов, с помощью которых процессор может контролировать выполнение кода, например:

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

Фирма Intel пошла дальше и в процессорах архитектуры IA-32 используется не два, а аж четыре уровня привилегий, которые именуются кольцами и отсчитываются от нуля до трех. Причем 0 - наиболее привилегированный уровень, а 3 - наименее привилегированный. Можно считать, что 0 - уровень Супервизора, а 3 - уровень Пользователя. Остальные уровни привилегий в принципе не нужны и обычно не используются.

Классический вариант архитектуры ОС таков: ядро системы работает на уровне Супервизора, а пользовательские задачи на уровне Пользователя, причем пользовательские задачи не могут вмешаться в работу друг-друга или ядра, а само ядро (оно же Супервизор) может делать все, что угодно. Именно по такой схеме построены Windows NT, Linux, FreeBSD, OpenBSD, NetBSD

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

Доверительный код - это означает, что Пользователь может выполнять в режиме Супервизора только тот код, который Супервизор разрешит ему выполнять. Внешне это выглядит, как предоставление системой каких-либо функций пользовательским приложениям (часто это называют передачей управления системе, но это не совсем верный, хотя и устоявшийся термин, и мы с вами тоже будем его использовать). Например вызов функции открытия файла open() в UNIX означает, что при передаче управления на точку входа функции open() пользовательская программа получает привилегии Супервизора (благодаря чему становится возможным доступ к диску)
Этот механизм передачи управления системе называется механизмом системных вызовов. О возможных его реализациях мы поговорим в следующий раз, т.к. сегодняшний материал и так достаточно сложен. Если вам что-то непонятно в системе защиты процессоров - пишите, - в ней вы должны обязательно разобраться!

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

У некоторых подписчиков возник вопрос, можно ли использовать при разработке ОС такие языки, как Pascal или C++.

Основная проблема ЯВУ при разработке ОС заключается в том, что с их помощью нельзя контролировать на низком уровне поведение процессора и внешних устройств, поэтому ассемблер нам понадобится в любом случае. Другое дело, что языки высокого уровня обычно имеют возможность вставки ассемблерного кода в исходник, поэтому использование чистого ассемблера можно свести к минимуму (только для загрузчика). Более того, некоторые ОС изолируют весь низкоуровневый код в т.н. HAL (hardware abstraction layer), а вся остальная часть системы написана только на ЯВУ и, следовательно, портабельна на другие архитектуры

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

Outro

На сегодня все, уважаемые подписчики
Как всегда, мой почтовый ящик открыт для вас:
lonesome@lowlevel.ru
Также вы можете задавать интересующие вас вопросы в форуме lowlevel.ru
Всего наилучшего!
Lonesome


ПРЕДЫДУЩИЙ ВЫПУСК      СЛЕДУЮЩИЙ ВЫПУСК

Rambler's Top100