6. Системні виклики для управління часом

Для роботи з системним годинником MINIX 3 підтримує чотири системних

виклику. Виклик time повертає поточний час в секундах, причому нулем вважається

опівночі 1 січня 1970 року (мається на увазі початок дня, а не його кінець). Крім

того, щоб зчитувати значення системного таймера, потрібно мати можливість

спочатку це значення встановити. Можливість встановити годинник дає виклик

stime, доступний тільки суперкористувачеві. Третій виклик - utime, він

дозволяє власнику файлу змінити значення часу, записане в індексному вузлі

файлу. У цього виклику досить обмежена область застосування, але

деяким програмам він потрібен, наприклад, програма touch встановлює час

в індексному вузлі файлу у відповідність з поточним часом.

Нарешті, виклик times дозволяє дізнатися, скільки часу процесор провів,

виконуючи процес, і скільки часу витрачено на систему (тобто на обробку

системних викликів). Крім того, підсумовується і повертається загальний час

системи та процесу для всіх дочірніх процесів.

5. Структура операційної системи

Тепер, коли ми дізналися, як виглядають операційні системи зовні (тобто

ми познайомилися з програмним інтерфейсом), саме час заглянути всередину.

Щоб отримати уявлення про весь спектр можливих варіантів, у наступних

наступних розділах ми досліджуємо п'ять існуючих (або використовувалися раніше)

структур. Дослідження це не можна назвати всебічним, тут лише розглядають

розглядаються кілька моделей, що застосовувалися на практиці в різних системах.

Їх п'ять - монолітні системи, багаторівневі системи, віртуальні

машини, екзоядра і модель клієнт-сервер.

1.5.1. Монолітні системи

У загальному випадку організація монолітної системи являє собою «великий

хаос ». Тобто структура як така відсутня. Операційна система

пишеться у вигляді набору процедур, кожна з яких може викликати інші, коли їй

це потрібно. При використанні такої техніки кожна процедура системи має

строго певний інтерфейс в термінах параметрів і результатів і кожна

має можливість викликати будь-яку іншу процедуру для виконання

деякої необхідної для неї роботи.

Для побудови монолітної системи необхідно скомпілювати всі окремі

окремі процедури, а потім зв'язати їх в єдиний об'єктний файл за допомогою

компонувальника. Тут, по суті, зовсім не ховаються деталі реалізації -

кожна процедура бачить будь-яку іншу процедуру (на відміну від структури,

містить модулі, в яких велика частина інформації є локальною

для модуля, і процедури модуля можна викликати тільки через спеціально

певні точки входу).

Однак навіть такі монолітні системи можуть мати деяку структуру. При

системних викликах, підтримуваних операційною системою, параметри поміщаються в строго певні місця - регістри або стек, після чого виконується спеціальна інструкція перехоплення, відома як виклик ядра, або виклик супервізора.

Ця інструкція перемикає машину з режиму користувача в режим ядра

і передає управління операційній системі. У більшості процесорів

є два режими роботи: режим ядра, призначений для ОС, і

користувальницький режим, в якому заборонений введення-виведення і деякі інші

інструкції.

Тепер саме час подивитися на те, як виконуються системні виклики.

Згадаймо, що виклик read виглядає наступним чином:

count = read (fd, buffer, nbytes);

Перед викликом бібліотечної процедури read, фактично здійснює

системний виклик read, що викликає програма спочатку поміщає параметри

в стек (кроки 1-3 на рис. 1.12). В силу історичних причин компілятори

мов С і C розміщують параметри в зворотному порядку (справа в тому, що при

передачі параметрів функції print f першою в стеку повинна розташовуватися

форматна рядок). Перший і третій параметри передаються за значенням, а другий - по

посиланням. Це означає, що процедура read отримує адресу буфера (указується

знаком &), а не його вміст. Далі (на кроці 4) здійснюється фактичний

виклик бібліотечної процедури. Дана інструкція нічим не відрізняється від

звичайних викликів процедур.

Рис. 1.12. Виконання системного виклику read (fd, buffer, nbytes) за 11 кроків

Бібліотечна процедура, можливо, написана на мові асемблера, зазвичай п

поміщає номер системного виклику туди, куди вимагає операційна система

(Наприклад, в регістр, як показано на кроці 5). Потім процедура виконує інструкцію

trap, щоб переключитися з режиму користувача в режим ядра і почати

виконання з певного адреси всередині ядра (крок б). Запущений код ядра

аналізує номер системного виклику і вибирає для нього відповідний

обробник, як правило, за допомогою таблиці покажчиків на обробники

системних викликів, індексується за номером системного виклику (крок 7). Потім

обраний обробник запускається (крок 8). По завершенні його роботи управління

може бути повернуто бібліотечної процедурою та передано інструкції,

наступної за trap (крок 9). Процедура, в свою чергу, повертає управління

програмі користувача так само, як будь-яка інша процедура (крок 10).

На завершення програма користувача повинна очистити стек: це дія

завжди виконується після повернення з процедури (крок 11). Припускаючи, що стек

зростає зверху вниз, як це зазвичай буває, скомпільований код збільшує

покажчик стека (Stack Pointer, SP) рівно настільки, щоб видалити з нього

параметри, поміщені перед викликом read. Після цього програма може сміливо

приступати до виконання наступних дій.

Описуючи крок 9, ми навмисно сказали, що управління «може бути

повернуто бібліотечної процедурою ». Справа в тому, що системний виклик здатний

блокувати виконання викликав процесу. Наприклад, якщо виклик повинен вважати

введення з клавіатури, але користувач нічого не вводить, що викликав процес

підлягає блокуванню. У цьому випадку операційна система спробує знайти

процес, який можна виконати в утворилася паузі. Коли очікуваний

введення, нарешті, станеться, система повернеться до обробки блокованого

процесу і виконає кроки 9-11.

Така організація операційної системи передбачає наступну структуру:

♦ Головна програма, яка викликає необхідну службову процедуру.

♦ Набір службових процедур, що виконують системні виклики.

♦ Набір утиліт, що обслуговують службові процедури.

У цій моделі для кожного системного виклику є одна службова

процедура. Утиліти виконують функції, які потрібні декільком службовим процедурам.