Требования к ОС и подходы к реализации

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Архитектору Инженеру

Вступление

Когда говорят «нужна операционная система», редко уточняют — какая именно и зачем. Серверу важны стабильность и учёт ресурсов; игровому ПК — драйверы GPU и низкая задержка ввода; встраиваемому контроллеру — предсказуемость в миллисекундах и малый размер образа.

Требования к ОС — это список того, что система обязана делать (функции) и как хорошо (качество). Подход к реализации — как архитекторы раскладывают эти требования по ядру, драйверам и пользовательским сервисам.

Эта статья связывает «учебниковый» взгляд с материалами энциклопедии: определение ОС, архитектура ядра, история.

---

Функциональные требования

Функциональные требования отвечают на вопрос: что ОС должна уметь?

Область	Примеры требований	Где раскрыто в энциклопедии
Управление процессором	Многозадачность, планирование, приоритеты	5115, 5117
Управление памятью	Виртуальная память, защита, разделяемые сегменты	5116, 5112
Файлы и хранение	Иерархия каталогов, права, журналирование	411, 1.md
Ввод-вывод	Драйверы, унифицированный API	5120, 3.md
Безопасность	Пользователи, группы, изоляция	5115, 3.md
Сеть	Стек протоколов, сокеты	1.md, раздел 2-03
Взаимодействие	IPC: pipe, shm, сигналы	5115, 5118

Минимальный набор для «универсальной» ОС

1. Абстракция процессора — программа не назначает себе ядра вручную; есть планировщик.
2. Виртуальная память — каждый процесс в своём адресном пространстве.
3. Файловая система — долговременное хранение с именами и правами.
4. Доступ к устройствам — через драйверы, а не прямую запись в порты из приложения.
5. Защита — режим ядра / пользователя, проверка прав на операции.

Без любого из этих пунктов система либо небезопасна, либо неудобна для переносимых программ.

---

Нефункциональные требования

Нефункциональные требования описывают качество работы.

Производительность

• Пропускная способность (throughput) — сколько заданий в единицу времени (транзакций, Мб/с).
• Время отклика (response time) — задержка от действия пользователя до реакции.
• Масштабируемость — рост производительности при добавлении CPU/RAM (идеально линейный, на практике — нет из-за NUMA, блокировок).

ОС влияет на все три: планировщик, кэш страниц, алгоритмы I/O. См. планирование, замещение страниц.

Надёжность и доступность

• Отказоустойчивость — сбой приложения не роняет всю систему.
• Восстановление после сбоя — журналы ФС, fsck, откат транзакций.
• Доступность 99.9%+ — кластеры, live patching ядра (см. ядро).

Монолитное ядро: быстрее вызовы внутри ядра, но сбой в драйвере опаснее. Микроядро: изоляция сервисов, выше накладные расходы на IPC.

Безопасность

• Конфиденциальность — процесс A не читает память B.
• Целостность — нельзя подменить системные файлы без прав.
• Доступность — защита от DoS (лимиты ресурсов, cgroups).

Современные механизмы: ASLR, NX-бит, SELinux/AppArmor, Secure Boot — в ядре и безопасности.

Удобство сопровождения и переносимость

• Переносимость приложений — POSIX, Win32 API, ABI.
• Обновляемость — пакетные менеджеры, откат, LTS-релизы (жизненный цикл в 1.md).
• Наблюдаемость — логи, /proc, eBPF, Performance Monitor.

Стоимость и ресурсы

Для встраиваемых систем критичны размер образа, потребление RAM, энергия. Там часто отказываются от подкачки, выбирают RTOS или урезанный Linux (Buildroot, Yocto).

---

Требования разных классов систем

Класс	Приоритеты	Типичная реализация
Десктоп	Отклик UI, драйверы, совместимость	Windows, macOS, Linux + DE
Сервер	Throughput, стабильность, сеть	Linux, Windows Server
Мобильная	Энергия, безопасность приложений	Android, iOS
Встраиваемая	Детерминизм, малый размер	FreeRTOS, Zephyr, Embedded Linux
Критическая инфраструктура	Сертификация, изоляция	QNX, KasperskyOS, отдельные домены на гипервизоре

Один и тот же Linux настраивается под разные профили: Android — другой набор подсистем и политик power management, чем Ubuntu Server.

---

Подходы к реализации — архитектура ядра

Требования «изоляция» и «скорость» тянут в разные стороны. Основные архитектурные подходы (подробно в 3.md):

Подход	Суть	Когда выбирают
Монолитное ядро	Драйверы и FS в адресном пространстве ядра	Максимальная производительность (Linux, Windows NT)
Микроядро	В ядре — минимум; драйверы в user space	Безопасность, сертификация (QNX, seL4)
Гибридное	Микроядро + «тяжёлые» сервисы в kernel mode	Компромисс (Windows NT, XNU)
Экзоядро	Приложения сами строят абстракции поверх ресурсов	Исследования, спецзадачи
Unikernel	Одно приложение + минимальная ОС в одном образе	Облако, микросервисы с малым overhead

Контейнер ≠ микроядро

Docker не «новая ОС». Это изоляция процессов средствами существующего ядра Linux (namespaces, cgroups). Требование «быстрый старт приложения» решается на уровне замены ядра.

---

Подходы к реализации подсистем

Планирование CPU

• Статическое — фиксированные приоритеты (RTOS).
• Динамическое — меняется по поведению (интерактив vs batch).
• Справедливое — CFS в Linux (см. 5117).

Память

• Страничная — доминирует (4 KiB, huge pages).
• Сегментная — исторически x86, сегодня чаще в гибриде с paging.
• Подкачка — файл swap / pagefile; политика swappiness.

Синхронизация

• Примитивы ядра: mutex, semaphore, futex (Linux).
• Примитивы POSIX для приложений; ядро обеспечивает блокировку и пробуждение.
• См. 5118, 5119.

Ввод-вывод

• Слоистая модель: syscall → VFS / block layer → драйвер → DMA.
• Синхронный и асинхронный I/O; очереди (io_uring).
• См. 5120.

---

Как сформулировать требования на практике

Пример чек-листа для выбора ОС под сервис:

1. Нужен ли жёсткий дедлайн ответа? → RTOS или tuning GPOS.
2. Сколько изоляции между компонентами? → ВМ, контейнеры, отдельные пользователи.
3. Какой стек (Java, .NET, Go) и лицензии?
4. Есть ли аппаратная поддержка (ARM, x86, GPU, TPM)?
5. Кто обновляет ядро и когда допустим reboot?

Для учебного проекта достаточно явно записать: «GPOS, многопользовательская, виртуальная память, TCP/IP, ext4/NTFS» — и сопоставить с классификацией.

---

Связь с остальным разделом

Рекомендуемый порядок после этой статьи:

1. История ОС — откуда взялись требования.
2. Ядро — как требования воплощаются в архитектуре.
3. Подсистемы: процессы → синхронизация → тупики → память → I/O.

Чек-лист самопроверки дополнен вопросами по требованиям и архитектурам.

---