 |
Структура системы и ядро классической Unix.
|
|
|
|
Эти ОС имеют монолитные ядра. Классическая Unix 7 представляет собой двухуровневую ОС, в центре которой ядро, вокруг которого находятся: системные услуги (init, inetd, routed, getty (терминал), lp (принтер), сс (система разработки), XDesktop shell (пользователь)) и приложения. Ядро предоставляет базовые услуги.
Ядро непосредственно взаимодействует с аппаратурой, имеет набор услуг, предоставляемых прикладным программам. К услугам ядра относятся операции ввода/вывода, создание и управление процессами, их синхронизация и межпроцессорное взаимодействие. Все приложения запрашивают услуги ядра посредством системных вывозов.
Приложения, как системные, определяющие функциональность системы, так и прикладные, обеспечивающие пользовательский интерфейс, составляют второй уровень.
Init отвечает за инициализацию системы, swapper – за перемещение процессов между физической памятью и диском.
Интерфейс системного вызова позволяет процессам обращаться с запросами на услуги ОС.
Модули символьного и блочного ввода/вывода, драйверы устройств используются при реализации ФС и для доступа к устройствам.
Буферный кэш отвечает за кэширование данных, над которыми выполняются блочные операции ввода/вывода, повышает производительность системы.
ФС управляет иерархическим пространством имен файлов, каталогов и устройств ввода/вывода.
Модуль управления памятью поддерживает виртуальную память.
Модуль управления процессами отвечает за создание и планирование процессов, прекращение их работы и поддержку базовых средств их взаимодействия.
Управление процессами.
Процессом в Unix называется единица исполнения программного кода. Процесс может выполняться в одном из двух состояний: пользовательском и системном.
|
|
|
Когда пользовательскому процессу требуется выполнить системную функцию, он делает системный вызов. С этого момента процесс считается системным. Таким образом пользовательский и системный процесс являются фазами одного процесса, но никогда не пересекаются. Каждая фаза пользуется собственным стеком. Каждому процессу выделяется свое адресное пространство, разделенное на 2 части:
| Сегмент текста | Доступно пользователю | Область процесса | 3 Гб |
| Сегмент данных | |||
| Сегмент стека | |||
| Стек ядра | |||
| Область данных процесса | |||
| Ядро Unix | Общая область | 1 Гб |
Ядро Unix всегда находится по одним и тем адресам, диспетчер блокирует их, когда процесс выполняется в пользовательском режиме. Доступная пользователю адресная часть делится на 3 части: сегмент текста, сегмент данных, сегмент стека.
Сегмент текста содержит машинные команды, представляющие текст программ, создается компилятором при трансляции с ЯПВУ, разрешен только для чтения, не изменяется ни в размерах, ни по содержанию. Может использоваться совместно с другими процессами для выполнения общей программы.
Сегмент данных содержит переменные, строки, массивы, другие данные программы, может модифицироваться.
Сегмент стека служит для хранения временных данных. Когда программа запускается, её стек уже не пуст, содержит переменные окружения, а также командную строку, введенную при вызове программы.
Каждый процесс может иметь свою область в области данных ядра. Здесь хранятся записи об открытых дескрипторах файла, о том, сколько времени ЦП использовал процесс, как процесс должен реагировать на каждый вид сигнала и т.д. Здесь же хранятся таблицы страниц, которые содержат сведения о размещении страниц памяти процесса.
Система управления памятью позволяет выполняться процессам, которые больше полной емкости ОЗУ компьютера. Для этого она делит области ОЗУ на страницы. Размер страницы устанавливается равным размеру блока диска.
|
|
|
В ОС Unix традиционно выполняются 2 системных процесса init и swapper. Все остальные процессы являются дочерними от init. Любой новый процесс создается с помощью вызова fork (). В ответ на вызов Unix создает новое адресное пространство с полной копией содержимого адресного пространства родительского процесса, а затем в адресное пространство с помощью системного вызова execve () может быть загружено для выполнения программы. Таким образом обновляется сегмент текста и данных.
23 мая 2012 г.
ОС Windows.
История.
MS–DOS, MS–DOS + Windows 3.1
Windows 95, 98, ME.
Windows NT, 2000, XP, 2003, Vista, 2008, 7, 2008 R2.
MS–DOS – 1981 год – однозадачная, 16-разрядная.
Windows 3.0, 3.1, 3.11 – 16-разрядные.
Windows 95 – 32-разрядная, вытесняющая многозадачность.
Windows NT – работу над ней возглавил Дэвид Катлер. Появляется система управления большим адресным пространством, система приоритетов обычных процессов и процессов реального времени, средства синхронизации. Windows NT 3.1 – 1993 год, Windows NT 4.0 – 1995 год – графический интерфейс перенесен из 95.
Windows 2000 – 1999 год.
Windows XP – 2001 год.
Windows Server 2003 – 2003 год.
Windows Vista – 2006 год.
Windows 2008 – 2008 год.
Windows 7 – 2009 год.
Windows 2008 R2 – 2009 год.
Часть 3.
Структура ОС Windows.
Она имела первоначально микроядерный дизайн. Потом стали использовать гибридную архитектуру. Платформы – Intel, Alpha (DEC), Power PC (IBM), MIPS (Silicon Graphics).
В ОС существует компоненты, которые работают как в режиме ядра, так и в режиме пользователя.
Упрощенная схема ОС Windows.
| Режим пользователя | Служебные процессы | Приложения Win32 | Серверный процесс |
| DLL подсистемы Win32 | |||
| Интерфейс системных вызовов | |||
| Режим ядра | Поддержка окон и графики Исполнительная система Драйверы устройств, Ядро Уровень абстрагирования от оборудования Аппаратное обеспечение |
Hardware Abstraction Layer (уровень абстрагирования от оборудования) – скрыть различия аппаратных архитектур для потенциального переноса системы с одной платформы на другую. Этот уровень предоставляет вышележащим уровням аппаратные устройства в абстрактном виде.
Ядром обычно называют все компоненты ОС, работающие в привилегированном режиме работы процессора. Корпорация Microsoft называет ядром компонент, находящийся в невыгружаемой памяти и содержащий низкоуровневые функции ОС, такие, как диспетчеризация прерываний и исключений, планирование потока и т.д.
|
|
|
Эти 2 компонента написаны на языках Си и Ассемблера, остальные – на языке Си.
Драйверы устройств содержат аппаратно-зависимый код, обеспечивают трансляцию пользовательских вызовов в запросы, специфичные для конкретных устройств.
Исполнительная система обеспечивает управление памятью, процессами и потоками, защиту, ввод/вывод и взаимодействие между процессами.
Подсистема поддержки окон и графики реализует функции пользовательского интерфейса.
В пространстве пользователя работают сервисы, управляемые диспетчером сервисов и решающие различные системные задачи.
Среду для выполнения пользовательских процессов предоставляют 3 подсистемы: Win32, POSIX, OS/2.
Основные компоненты реализованы в следующих системных файлах, находящихся в каталоге system32.
1. ntoskrn.exe – исполнительная система и ядро.
2. ntdll.dll – внутренние функции поддержки и диспетчер системных сервисов, функции исполнительной системы.
3. hal.dll – уровень абстрагирования.
4. win32k.sys – часть подсистемы win32, работающая в режиме ядра.
5. kernel32.dll, advapi32.dll, user32.dll, gdi32.dll.
Подсистема win32.
Взаимодействие между приложениями и ОС осуществляется с помощью системных вызовов, однако, приложение не может произвести системный вызов напрямую, вместо этого оно должно воспользоваться программным интерфейсом win32 API – основный интерфейс программирования в ОС Windows. Функции – документированные вызываемые подпрограммы, например CreateProcess, CreateFile. Состав – серверный процесс csrss.exe, драйверы режима ядра win32k.sys, dll-модули подсистемы. Приложение, ориентированное на win32 API, может работать практически на всех версиях Windows. При запуске процесса все требуемые динамические библиотеки отображаются в виртуальном адресном пространстве, а для быстрого вызова используется специальный вектор передачи.
|
|
|
При вызове приложений одной из win32-функций может возникнуть одна из 3 ситуаций:
- Функция полностью выполняется внутри библиотеки.
- Для выполнения функции привлекается сервис csrss.exe.
- Вызов транслируется в системный вызов, который обычно обрабатывается в модуле ntdll.dll.
В первый версиях практически все вызовы выполняют по второй ситуации. После того, как существенная часть кода была перенесена в ядро, то вызовы идут, как правило, по третьей ситуации. Помимо перечисленных библиотек system32 содержит огромное количество других библиотек. В настоящее время количество вызовов API составляет несколько десяткой тысяч. Список экспортированных функций можно посмотреть с помощью утилиты depends, которая содержится в Platform SDK.
25 мая 2012 г.
|
|
|
