MINIX 3

MINIX 3 — это проект по созданию небольшой высоконадёжной и функциональной Unix-подобной операционной системы. Он был опубликован под лицензией BSD и является наследником ранее созданных операционных систем MINIX 1 и MINIX 2.

MINIX 3

Оболочка X11 с оконным менеджером TWM работающая на операционной системе MINIX 3
Разработчик Эндрю Таненбаум
Семейство ОС UNIX-подобная операционная система
Последняя версия
Частота обновления финальных версий да
Поддерживаемые платформы i386 (IA-32)
Тип ядра Микроядро
Лицензия BSD
Состояние Актуальное
Репозиторий исходного кода git.minix3.org/?p=minix.…
Предыдущая Minix
Веб-сайт minix3.org

Главной целью проекта является создание отказоустойчивой системы, способной обнаруживать и исправлять собственные ошибки «на лету» без непосредственного вмешательства пользователя. В основном, предполагалось использовать операционную систему во встраиваемых системах и образовании.[3]

MINIX 3 в настоящее время поддерживает IA-32 архитектуру PC-совместимых компьютеров. Кроме того, возможен запуск MINIX под эмуляторами и виртуальными машинами, такими как Bochs,[4][5] VMware Workstation,[6] Microsoft Virtual PC[7] и QEMU. Порты для архитектур ARM[8] и PowerPC[9] находятся в разработке.

Распространяется в виде образа операционной системы, загружаемой со сменного носителя (Live CD).

Цели проекта
Структура операционных систем, основанных на монолитном ядре и микроядре, соответственно

Учитывая природу систем, основанных на монолитном ядре, где драйвер (который содержит, по словам создателя MINIX 3 Таненбаума, примерно в 3-7 раз большее количество ошибок, чем обычная программа)[10] может обрушить всю систему,[11] MINIX 3 направлен на создание такой операционной системы, которая была бы «надежным, самовосстанавливающимся и многосерверным UNIX-клоном».[12]

Чтобы достичь этого, код, выполняющийся в режиме ядра, должен быть минимальным, а файловый сервер, сервер процессов и каждый драйвер устройства должны выполняться как отдельные процессы в пользовательском режиме. Каждый драйвер тщательно контролируется частью системы, известной как сервер восстановления. Если драйвер не реагирует на пинги от сервера восстановления, то он закрывается и заменяется новой копией.

В монолитной системе ошибка в драйвере может привести к разрушению всего ядра, что значительно менее вероятно в MINIX 3.[13]

История

MINIX 3 был анонсирован 24 октября 2005 года Эндрю Таненбаумом во время его вступительной речи на симпозиуме о принципах операционных систем ACM. Хотя MINIX 3 все ещё служит в качестве примера для нового издания книги Таненбаума и Вудхалла, он все же был переработан, чтобы быть «удобным в использовании как надёжная операционная система для встраиваемых устройств и устройств с ограниченными ресурсами, для задач требующих высокой надёжности».

Version Release date Description
3.1.0 2005-10-24
  • Первый релиз MINIX 3 (Выпуск книги).
3.1.2a 2006-05-29
  • Новый менеджер пакетов Packman.
  • Исправлена проблема установки с автоматическим разбиением дисков.
3.1.3 2007-04-13
3.1.3a 2007-06-08
  • Исправление ошибок.
3.1.4 2009-06-09
3.1.5 2009-11-05
  • Улучшение производительности
  • Разделяемая память
  • Функция setitimer
  • Файловая система ISO 9660
  • Open Sound System
  • Ловушка доступа к неинициализированным указателям NULL, для удобства пользователя
  • Улучшена обработка сигналов
  • Лучшая поддержка для отладчиков (усовершенствованный ptrace и др.)
  • Автоопределение сетевых карт (для поддерживаемых PCI-карт), улучшение конфигурации сети
3.1.6 2010-02-08
3.1.7 2010-06-16
  • Userspace scheduling and a scheduling server[14]
  • Поддержка нескольких сетевых карт одного типа
  • Загрузка образов системы > 16 MB
  • Использование GCC
  • Поддержка кодировок cp1251 и koi8-u
3.1.8 2010-10-04
3.2.0 2012-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
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. Восстановление драйвера не повлияет на рабочий процесс.

Встроенные прерывания и сообщения

Когда происходит прерывание, оно преобразуется в уведомление, отправляемое соответствующему драйверу. Если драйвер ожидает сообщения, то он получает прерывание немедленно, в противном случае получит уведомление в следующий раз. Эта схема устраняет вложенные прерывания и делает написание драйвера проще.

Архитектура
Архитектура MINIX 3

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

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

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

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

В настоящее время сервер реинкарнации, файловый сервер, сервер процессов и микроядро являются частью доверенной вычислительной базы. Если любой из них "падает", то вся система выходит из строя. Тем не менее, снижение вычислительной базы с 3-5 миллионов строк кода в Linux или 20 000 строк Windows значительно повышает надежность системы.

