MINIX 3 — проект по созданию небольшой высоконадёжной и функциональной Unix-подобной операционной системы. Он был опубликован под лицензией BSD и является наследником ранее созданных операционных систем MINIX 1 и MINIX 2.
Главной целью проекта является создание отказоустойчивой системы, способной обнаруживать и исправлять собственные ошибки «на лету» без непосредственного вмешательства пользователя. В основном, предполагалось использовать операционную систему во встраиваемых системах и образовании.«LWN.net.» LWN: MINIX 3 hits the net. 28 Oct 2005. Eklektix, Inc.. 4 Jul 2006 .
MINIX 3 в настоящее время поддерживает IA-32 архитектуру PC-совместимых компьютеров. Кроме того, возможен запуск MINIX под эмуляторами и виртуальными машинами, такими как Bochs,Woodhull, Al. Getting Started with Minix on Bochs on Mac OS. 20 Feb 2003. 8 Jul 2006 .Senn, Will. «OSNews.com.» Virtually Minix: A Tutorial & Intro to Minix on XP via Bochs — OSNews.com. 08 Jul 2006. OSNews.com. 8 Jul 2006 . VMware Workstation,Wagstrom, Patrick. Minix under VMWare Installation How-To. 8 Jul 2006 . Microsoft Virtual PC и QEMU. Порты для архитектур ARM и PowerPCAlting, Ingmar A. MinixPPC: A port of MINIX 3 to the PowerPC platform, 15 Sep 2006. находятся в разработке.
В 2026 году был опубликован независимый форк MINIX 3 под названием MEECHO, предназначенный для 64-битной архитектуры AArch64. Согласно документации проекта, система загружается в QEMU и на одноплатном компьютере BIGTREETECH CB2 на базе Rockchip RK3566.
Распространяется в виде образа операционной системы, загружаемой со сменного носителя (Live CD).
Цели проекта
Учитывая природу систем, основанных на монолитном ядре, где драйвер (который содержит, по словам создателя MINIX 3 Таненбаума, примерно в 3-7 раз большее количество ошибок, чем обычная программа) может обрушить всю систему,Tanenbaum, Andrew. CSAIL Event Calendar. 25 Aug 2006 . MINIX 3 направлен на создание такой операционной системы, которая была бы «надежным, самовосстанавливающимся и многосерверным UNIX-клоном».Tanenbaum, Andrew. «Tanenbaum-Torvalds debate, Part II:.» 12 May 2006. Vrije Universiteit. 15 Jun 2006 .
Чтобы достичь этого, код, выполняющийся в режиме ядра, должен быть минимальным, а файловый сервер, сервер процессов и каждый драйвер устройства должны выполняться как отдельные процессы в пользовательском режиме. Каждый драйвер тщательно контролируется частью системы, известной как сервер восстановления. Если драйвер не реагирует на пинги от сервера восстановления, то он закрывается и заменяется новой копией.
В монолитной системе ошибка в драйвере может привести к разрушению всего ядра, что значительно менее вероятно в MINIX 3.Tanenbaum, Andrew S.. «Reliability.» The MINIX 3 Operating System. Vrije Universiteit. 22 Jun 2006
История MINIX 3 был анонсирован 24 октября 2005 года Эндрю Таненбаумом во время его вступительной речи на симпозиуме о принципах операционных систем ACM. Хотя MINIX 3 все ещё служит в качестве примера для нового издания книги Таненбаума и Вудхалла, он все же был переработан, чтобы быть «удобным в использовании как надёжная операционная система для встраиваемых устройств и устройств с ограниченными ресурсами, для задач, требующих высокой надёжности».
Version Release date Description 3.1.02005-10-24 Первый релиз MINIX 3 (Выпуск книги) 3.1.2a2006-05-29 Новый менеджер пакетов Packman Исправлена проблема установки с автоматическим разбиением дисков 3.1.32007-04-13 Добавлена новая виртуальная файловая система 3.1.3a2007-06-08 Исправление ошибок 3.1.42009-06-09 Поддержка виртуальной памяти Улучшена поддержка виртуальной машины (где MINIX запускается как гость) 3.1.52009-11-05 Улучшение производительности Разделяемая память Функция setitimer Файловая система ISO 9660 Open Sound System Ловушка доступа к неинициализированным указателям NULL для удобства пользователя Улучшена обработка сигналов Лучшая поддержка для отладчиков (усовершенствованный ptrace и др.) Автоопределение сетевых карт (для поддерживаемых PCI-карт), улучшение конфигурации сети 3.1.62010-02-08 Новые сетевые драйверы: Atheros L2, Intel E1000, Realtek 8169, DEC Tulip PipeFS — removed pipe handling from filesystem drivers HGFS — поддержка для монтирования общих папок VMware как файловой системы VFS: supplemental group support и поддержка атрибута sticky bit Поддержка математического сопроцессора Фрэймворк системных событий (SEF) Экспериментальная поддержка APIC 3.1.72010-06-16 Userspace scheduling and a scheduling serverIndividual Programming Assignment User Mode Scheduling in MINIX 3 by Bjorn Patrick Swift Поддержка нескольких сетевых карт одного типа Загрузка образов системы > 16 MB Использование GCC Поддержка кодировок CP1251 и KOI8-U 3.1.82010-10-04 Новая инфраструктура управления пакетами: pkgsrc и pkgin Поддержка сокета домена Unix Мультизагрузка Поддержка ext2 Драйвер ACPI Полная поддержка APIC, включая APIC I/O Экспериментальная поддержка AHCI 3.2.02012-02-29 Портирование GNU Debugger для MINIX 3 и реализация поддержки дампа ядра Поддержка FUSE с экспериментальной NTFS-3G Частичная замена пространства пользователя MINIX на NetBSD реализацию Замена стандартного компилятора ACK на Clang (GCC также поддерживается) Switch to ELF and NetBSD libc libraries Pkgsrc Upstreaming and Application Porting Асинхронный virtual filesystem (VFS) сервер Замена загрузчика MINIX на NetBSD Поддержка NCQ в AHCI драйвере 3.2.1 2013-02-21 Замена стандартного inet сервера на сетевой стек lwIP Transitioning towards strict BSD coding style (based on KNF) VBFS — поддержка монтирования VirtualBox Shared Folder как файловой системы Поддержка кросс-компиляции Поддержка Device Driver Environment kit 3.3.0 2014-09-16 Поддержка архитектуры ARM. Minix успешно запущен на широко распространенных одноплатных компьютерах Beagle Экспериментальная поддержка USB для Beaglebone (hub и mass storage) Кросскомпиляция для ARM и x86
Ревизия сайта С релизом MINIX 3.2.0 официальный веб-сайт был усовершенствован. Его достоинством является то, что кнопка загрузки и ссылки на другие важные страницы размещены прямо на главной странице. Официальная вики до сих пор ещё не получила необходимой ревизии и в настоящее время работает на MoinMoin.
Надёжность MINIX 3
Главной целью MINIX 3 является надёжность. Ниже представлены некоторые из наиболее важных принципов повышения надёжности.
Уменьшение размера ядра Монолитные операционные системы, такие как Linux и FreeBSD, и такой гибрид, как Windows, содержат миллионы строк кода ядра. MINIX 3 имеет около 6000 строк исполняемого кода ядра, в котором проще отследить проблему в коде.
Отсечение ошибок В монолитной ОС драйверы устройств располагаются в ядре. Это означает, что когда новое периферийное устройство загружается, неизвестный и потенциально ненадежный код вставляется в ядро. Ошибка в коде драйвера может привести к разрушению системы. В MINIX 3 каждый драйвер работает в своём процессе. Драйверы не могут выполнять привилегированных команд: модификацию таблиц страниц, произвольный ввод-вывод или же запись в память по абсолютному адресу. Они вынуждены делать вызовы ядра для этого и оно проверяет каждую команду на допустимость.
Ограничение доступа драйверов к памяти В монолитной ОС драйвер может записать любое слово в память и таким образом может случайно испортить пользовательскую программу. В MINIX 3, когда пользователь ожидает данные, к примеру, от файловой системы, она создает дескриптор, указывающий, кто имеет доступ и к каким именно адресам. Затем он передает индекс этого дескриптора в файловую систему, которая может передать его драйверу. Файловая система или драйвер запрашивает у ядра запись через этот дескриптор, что делает невозможной для них запись адресов вне буфера.
Сохранение работоспособности дефектных указателей Разыменование дефектного указателя в драйвере привело бы к уничтожению процесса драйвера, но никак не повлияло бы на всю систему в целом. Сервер реинкарнации автоматически перезапустит упавший драйвер. Для некоторых драйверов (таких как драйверы диска и сети) восстановление происходит незаметно для пользовательских процессов, для других же (таких как драйверы аудио и принтера), пользователь может получить уведомление. В монолитных системах разыменование дефектного указателя в ядре или драйвере приводит к разрушению системы.
Ручные бесконечные циклы Если драйвер попадет в бесконечный цикл, то планировщик будет постепенно понижать его приоритет, пока тот не перейдет в режим ожидания. В конечном итоге сервер реинкарнации увидит, что драйвер не отвечает на запросы статуса, поэтому он будет уничтожать и запускать драйвер циклически. В монолитной системе зацикливание драйвера может привести к зависанию системы.
Ограничение повреждений от переполненного буфера В MINIX 3 используется фиксированная длина сообщений для внутренней связи, что исключает определённые проблемы переполнения и управления буфером. Также многие эксплойты работают, переполняя буфер для того, чтобы обмануть программу, возвращая из функции вызова и перезаписав с помощью стека адрес возврата, указывающий на перезаполненный буфер. В MINIX 3 данная атака не сработает, потому что команда и данные разделены пространством и только код (код для чтения) команды может быть выполнен.
Ограничение доступа к функциям ядра Драйверы устройств получают доступ к функциям ядра (таким, как копирование данных из пользовательского адресного пространства) через вызовы к ядру. В Миникс 3 ядро имеет битовую карту, в которой для каждого драйвера указано, какие вызовы ему разрешены. В монолитных системах каждый драйвер может вызвать любую функцию ядра, авторизовав её или нет.
Ограничение доступа к портам ввода-вывода Ядро также обладает таблицей, в которой для каждого драйвера указано, к какому из портов ввода-вывода он имеет доступ. В результате драйвер может работать только со своими собственными портами ввода-вывода. В монолитных системах драйвер может получить доступ к портам ввода-вывода, принадлежащим другим устройствам.
Ограничение связи с компонентами ОС Не каждый драйвер или сервер должен общаться с другими такими же драйверами или серверами. Соответственно, процесс битовой карты определяет, по каким направлениям каждый процесс может обращаться.
Восстановление остановленных или проблемных драйверов Специальное устройство, называемое реинкарнационным сервером, периодически опрашивает каждый драйвер. Если драйвер останавливается или ему не удается ответить на запросы, то реинкарнационный сервер автоматически заменяет его на новую копию. Обнаружение и замена нефункциональных драйверов происходит автоматически без какого-либо пользовательского вмешательства. Эта функция не работает для драйверов дисков в настоящее время, но в следующей версии система будет в состоянии восстановить каждый драйвер диска, который будет скрыт в RAM. Восстановление драйвера не повлияет на рабочий процесс.
Встроенные прерывания и сообщения Когда происходит прерывание, оно преобразуется в уведомление, отправляемое соответствующему драйверу. Если драйвер ожидает сообщения, то он получает прерывание немедленно, в противном случае получит уведомление в следующий раз. Эта схема устраняет вложенные прерывания и делает написание драйвера проще.
Архитектура
Как можно увидеть, нижним уровнем является микроядро, состоящее из около 4000 строк кода (в основном на языке Си и небольшое количество на языке ассемблера). Оно обрабатывает прерывания, осуществляет планирование и передачу сообщений. Также оно поддерживает API из примерно 30 вызовов ядра, которые сервис или драйвер могут выполнить. Пользовательская программа не может делать такие вызовы. Вместо этого они могут делать системные вызовы стандарта POSIX, которые посылают сообщение сервисам. Вызов ядра выполняет такие функции, как настройка прерываний и копирование данных между адресными пространствами.