Различия между MINIX 3 и предыдущими версиями
Основная статья: MINIX
История взаимодействий различных Unix-подобных систем

MINIX 1, 1.5 и 2 были созданы как инструменты для обучения проектированию ОС.

MINIX 1.0 был создан в 1987 году. 12 000 строк исходного кода ядра было написано преимущественно на языке программирования Си и на языке ассемблера. Исходный код ядра, файловая и система управления памятью были напечатаны в книге. Изначально Таненбаум создал MINIX для компьютеров IBM PC и IBM PC/AT, доступных в то время.

MINIX 1.5, выпущенный в 1991 году, включал в себя поддержку MicroChannel IBM PS/2 и был также портирован на архитектуры Motorola 68000 и SPARC, поддерживающие Atari ST, Commodore Amiga, Apple Macintosh и Sun Microsystems SPARCstation компьютерные платформы. Также доступна версия MINIX, работающая как пользовательский процесс под SunOS.

MINIX 2, выпущенная в 1997 году, была доступна только для архитектур x86 и запускаемая под ОС Solaris SPARC архитектурой. Minix-vmd был создан двумя исследователями из Vrije Universiteit, с добавлением виртуальной памяти и с поддержкой для X Window System.

MINIX 3 делает то же самое, обеспечивая современную ОС множеством новых инструментов и Unix-приложений.[15] Профессор Таненбаум однажды сказал:

Учитывайте, что MINIX 3 — это не MINIX вашего дедушки… MINIX 1 была написана в качестве учебного пособия… MINIX 3 является началом создания высоконадежной, самовосстанавливающейся ОС, свободной от наворотов… MINIX 1 и MINIX 3 связаны так же, как Windows 3.1 и Windows XP — той же частью названия.[12]

MINIX 3.2.0 была выпущена в феврале 2012 года. Данная версия имеет множество новых возможностей, в том числе и компилятор Clang, экспериментальную симметричную многопроцессорную поддержку, procfs и ext2fs поддержку файлов и GDB. Некоторые части NetBSD были также включены в релиз, в том числе загрузчик, libc и различные другие библиотеки.[16]

Релиз MINIX 3.2.1 вышел 21 февраля 2013 года.

Литература

Примечания
  1. (unspecified title) — 2014.
  2. http://www.minix3.org/330.html
  3. «LWN.net.» LWN: MINIX 3 hits the net. 28 Oct 2005. Eklektix, Inc.. 4 Jul 2006 .
  4. Woodhull, Al. Getting Started with Minix on Bochs on Mac OS. 20 Feb 2003. 8 Jul 2006 .
  5. 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 .
  6. Wagstrom, Patrick. Minix under VMWare Installation How-To. 8 Jul 2006 Архивированная копия (недоступная ссылка). Дата обращения: 1 мая 2014. Архивировано 12 ноября 2013 года..
  7. Woodhull, Al. Minix on Virtual PC: first look. 02 Jun 2005. 8 Jul 2006
  8. MINIX 3 Operating System official website
  9. Alting, Ingmar A. MinixPPC: A port of MINIX 3 to the PowerPC platform, 15 Sep 2006.
  10. Tanenbaum, Andy Introduction to MINIX 3. OSnew. OSnews (25 сентября 2006). — «From Rebirth section: "Various studies have shown that software broadly contains something like 6-16 bugs per 1000 lines of code and that device drivers have 3-7 times as many bugs as the rest of the operating system. When combined with the fact that 70% of a typical operating system consists of device drivers, it is clear that device drivers are a big source of trouble. For Windows XP, 85% of the crashes are due to bugs in device drivers. Obviously, to make OSes reliable, something has to be done to deal with buggy device drivers. Building a reliable system despite the inevitable bugs in device drivers was the original driving force behind MINIX 3."». Дата обращения: 4 июля 2008. Архивировано 18 января 2013 года.
  11. Tanenbaum, Andrew. CSAIL Event Calendar. 25 Aug 2006 Архивная копия от 4 февраля 2012 на Wayback Machine.
  12. Tanenbaum, Andrew. «Tanenbaum-Torvalds debate, Part II:.» 12 May 2006. Vrije Universiteit. 15 Jun 2006 .
  13. Tanenbaum, Andrew S.. «Reliability.» The MINIX 3 Operating System. Vrije Universiteit. 22 Jun 2006 Архивировано 1 июля 2006 года.  (недоступная ссылка с 14-05-2013 [3212 дней] — история)
  14. Individual Programming Assignment User Mode Scheduling in MINIX 3 by Bjorn Patrick Swift
  15. Woodhull, Albert S.. "MINIX 3: A small, reliable free operating system: " MINIX 3 FAQ. 24 Oct 2005. Vrije Universiteit. 15 Jun 2006 .
  16. MINIX Releases. wiki.minix3.org. Дата обращения: 29 февраля 2012. Архивировано 18 января 2013 года.

Ссылки
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.