Ядро (операционная система)

Ядро лежащая — это компьютерная программа, в основе и компьютера операционной системы обычно осуществляющая полный контроль над всем в системе. Ядро также отвечает за предотвращение и смягчение конфликтов между различными процессами. ^{[ 1 ]} Это часть кода операционной системы, которая всегда находится в памяти. ^{[ 2 ]} и облегчает взаимодействие между аппаратными и программными компонентами. Полное ядро контролирует все аппаратные ресурсы (например, ввод-вывод, память, криптография) через драйверы устройств , разрешает конфликты между процессами, касающимися таких ресурсов, и оптимизирует использование общих ресурсов, например, использования ЦП и кэша , файловых систем и сетевых сокетов. В большинстве систем ядро является одной из первых программ, загружаемых при запуске (после загрузчика ). Он обрабатывает остальную часть запуска, а также запросы памяти, периферийных устройств и ввода-вывода (I/O) от программного обеспечения , переводя их в по обработке данных инструкции для центрального процессора .

Критический код ядра обычно загружается в отдельную область памяти, защищенную от доступа прикладного программного обеспечения или других менее важных частей операционной системы. Ядро выполняет свои задачи, такие как запуск процессов, управление аппаратными устройствами, такими как жесткий диск , и обработка прерываний, в этом защищенном пространстве ядра . Напротив, прикладные программы, такие как браузеры, текстовые процессоры или аудио- или видеоплееры, используют отдельную область памяти — пользовательское пространство . Такое разделение предотвращает взаимодействие пользовательских данных и данных ядра и возникновение нестабильности и замедления работы. ^{[ 1 ]} а также предотвращает влияние неисправных приложений на другие приложения или сбой всей операционной системы. Даже в системах, где ядро включено в адресное пространство приложений , защита памяти используется для предотвращения изменения ядра неавторизованными приложениями.

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

Существуют различные конструкции архитектуры ядра. Монолитные ядра полностью работают в одном адресном пространстве, при этом ЦП работает в режиме супервизора , главным образом для повышения скорости. Микроядра запускают большинство, но не все свои сервисы в пользовательском пространстве. ^{[ 3 ]} как это делают пользовательские процессы, в основном для устойчивости и модульности . ^{[ 4 ]} MINIX 3 — яркий пример микроядерного дизайна. Ядро Linux является одновременно монолитным и модульным, поскольку оно может вставлять и удалять загружаемые модули ядра во время выполнения.

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

Оперативная память

Оперативная память (ОЗУ) используется для хранения как программных инструкций, так и данных. ^{[ а ]} Обычно для выполнения программы в памяти должны присутствовать оба. Часто множеству программ требуется доступ к памяти, часто требуя больше памяти, чем имеется на компьютере. Ядро отвечает за решение, какую память может использовать каждый процесс, и за определение того, что делать, если памяти недостаточно.

Устройства ввода/вывода

К устройствам ввода-вывода относятся, помимо прочего, периферийные устройства, такие как клавиатуры, мыши, дисководы, принтеры, USB- устройства, сетевые адаптеры и устройства отображения . Ядро предоставляет приложениям удобные методы использования этих устройств, которые обычно абстрагируются ядром, поэтому приложениям не нужно знать детали их реализации.

Управление ресурсами

Ключевые аспекты, необходимые при управлении ресурсами, — это определение домена выполнения ( адресного пространства ) и механизма защиты, используемого для обеспечения доступа к ресурсам внутри домена. ^{[ 5 ]} Ядра также предоставляют методы синхронизации и межпроцессного взаимодействия (IPC). Эти реализации могут находиться внутри самого ядра, либо ядро также может полагаться на другие процессы, которые оно выполняет. Хотя ядро должно обеспечивать IPC для обеспечения доступа к средствам, предоставляемым друг другом, ядра также должны предоставлять работающим программам метод отправки запросов на доступ к этим средствам. Ядро также отвечает за переключение контекста между процессами или потоками.

Управление памятью

Ядро имеет полный доступ к системной памяти и должно разрешать процессам безопасный доступ к этой памяти по мере необходимости. Часто первым шагом в этом является виртуальная адресация , обычно достигаемая путем пейджинга и/или сегментации . Виртуальная адресация позволяет ядру сделать данный физический адрес другим адресом, виртуальным адресом. Виртуальные адресные пространства могут быть разными для разных процессов; память, к которой один процесс обращается по определенному (виртуальному) адресу, может отличаться от памяти, к которой обращается другой процесс по тому же адресу. Это позволяет каждой программе вести себя так, как если бы она была единственной (кроме ядра) работающей, и, таким образом, предотвращает сбой друг друга. ^{[ 6 ]}

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

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

Управление устройствами

Для выполнения полезных функций процессам необходим доступ к подключенным к компьютеру периферийным устройствам , которые управляются ядром через драйверы устройств . Драйвер устройства — это компьютерная программа, инкапсулирующая, контролирующая и управляющая аппаратным устройством (через его аппаратно-программный интерфейс (HSI) ) от имени ОС. Он предоставляет операционной системе API, процедуры и информацию о том, как управлять определенным оборудованием и взаимодействовать с ним. Драйверы устройств являются важной и жизненно важной зависимостью для всех ОС и их приложений. Целью разработки драйвера является абстракция; Функция драйвера заключается в преобразовании вызовов абстрактных функций, предусмотренных ОС (программных вызовов), в вызовы, специфичные для устройства. По идее, устройство должно корректно работать с подходящим драйвером. Драйверы устройств используются, например, для видеокарт, звуковых карт, принтеров, сканеров, модемов и сетевых карт.

На аппаратном уровне общие абстракции драйверов устройств включают:

Прямое взаимодействие
Использование высокоуровневого интерфейса (Video BIOS )
Использование драйвера устройства более низкого уровня (драйверы файлов, использующие драйверы дисков)
Имитируем работу с железом, делая при этом совсем другое

А на программном уровне абстракции драйверов устройств включают в себя:

Разрешение операционной системе прямого доступа к аппаратным ресурсам
Только реализация примитивов
Реализация интерфейса для программного обеспечения без драйверов, такого как TWAIN.
Реализация языка (часто языка высокого уровня, такого как PostScript )

Например, чтобы показать пользователю что-то на экране, приложение должно отправить запрос ядру, которое перенаправит запрос своему драйверу дисплея, который затем отвечает за фактическое отображение символа/пикселя. ^{[ 6 ]}

Ядро должно поддерживать список доступных устройств. Этот список может быть известен заранее (например, во встроенной системе , где ядро будет переписано при изменении доступного оборудования), настраиваться пользователем (типично для старых ПК и систем, не предназначенных для личного использования) или обнаруживаться операционной системы во время выполнения (обычно это называется «подключи и работай »). В системах Plug-and-Play диспетчер устройств сначала выполняет сканирование различных периферийных шин , таких как соединение периферийных компонентов (PCI) или универсальная последовательная шина (USB), для обнаружения установленных устройств, а затем ищет соответствующие драйверы.

Поскольку управление устройствами — это очень специфичная для ОС тема, эти драйверы обрабатываются по-разному в зависимости от конструкции ядра, но в каждом случае ядро должно обеспечивать ввод -вывод , чтобы позволить драйверам физически получать доступ к своим устройствам через тот или иной порт или память. расположение. При разработке системы управления устройствами необходимо принять важные решения, поскольку в некоторых проектах доступ может включать переключение контекста , что делает операцию очень интенсивной для ЦП и легко приводит к значительному снижению производительности. ^{[ нужна ссылка ]}

Системные вызовы

В вычислительной технике системный вызов — это то, как процесс запрашивает у ядра операционной системы услугу, на запуск которой у него обычно нет разрешения. Системные вызовы обеспечивают интерфейс между процессом и операционной системой. Большинство операций, взаимодействующих с системой, требуют разрешений, недоступных для процесса пользовательского уровня, например, ввод-вывод, выполняемый с помощью устройства, присутствующего в системе, или любая форма связи с другими процессами требует использования системных вызовов.

Системный вызов — это механизм, который используется прикладной программой для запроса службы у операционной системы. Они используют инструкцию машинного кода , которая заставляет процессор менять режим. Примером может быть переход из режима супервизора в защищенный режим. Здесь операционная система выполняет такие действия, как доступ к аппаратным устройствам или блоку управления памятью . Обычно операционная система предоставляет библиотеку, которая находится между операционной системой и обычными пользовательскими программами. Обычно это библиотека C, такая как Glibc или Windows API. Библиотека обрабатывает низкоуровневые детали передачи информации ядру и переключения в режим супервизора. Системные вызовы включают закрытие, открытие, чтение, ожидание и запись.

Чтобы действительно выполнять полезную работу, процесс должен иметь доступ к службам, предоставляемым ядром. В каждом ядре это реализуется по-разному, но большинство из них предоставляют библиотеку C или API , которые, в свою очередь, вызывают соответствующие функции ядра. ^{[ 7 ]}

Метод вызова функции ядра варьируется от ядра к ядру. Если используется изоляция памяти, пользовательский процесс не может напрямую вызвать ядро, поскольку это будет нарушением правил контроля доступа процессора. Вот несколько возможностей:

Использование программно-моделируемого прерывания . Этот метод доступен на большинстве аппаратных средств и поэтому очень распространен.
Использование шлюза вызова . Шлюз вызова — это специальный адрес, хранимый ядром в списке в памяти ядра в месте, известном процессору. Когда процессор обнаруживает вызов по этому адресу, он вместо этого перенаправляет его в целевое местоположение, не вызывая нарушения доступа. Для этого требуется аппаратная поддержка, но оборудование для этого довольно распространенное.
Использование специальной инструкции системного вызова . Этот метод требует специальной аппаратной поддержки, которой может не хватать в обычных архитектурах (в частности, x86 ). Однако инструкции системного вызова были добавлены в последние модели процессоров x86, и некоторые операционные системы для ПК используют их, когда они доступны.
Использование очереди в памяти. Приложение, которое отправляет большое количество запросов, но не требует ожидания результата каждого, может добавлять подробную информацию о запросах в область памяти, которую ядро периодически сканирует для поиска запросов.

Проектные решения ядра

Защита

Важным фактором при проектировании ядра является поддержка, которую оно обеспечивает для защиты от ошибок ( отказоустойчивость ) и от вредоносного поведения ( безопасность ). Эти два аспекта обычно четко не разграничиваются, и принятие этого разграничения при проектировании ядра приводит к отказу от иерархической структуры защиты . ^{[ 5 ]}

Механизмы или политики, предоставляемые ядром, можно классифицировать по нескольким критериям, включая: статические (применяются во время компиляции ) или динамические (применяются во время выполнения ); упреждающее или постобнаружение; в соответствии с принципами защиты, которым они удовлетворяют (например, Деннинг ^{[ 8 ]}^{[ 9 ]}); поддерживаются ли они аппаратно или на языке; являются ли они скорее открытым механизмом или обязательной политикой; и многое другое.

Поддержка доменов иерархической защиты ^{[ 10 ]} обычно реализуется с использованием режимов ЦП .

Многие ядра обеспечивают реализацию «возможностей», т. е. объектов, предоставляемых пользовательскому коду и позволяющих ограниченный доступ к базовому объекту, управляемому ядром. Типичным примером является обработка файлов: файл — это представление информации, хранящейся на постоянном запоминающем устройстве. Ядро может выполнять множество различных операций, включая чтение, запись, удаление или выполнение, но приложению пользовательского уровня может быть разрешено выполнять только некоторые из этих операций (например, ему может быть разрешено только чтение файла). Обычно ядро предоставляет приложению объект (обычно так называемый «дескриптор файла»), над которым приложение может затем вызывать операции, достоверность которого ядро проверяет во время запроса операции. Такая система может быть расширена, чтобы охватить все объекты, которыми управляет ядро, а также объекты, предоставляемые другими пользовательскими приложениями.

Эффективный и простой способ обеспечить аппаратную поддержку возможностей — делегировать блоку управления памятью (MMU) ответственность за проверку прав доступа для каждого доступа к памяти. Этот механизм называется адресацией на основе возможностей . ^{[ 11 ]} В большинстве коммерческих компьютерных архитектур отсутствует такая поддержка MMU.

Альтернативный подход заключается в моделировании возможностей с использованием обычно поддерживаемых иерархических доменов. При таком подходе каждый защищенный объект должен находиться в адресном пространстве, к которому приложение не имеет доступа; ядро также хранит в такой памяти список возможностей. Когда приложению необходимо получить доступ к объекту, защищенному возможностью, оно выполняет системный вызов, а затем ядро проверяет, предоставляет ли возможность приложения разрешение на выполнение запрошенного действия, и, если это разрешено, выполняет доступ к нему (либо напрямую, или делегируя запрос другому процессу уровня пользователя). Затраты на производительность при переключении адресного пространства ограничивают практичность этого подхода в системах со сложным взаимодействием между объектами, но он используется в современных операционных системах для объектов, к которым не часто обращаются или от которых не ожидается быстрой работы. ^{[ 12 ]}^{[ 13 ]}

Если прошивка не поддерживает механизмы защиты, можно смоделировать защиту на более высоком уровне, например, моделируя возможности путем манипулирования таблицами страниц , но это влияет на производительность. ^{[ 14 ]} Однако отсутствие аппаратной поддержки может не быть проблемой для систем, которые предпочитают использовать языковую защиту. ^{[ 15 ]}

Важным решением при проектировании ядра является выбор уровней абстракции, на которых должны быть реализованы механизмы и политики безопасности. Механизмы безопасности ядра играют решающую роль в поддержке безопасности на более высоких уровнях. ^{[ 11 ]}^{[ 16 ]}^{[ 17 ]}^{[ 18 ]}^{[ 19 ]}

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

Отсутствие многих критических механизмов безопасности в современных основных операционных системах препятствует реализации адекватных политик безопасности на уровне абстракции приложений . ^{[ 16 ]} Фактически, распространенным заблуждением в области компьютерной безопасности является то, что любая политика безопасности может быть реализована в приложении независимо от поддержки ядра. ^{[ 16 ]}

По мнению разработчиков Mars Research Group, отсутствие изоляции является одним из основных факторов, подрывающих безопасность ядра. ^{[ 20 ]} Они предлагают свою структуру изоляции драйверов для защиты, в первую очередь в ядре Linux. ^{[ 21 ]}^{[ 22 ]}

Аппаратная или языковая защита

Типичные компьютерные системы сегодня используют аппаратно-обеспечиваемые правила о том, каким программам разрешен доступ к каким данным. Процессор контролирует выполнение и останавливает программу, которая нарушает правило, например пользовательский процесс, который пытается выполнить запись в память ядра. В системах, в которых отсутствует поддержка возможностей, процессы изолируются друг от друга с помощью отдельных адресных пространств. ^{[ 23 ]} Вызовы пользовательских процессов в ядро регулируются требованием использования одного из описанных выше методов системного вызова.

Альтернативный подход – использовать языковую защиту. В системе защиты на основе языка ядро разрешает выполнение только кода, созданного компилятором доверенного языка . Тогда язык может быть спроектирован таким образом, чтобы программист не мог дать ему указание сделать что-то, что нарушит требования безопасности. ^{[ 15 ]}

К преимуществам этого подхода относятся:

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

К недостаткам относятся:

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

с языковой защитой включают JX и Microsoft Singularity Примеры систем .

Процесс сотрудничества

Эдсгер Дейкстра доказал, что с логической точки зрения операции атомарной блокировки и разблокировки, работающие с двоичными семафорами, являются достаточными примитивами для выражения любой функциональности взаимодействия процессов. ^{[ 24 ]} Однако этот подход обычно считается недостаточным с точки зрения безопасности и эффективности, тогда как подход с передачей сообщений является более гибким. ^{[ 25 ]} Также доступен ряд других подходов (низкого или более высокого уровня), при этом многие современные ядра обеспечивают поддержку таких систем, как общая память и удаленные вызовы процедур .

Управление устройствами ввода-вывода

Идея ядра, в котором устройства ввода-вывода обрабатываются единообразно с другими процессами как параллельные взаимодействующие процессы, была впервые предложена и реализована Бринчом Хансеном (хотя аналогичные идеи были предложены в 1967 году). ^{[ 26 ]}^{[ 27 ]}). В описании Хансена «общие» процессы называются внутренними процессами , а устройства ввода-вывода — внешними процессами . ^{[ 25 ]}

Как и в случае с физической памятью, предоставление приложениям прямого доступа к портам и регистрам контроллера может привести к сбоям в работе контроллера или сбою системы. При этом, в зависимости от сложности устройства, некоторые устройства могут оказаться удивительно сложными для программирования и использовать несколько разных контроллеров. По этой причине важно предоставить более абстрактный интерфейс для управления устройством. Этот интерфейс обычно реализуется драйвером устройства или уровнем абстракции оборудования. Зачастую приложениям требуется доступ к этим устройствам. Ядро должно поддерживать список этих устройств, каким-либо образом запрашивая их у системы. Это можно сделать через BIOS или через одну из различных системных шин (например, PCI/PCIE или USB). На примере видеодрайвера: когда приложение запрашивает операцию на устройстве, например отображение символа, ядру необходимо отправить этот запрос текущему активному видеодрайверу. Видеодрайверу, в свою очередь, необходимо выполнить этот запрос. Это пример межпроцессное взаимодействие (IPC).

Подходы к проектированию на уровне ядра

Перечисленные выше задачи и возможности могут быть реализованы множеством способов, отличающихся друг от друга дизайном и реализацией.

Принцип разделения механизма и политики является существенным различием между философией микро- и монолитного ядра. ^{[ 28 ]}^{[ 29 ]} Здесь механизм — это поддержка, позволяющая реализовать множество различных политик, а политика — это особый «режим работы». Пример:

Механизм: попытки входа пользователя перенаправляются на сервер авторизации.
Политика: серверу авторизации требуется пароль, который сверяется с паролями, хранящимися в базе данных.

Поскольку механизм и политика разделены, политику можно легко изменить, например, требуя использования токена безопасности .

В минимальное микроядро включены лишь некоторые базовые политики: ^{[ 29 ]} и его механизмы позволяют тому, что работает поверх ядра (оставшаяся часть операционной системы и другие приложения), решать, какие политики применять (например, управление памятью, планирование процессов высокого уровня, управление файловой системой и т. д.). ^{[ 5 ]}^{[ 25 ]} Вместо этого монолитное ядро имеет тенденцию включать в себя множество политик, что ограничивает возможности остальной системы полагаться на них.

Пер Бринч Хансен представил аргументы в пользу разделения механизма и политики. ^{[ 5 ]}^{[ 25 ]} Неспособность должным образом выполнить это разделение является одной из основных причин отсутствия существенных инноваций в существующих операционных системах. ^{[ 5 ]} проблема, распространенная в компьютерной архитектуре. ^{[ 30 ]}^{[ 31 ]}^{[ 32 ]} Монолитная конструкция обусловлена архитектурным подходом к защите «режим ядра»/«режим пользователя» (технически называемым иерархическими доменами защиты ), который распространен в обычных коммерческих системах; ^{[ 33 ]} фактически поэтому каждый модуль, нуждающийся в защите, предпочтительно включать в ядро. ^{[ 33 ]} Эту связь между монолитным дизайном и «привилегированным режимом» можно свести к ключевому вопросу разделения механизма и политики; ^{[ 5 ]} Фактически, архитектурный подход «привилегированного режима» объединяет механизм защиты с политиками безопасности, в то время как основной альтернативный архитектурный подход, адресация на основе возможностей , четко разграничивает эти два подхода, что естественным образом приводит к микроядерной конструкции. ^{[ 5 ]} (см. Разделение защиты и безопасности ).

В то время как монолитные ядра выполняют весь свой код в одном и том же адресном пространстве ( пространстве ядра ), микроядра пытаются запускать большую часть своих сервисов в пользовательском пространстве, стремясь улучшить удобство сопровождения и модульность кодовой базы. ^{[ 4 ]} Большинство ядер не вписываются точно ни в одну из этих категорий, а скорее находятся между этими двумя конструкциями. Они называются гибридными ядрами . более экзотические конструкции, такие как наноядра и экзоядра Доступны экзоядро . , но они редко используются в производственных системах. Например, гипервизор Xen представляет собой

Монолитные ядра

В монолитном ядре все службы ОС работают вместе с основным потоком ядра и, таким образом, также находятся в одной и той же области памяти. Этот подход обеспечивает богатый и мощный доступ к оборудованию. UNIX Разработчик Кен Томпсон заявил, что «по его мнению, проще реализовать монолитное ядро». ^{[ 34 ]} Основными недостатками монолитных ядер являются зависимости между компонентами системы (ошибка в драйвере устройства может привести к сбою всей системы) и тот факт, что большие ядра может стать очень трудным в обслуживании; Томпсон также заявил, что «[монолитному ядру] легче в спешке превратиться в беспорядок, если оно модифицируется». ^{[ 34 ]}

Монолитные ядра, которые традиционно используются Unix-подобными операционными системами, содержат все основные функции операционной системы и драйверы устройств. Монолитное ядро — это одна программа, содержащая весь код, необходимый для выполнения каждой задачи, связанной с ядром. Каждая часть, к которой имеет доступ большинство программ и которую нельзя поместить в библиотеку, находится в пространстве ядра: драйверы устройств, планировщик, обработка памяти, файловые системы и сетевые стеки. Приложениям предоставляется множество системных вызовов, позволяющих им получить доступ ко всем этим службам. Монолитное ядро, изначально загруженное подсистемами, которые могут быть не нужны, можно настроить до такой степени, что оно будет таким же быстрым или даже быстрее, чем то, которое было специально разработано для аппаратного обеспечения, хотя и более актуально в общем смысле.

Современные монолитные ядра, такие как ядро Linux , ядро FreeBSD , ядро AIX , ядро HP-UX и ядро Solaris , все из которых относятся к категории Unix-подобных операционных систем, поддерживают загружаемые модули ядра , позволяя модулям загружаться в ядро во время выполнения, что позволяет легко расширять возможности ядра по мере необходимости, помогая при этом минимизировать объем кода, выполняющегося в пространстве ядра.

Большая часть работы в монолитном ядре выполняется посредством системных вызовов. Это интерфейсы, обычно имеющие табличную структуру, которые обращаются к некоторой подсистеме ядра, например к дисковым операциям. По сути, вызовы выполняются внутри программ, и проверенная копия запроса передается через системный вызов. Значит, ехать совсем недалеко. Монолитное ядро Linux можно сделать очень маленьким не только из-за его способности динамически загружать модули, но и из-за простоты настройки. Фактически, некоторые версии достаточно малы, чтобы вместить в себя большое количество утилит и других программ на компьютере. одну дискету и при этом обеспечивать полнофункциональную операционную систему (одной из самых популярных из которых является muLinux ). Эта возможность миниатюризировать ядро также привела к быстрому росту использования Linux во встраиваемых системах .

Эти типы ядер состоят из основных функций операционной системы и драйверов устройств с возможностью загрузки модулей во время выполнения. Они предоставляют богатые и мощные абстракции базового оборудования. Они предоставляют небольшой набор простых аппаратных абстракций и используют приложения, называемые серверами, для обеспечения большей функциональности. Этот конкретный подход определяет виртуальный интерфейс высокого уровня над оборудованием с набором системных вызовов для реализации служб операционной системы, таких как управление процессами, параллелизм и управление памятью, в нескольких модулях, которые работают в режиме супервизора. Данная конструкция имеет ряд недостатков и ограничений:

Кодирование в ядре может быть сложной задачей, отчасти потому, что нельзя использовать общие библиотеки (например, полнофункциональную libc ), а также потому, что необходимо использовать отладчик уровня исходного кода, такой как gdb . Часто требуется перезагрузка компьютера. Это не просто проблема удобства разработчиков. Когда отладка усложняется и трудности становятся сильнее, становится более вероятным, что код будет содержать больше ошибок.
Ошибки в одной части ядра имеют сильные побочные эффекты; поскольку каждая функция в ядре имеет все привилегии, ошибка в одной функции может повредить структуру данных другой, совершенно несвязанной части ядра или любой работающей программы.
Ядра часто становятся очень большими и их трудно поддерживать.
Даже если модули, обслуживающие эти операции, отделены от целого, интеграция кода является жесткой и ее сложно выполнить правильно.
Поскольку модули работают в одном адресном пространстве , ошибка может вывести из строя всю систему.

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

Микроядра

Микроядро (также сокращенно μK или uK) — это термин, описывающий подход к проектированию операционной системы, при котором функциональность системы перемещается из традиционного «ядра» в набор «серверов», которые взаимодействуют через «минимальное» ядро. , оставляя как можно меньше в «системном пространстве» и как можно больше в «пользовательском пространстве». Микроядро, разработанное для конкретной платформы или устройства, всегда будет иметь только то, что ему необходимо для работы. Подход с использованием микроядра заключается в определении простой абстракции над аппаратным обеспечением с помощью набора примитивов или системных вызовов для реализации минимальных служб ОС, таких как управление памятью , многозадачность и межпроцессное взаимодействие . Другие службы, включая те, которые обычно предоставляются ядром, такие как сетевые функции , реализуются в программах пользовательского пространства, называемых серверами . Микроядра легче поддерживать, чем монолитные ядра, но большое количество системных вызовов и переключений контекста может замедлить работу системы, поскольку они обычно генерируют больше накладных расходов, чем простые вызовы функций.

В пространстве ядра находятся только те части, которые действительно требуют нахождения в привилегированном режиме: IPC (межпроцессное взаимодействие), базовый планировщик или примитивы планирования, базовая обработка памяти, базовые примитивы ввода-вывода. Многие критически важные части теперь выполняются в пользовательском пространстве: полный планировщик, обработка памяти, файловые системы и сетевые стеки. Микроядра были изобретены как реакция на традиционную «монолитную» конструкцию ядра, при которой все функциональные возможности системы были помещены в одну статическую программу, работающую в специальном «системном» режиме процессора. В микроядре выполняются только самые фундаментальные задачи, такие как доступ к некоторым (не обязательно всем) аппаратным средствам, управление памятью и координация передачи сообщений между процессами. Некоторые системы, использующие микроядра, — это QNX и HURD. В случае пользовательских сеансов QNX и Hurd могут быть полные снимки самой системы или представления, как это называется. Сама суть микроядерной архитектуры иллюстрирует некоторые ее преимущества:

Легче обслуживать
Патчи можно протестировать в отдельном экземпляре, а затем заменить на рабочий экземпляр.
Быстрое время разработки и возможность тестирования нового программного обеспечения без перезагрузки ядра.
В целом побольше настойчивости, если один экземпляр вышел из строя, то зачастую его можно заменить исправным зеркалом.

Большинство микроядер используют систему передачи сообщений для обработки запросов от одного сервера к другому. Система передачи сообщений обычно работает на основе порта с микроядром. Например, если отправляется запрос на увеличение памяти, микроядро открывает порт и отправляет запрос. Внутри микроядра шаги аналогичны системным вызовам. Обоснование заключалось в том, что это привнесет модульность в системную архитектуру, что повлечет за собой более чистую систему, более простую в отладке или динамической модификации, настраиваемую в соответствии с потребностями пользователей и более производительную. Они являются частью таких операционных систем, как GNU Hurd , MINIX , MkLinux , QNX и Redox OS . Хотя микроядра сами по себе очень малы, в сочетании со всем необходимым для них вспомогательным кодом они фактически часто больше, чем монолитные ядра. Сторонники монолитных ядер также отмечают, что двухуровневая структура микроядерных систем, в которой большая часть операционной системы не взаимодействует напрямую с аппаратным обеспечением, создает немаловажные затраты с точки зрения эффективности системы. Эти типы ядер обычно предоставляют только минимальные услуги, такие как определение адресных пространств памяти, межпроцессное взаимодействие (IPC) и управление процессами. Другие функции, такие как запуск аппаратных процессов, не обрабатываются микроядрами напрямую. Сторонники микроядер отмечают, что монолитные ядра имеют тот недостаток, что ошибка в ядре может привести к сбою всей системы. Однако при использовании микроядра в случае сбоя процесса ядра все равно можно предотвратить сбой всей системы, просто перезапустив службу, вызвавшую ошибку.

Другие службы, предоставляемые ядром, такие как сетевые функции, реализуются в программах пользовательского пространства, называемых серверами . Серверы позволяют модифицировать операционную систему, просто запуская и останавливая программы. Например, на машине без поддержки сети сетевой сервер не запускается. Задача перемещения в ядро и из него для перемещения данных между различными приложениями и серверами создает накладные расходы, которые снижают эффективность микроядер по сравнению с монолитными ядрами.

Однако недостатки микроядра существуют. Некоторые из них:

Больший объем оперативной памяти
Требуется больше программного обеспечения для взаимодействия, существует вероятность потери производительности.
Ошибки обмена сообщениями исправлять сложнее из-за более длительного пути по сравнению с единственной копией в монолитном ядре.
Управление процессами в целом может быть очень сложным.

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

Микроядро позволяет реализовать остальную часть операционной системы как обычную прикладную программу, написанную на языке высокого уровня , и использовать разные операционные системы поверх одного и того же неизмененного ядра. Также возможно динамическое переключение между операционными системами и одновременное использование нескольких операционных систем. ^{[ 25 ]}

Монолитные ядра против микроядер

По мере роста ядра компьютера растут и размер и уязвимость его доверенной вычислительной базы ; и, помимо снижения безопасности, существует проблема увеличения объема памяти . Это в некоторой степени смягчается за счет совершенствования системы виртуальной памяти , но не все компьютерные архитектуры поддерживают виртуальную память. ^{[ б ]} Чтобы уменьшить объем ядра, необходимо выполнить обширное редактирование, чтобы тщательно удалить ненужный код, что может быть очень сложно из-за неочевидных взаимозависимостей между частями ядра с миллионами строк кода.

К началу 1990-х годов из-за различных недостатков монолитных ядер по сравнению с микроядрами практически все исследователи операционных систем считали монолитные ядра устаревшими. ^{[ нужна ссылка ]} В результате конструкция Linux как монолитного ядра, а не микроядра, стала темой знаменитых дебатов между Линусом Торвальдсом и Эндрю Таненбаумом . ^{[ 35 ]} Обе стороны аргумента, представленного в дебатах Таненбаума и Торвальдса , заслуживают внимания .

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

Монолитные ядра спроектированы таким образом, чтобы весь их код находился в одном адресном пространстве ( пространстве ядра ), что, по мнению некоторых разработчиков, необходимо для повышения производительности системы. ^{[ 36 ]} Некоторые разработчики также утверждают, что монолитные системы чрезвычайно эффективны, если они хорошо написаны. ^{[ 36 ]} Монолитная модель имеет тенденцию быть более эффективной. ^{[ 37 ]} за счет использования общей памяти ядра, а не более медленной системы микроядра IPC, которая обычно основана на передаче сообщений . ^{[ нужна ссылка ]}

Производительность микроядер была низкой как в 1980-х, так и в начале 1990-х годов. ^{[ 38 ]}^{[ 39 ]} Однако исследования, эмпирически измерявшие производительность этих микроядер, не анализировали причины такой неэффективности. ^{[ 38 ]} Объяснения этих данных остались «фольклором», с предположением, что они связаны с увеличением частоты переключений из «ядерного режима» в «пользовательский режим», увеличением частоты межпроцессного взаимодействия и повышенная частота переключений контекста . ^{[ 38 ]}

На самом деле, как предполагалось в 1995 году, причинами плохой производительности микроядер могли быть: (1) фактическая неэффективность всего микроядерного подхода , (2) конкретные концепции , реализованные в этих микроядрах, и (3) конкретная реализация этих концепций. Поэтому еще предстоит изучить, заключается ли решение в создании эффективного микроядра, в отличие от предыдущих попыток, в применении правильных методов построения. ^{[ 38 ]}

С другой стороны, иерархическая архитектура доменов защиты , которая приводит к созданию монолитного ядра. ^{[ 33 ]} имеет существенный недостаток производительности каждый раз, когда происходит взаимодействие между различными уровнями защиты (т. е. когда процессу приходится манипулировать структурой данных как в «режиме пользователя», так и в «режиме супервизора»), поскольку для этого требуется копирование сообщений по значению . ^{[ 40 ]}

Подход с гибридным ядром сочетает в себе скорость и более простую конструкцию монолитного ядра с модульностью и безопасностью выполнения микроядра.

Гибридные (или модульные) ядра

Гибридные ядра используются в большинстве коммерческих операционных систем, таких как Microsoft Windows NT 3.1, NT 3.5, NT 3.51, NT 4.0, 2000, XP, Vista, 7, 8, 8.1 и 10. Apple Собственная macOS использует гибридное ядро под названием XNU. , основанный на коде OSF/1 ( ядра Маха OSFMK 7.3). ^{[ 41 ]} и FreeBSD ядро монолитное . Гибридные ядра похожи на микроядра, за исключением того, что они включают в пространство ядра некоторый дополнительный код для повышения производительности. Эти ядра представляют собой компромисс, который был реализован некоторыми разработчиками для реализации основных преимуществ как монолитных, так и микроядер. Эти типы ядер являются расширениями микроядер с некоторыми свойствами монолитных ядер. В отличие от монолитных ядер, эти типы ядер не могут самостоятельно загружать модули во время выполнения. ^{[ нужна ссылка ]} Это подразумевает запуск некоторых служб (таких как сетевой стек или файловая система ) в пространстве ядра, чтобы снизить нагрузку на производительность традиционного микроядра, но при этом выполнение кода ядра (например, драйверов устройств) в качестве серверов в пользовательском пространстве.

Многие традиционно монолитные ядра теперь, по крайней мере, добавляют (или используют) возможности модуля. Наиболее известным из этих ядер является ядро Linux. Модульное ядро по существу может иметь части, встроенные в двоичный файл ядра, или двоичные файлы, которые загружаются в память по требованию. Модуль с испорченным кодом может дестабилизировать работающее ядро. Можно написать драйвер для микроядра в совершенно отдельном пространстве памяти и протестировать его перед запуском в эксплуатацию. Когда модуль ядра загружается, он обращается к пространству памяти монолитной части, добавляя к нему то, что ему нужно, тем самым открывая путь для возможного загрязнения. Несколько преимуществ модульного (или) гибридного ядра:

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

Модули, как правило, взаимодействуют с ядром, используя тот или иной интерфейс модуля. Интерфейс обобщен (хотя и специфичен для конкретной операционной системы), поэтому не всегда можно использовать модули. Часто драйверам устройств может потребоваться большая гибкость, чем предоставляет интерфейс модуля. По сути, это два системных вызова, и часто проверки безопасности, которые в монолитном ядре нужно выполнить только один раз, теперь могут выполняться дважды. К недостаткам модульного подхода можно отнести:

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

Наноядра

Наноядро делегирует практически все службы – включая даже самые базовые, такие как контроллеры прерываний или таймер – драйверам устройств , чтобы сделать требования ядра к памяти даже меньшими, чем традиционное микроядро. ^{[ 42 ]}

Экзоядра

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

Сами по себе экзоядра чрезвычайно малы. Однако они сопровождаются библиотеками операционных систем (см. также unikernel ), предоставляющими разработчикам приложений функциональные возможности обычной операционной системы. Это сводится к тому, что каждый пользователь пишет свою собственную остальную часть ядра практически с нуля, что является очень рискованной, сложной и довольно устрашающей задачей - особенно в ограниченной по времени среде, ориентированной на производство, поэтому экзоядра никогда не использовались. прижился. ^{[ нужна ссылка ]} Основным преимуществом систем на основе экзоядра является то, что они могут включать в себя несколько операционных систем библиотеки, каждая из которых экспортирует свой API , например один для пользовательского интерфейса разработки в реальном времени высокого уровня, а другой для управления .

Многоядерность

Многоядерная операционная система рассматривает многоядерную машину как сеть независимых ядер, как если бы это была распределенная система . Он не предполагает разделяемую память, а скорее реализует межпроцессное взаимодействие как передачу сообщений . ^{[ 43 ]}^{[ 44 ]} Barrelfish была первой операционной системой, которую можно было назвать многоядерной.

История разработки ядра

Ранние ядра операционной системы

Строго говоря, операционная система (и, следовательно, ядро) не требуется для работы компьютера. Программы можно загружать и выполнять непосредственно на «голом железе» машины при условии, что авторы этих программ готовы работать без какой-либо аппаратной абстракции или поддержки операционной системы. Большинство первых компьютеров работали таким образом в 1950-х и начале 1960-х годов, которые перезагружались и перезагружались между выполнением различных программ. В конце концов, небольшие вспомогательные программы, такие как загрузчики программ и отладчики, оставались в памяти между запусками или загружались из ПЗУ . По мере их разработки они легли в основу того, что стало ранними ядрами операционных систем. Подход «голого железа» до сих пор используется на некоторых игровых консолях и встраиваемых системах . ^{[ 45 ]} но в целом новые компьютеры используют современные операционные системы и ядра.

В 1969 году мультипрограммная система RC 4000 представила философию проектирования системы небольшого ядра, «на основе которой можно было бы упорядоченно строить операционные системы для различных целей». ^{[ 46 ]} то, что можно было бы назвать микроядерным подходом.

Операционные системы с разделением времени

За десятилетие, предшествовавшее Unix , мощность компьютеров значительно возросла – до такой степени, что операторы компьютеров искали новые способы заставить людей использовать свое свободное время на своих машинах. Одним из главных достижений той эпохи было разделение времени , благодаря которому ряд пользователей получал небольшие отрезки компьютерного времени со скоростью, с которой каждый из них был подключен к своей, более медленной, машине. ^{[ 47 ]}

Развитие систем разделения времени привело к ряду проблем. Во-первых, пользователи, особенно в университетах, где разрабатывались системы, похоже, хотели взломать систему, чтобы получить больше процессорного времени. По этой причине безопасность и контроль доступа стали основным направлением проекта Multics в 1965 году. ^{[ 48 ]} Еще одной постоянной проблемой было правильное обращение с вычислительными ресурсами: пользователи проводили большую часть своего времени, глядя на терминал и думая о том, что вводить, вместо того, чтобы фактически использовать ресурсы компьютера, а система разделения времени должна предоставлять время ЦП активному пользователю. в эти периоды. Наконец, системы обычно предлагали иерархию памяти в несколько уровней, и разделение этого дорогостоящего ресурса привело к серьезным разработкам в виртуальной памяти системах .

Амига

Commodore был выпущен в 1985 году и был одним из Amiga первых – и, безусловно, наиболее успешных – домашних компьютеров с усовершенствованной архитектурой ядра. Исполнительный компонент ядра AmigaOS, exec.library , использует схему передачи сообщений микроядра, но существуют и другие компоненты ядра, такие как Graphics.library , которые имеют прямой доступ к оборудованию. Защита памяти отсутствует, а ядро почти всегда работает в пользовательском режиме. В режиме ядра выполняются только специальные действия, а приложения пользовательского режима могут попросить операционную систему выполнить их код в режиме ядра.

Юникс

На этапе проектирования Unix программисты решили моделировать каждое устройство высокого уровня в виде файла , поскольку считали, что целью вычислений является преобразование данных . ^{[ 49 ]}

Например, принтеры были представлены как «файл» в известном месте — когда данные копировались в файл, они распечатывались. Другие системы, чтобы обеспечить аналогичную функциональность, имели тенденцию виртуализировать устройства на более низком уровне – то есть и устройства , и файлы были бы экземплярами некоторой концепции более низкого уровня . Виртуализация системы на уровне файлов позволила пользователям манипулировать всей системой, используя существующие утилиты и концепции управления файлами , что значительно упростило работу. В качестве расширения той же парадигмы Unix позволяет программистам манипулировать файлами с помощью ряда небольших программ, используя концепцию каналов , которая позволяла пользователям выполнять операции поэтапно, пропуская файл через цепочку одноцелевых инструментов. Хотя конечный результат был тот же, использование небольших программ таким образом значительно повысило гибкость, а также простоту разработки и использования, позволяя пользователю изменять свой рабочий процесс, добавляя или удаляя программу из цепочки.

В модели Unix операционная система состоит из двух частей: во-первых, огромной коллекции служебных программ, которые управляют большинством операций; во-вторых, ядро, на котором работают программы. ^{[ 49 ]} В Unix, с точки зрения программирования, разница между ними довольно тонкая; ядро — это программа, работающая в режиме супервизора, ^{[ с ]} который действует как загрузчик программ и супервизор для небольших служебных программ, составляющих остальную часть системы, а также обеспечивает услуги блокировки и ввода-вывода для этих программ; кроме того, ядро вообще не вмешивалось в пространство пользователя .

С течением времени модель вычислений изменилась, и подход Unix ко всему как к файлу или потоку байтов больше не был таким универсальным, как раньше. Хотя терминал можно рассматривать как файл или поток байтов, который печатается или считывается, это, похоже, не относится к графическому пользовательскому интерфейсу . Сеть создала еще одну проблему. Даже если сетевую связь можно сравнить с доступом к файлам, низкоуровневая пакетно-ориентированная архитектура работает с отдельными фрагментами данных, а не с целыми файлами. По мере роста возможностей компьютеров Unix становилась все более загроможденной кодом. Это также связано с тем, что модульность ядра Unix широко масштабируема. ^{[ 50 ]} ядра могли содержать 100 000 строк кода В то время как в семидесятых и восьмидесятых годах , ядра, подобные Linux , современных преемников Unix, таких как GNU , содержат более 13 миллионов строк. ^{[ 51 ]}

Современные производные Unix обычно основаны на монолитных ядрах с загрузкой модулей. Примерами этого являются ядро Linux во многих дистрибутивах GNU такие , IBM AIX , а также варианты ядра Berkeley Software Distribution, как FreeBSD , DragonFly BSD , OpenBSD , NetBSD и macOS . Помимо этих альтернатив, разработчики-любители поддерживают активное сообщество разработчиков операционных систем , состоящее из самописных ядер для хобби, которые в конечном итоге в конечном итоге разделяют многие функции с ядрами Linux, FreeBSD, DragonflyBSD, OpenBSD или NetBSD и/или совместимы с ними. ^{[ 52 ]}

Классическая Mac OS и macOS

Apple впервые выпустила свою классическую Mac OS в 1984 году в комплекте с Macintosh персональным компьютером . Apple перешла к дизайну наноядра в Mac OS 8.6. Напротив, современная macOS (первоначально называвшаяся Mac OS X) основана на Darwin , который использует гибридное ядро под названием XNU , которое было создано путем объединения ядра 4.3BSD и ядра Mach . ^{[ 53 ]}

Microsoft Windows

Microsoft Windows была впервые выпущена в 1985 году как дополнение к MS-DOS . Из-за зависимости от другой операционной системы первоначальные выпуски Windows до Windows 95 считались операционной средой (не путать с операционной системой ). Эта линейка продуктов продолжала развиваться на протяжении 1980-х и 1990-х годов: в серию Windows 9x были добавлены 32-битная адресация и вытесняющая многозадачность; но закончилось с выпуском Windows Me в 2000 году.

Microsoft также разработала Windows NT , операционную систему с очень похожим интерфейсом, но предназначенную для высококлассных и бизнес-пользователей. Эта линия началась с выпуском Windows NT 3.1 в 1993 году и была представлена обычным пользователям с выпуском Windows XP в октябре 2001 года, заменив Windows 9x совершенно другой, гораздо более сложной операционной системой. Эта линия продолжается и в Windows 11 .

Архитектура ядра Windows NT считается гибридным ядром, поскольку само ядро содержит такие задачи, как диспетчер окон и диспетчеры IPC, с многоуровневой моделью подсистемы клиент/сервер. ^{[ 54 ]} Оно было разработано как модифицированное микроядро , поскольку на ядро Windows NT повлияло микроядро Маха, но оно не соответствует всем критериям чистого микроядра.

IBM-супервайзер

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

Исторически этот термин по существу ассоциировался с IBM линейкой операционных систем для мэйнфреймов , начиная с OS/360 . В других операционных системах супервизор обычно называется ядром.

супервизора В 1970-х годах IBM еще больше абстрагировала состояние от аппаратного обеспечения, в результате чего был создан гипервизор , обеспечивающий полную виртуализацию , то есть возможность запуска нескольких операционных систем на одной машине совершенно независимо друг от друга. Поэтому первая такая система называлась Virtual Machine или VM .

Разработка микроядер

Хотя Mach , разработанный Ричардом Рашидом в Университете Карнеги-Меллон , является самым известным микроядром общего назначения, другие микроядра были разработаны с более конкретными целями. Семейство микроядер L4 (в основном ядро L3 и L4) было создано, чтобы продемонстрировать, что микроядра не обязательно медленные. ^{[ 55 ]} Новые реализации, такие как Fiasco и Pistachio, могут запускать Linux рядом с другими процессами L4 в отдельных адресных пространствах. ^{[ 56 ]}^{[ 57 ]}

Кроме того, QNX — это микроядро, которое в основном используется во встроенных системах . ^{[ 58 ]} а программное обеспечение с открытым исходным кодом MINIX , изначально созданное для образовательных целей, теперь ориентировано на то, чтобы стать высоконадежной и самовосстанавливающейся микроядерной ОС.

См. также

Примечания

^ Это может зависеть от архитектуры компьютера.
^ Виртуальная адресация чаще всего достигается с помощью встроенного блока управления памятью .
^ Самый высокий уровень привилегий имеет разные названия в разных архитектурах, например режим супервизора, режим ядра, CPL0, DPL0, кольцо 0 и т. д. в разделе Защитное кольцо . Дополнительную информацию см.

Ссылки

^ Jump up to: ^а ^б «Ядро» . Линфо . Группа пользователей Linux Bellevue. Архивировано из оригинала 8 декабря 2006 года . Проверено 15 сентября 2016 г.
^ Рэндал Э. Брайант; Дэвид Р. О'Халларон (2016). Компьютерные системы: взгляд программиста (Третье изд.). Пирсон. п. 17. ISBN 978-0-13-409266-9 .
^ см . Демон (вычисления)
^ Jump up to: ^а ^б Рох 2004 г.
^ Jump up to: ^а ^б ^с ^д ^и ^ж ^г Вульф 1974, стр. 337–345.
^ Jump up to: ^а ^б Серебряное сокровище 1991 г.
^ Таненбаум, Эндрю С. (2008). Современные операционные системы (3-е изд.). Прентис Холл. стр. 50–51. ISBN 978-0-13-600663-3 . . . . почти все системные вызовы вызываются из программ на языке C путем вызова библиотечной процедуры. . . Библиотечная процедура. . . выполняет инструкцию TRAP для переключения из пользовательского режима в режим ядра и начала выполнения. . .
^ Деннинг 1976
^ Swift 2005, стр. 29, цитата: «изоляция, контроль ресурсов, проверка решений (проверка) и восстановление ошибок».
^ Шредер 72
^ Jump up to: ^а ^б Линден 76
^ Эранян, Стефан; Мосбергер, Дэвид (2002). «Виртуальная память в ядре Linux IA-64» . Ядро Linux IA-64: проектирование и реализация . Прентис Холл PTR. ISBN 978-0-13-061014-0 .
^ Зильбершац и Гэлвин, Концепции операционной системы, 4-е изд., стр. 445 и 446.
^ Хох, Чарльз; Дж. К. Браун (июль 1980 г.). «Реализация возможностей PDP-11/45» . Обзор операционных систем ACM SIGOPS . 14 (3): 22–32. дои : 10.1145/850697.850701 . S2CID 17487360 .
^ Jump up to: ^а ^б Шнайдер, Фред Б.; Морриссетт, Грег; Харпер, Роберт. «Языковой подход к безопасности» (PDF) . Архивировано (PDF) из оригинала 22 декабря 2018 г.
^ Jump up to: ^а ^б ^с Лоскокко, Пенсильвания; Смолли, SD; Макельбауэр, Пенсильвания; Тейлор, Р.С.; Тернер, С.Дж.; Фаррелл, Дж. Ф. (октябрь 1998 г.). «Неизбежность неудачи: ошибочное предположение о безопасности в современных вычислительных средах» . Материалы 21-й Национальной конференции по безопасности информационных систем . стр. 303–314. Архивировано из оригинала 21 июня 2007 г.
^ Лепре, Джей; Форд, Брайан; Хиблер, Майк (1996). «Постоянная актуальность локальной операционной системы для глобальных приложений». Материалы 7-го семинара по Европейскому семинару ACM SIGOPS Системная поддержка для мировых приложений - EW 7 . стр. 133–140. дои : 10.1145/504450.504477 . ISBN 978-1-4503-7339-5 . S2CID 10027108 .
^ Андерсон, Дж. (октябрь 1972 г.). Исследование планирования технологий компьютерной безопасности (PDF) (Отчет). Том. II. Отдел электронных систем ВВС. ЭСД-ТР-73-51, Том. II. Архивировано (PDF) из оригинала 21 июля 2011 г.
^ Джерри Х. Зальцер; Майк Д. Шредер (сентябрь 1975 г.). «Защита информации в компьютерных системах» . Труды IEEE . 63 (9): 1278–1308. CiteSeerX 10.1.1.126.9257 . дои : 10.1109/PROC.1975.9939 . S2CID 269166 . Архивировано из оригинала 8 марта 2021 г. Проверено 15 июля 2007 г.
^ «Тонкая изоляция ядра» . Марс-research.github.io . Проверено 15 сентября 2022 г.
^ Фетцер, Мэри. «Автоматическая изоляция драйверов устройств защищает от ошибок в операционных системах» . Университет штата Пенсильвания через techxplore.com . Проверено 15 сентября 2022 г.
^ Хуан, Юнчжэ; Нараянан, Викрам; Детвейлер, Дэвид; Хуан, Кайминг; Тан, Банда; Джагер, Трент; Бурцев, Антон (2022). «KSplit: автоматизация изоляции драйверов устройств» (PDF) . Проверено 20 декабря 2023 г.
^ Джонатан С. Шапиро; Джонатан М. Смит; Дэвид Дж. Фарбер (1999). «ЭРОС». Обзор операционных систем ACM Sigops . 33 (5): 170–185. дои : 10.1145/319344.319163 .
^ Дейкстра, EW Сотрудничающие последовательные процессы . Математика. Департамент технологического университета, Эйндховен, сентябрь 1965 г.
^ Jump up to: ^а ^б ^с ^д ^и Бринч Хансен 70 стр. 238–241
^ Харрисон, MC; Шварц, Дж.Т. (1967). «SHARER, система разделения времени для CDC 6600» . Коммуникации АКМ . 10 (10): 659–665. дои : 10.1145/363717.363778 . S2CID 14550794 .
^ Хакстейбл, DHR; Уорик, Монтана (1967). «Динамические супервизоры – их проектирование и конструкция» . Материалы симпозиума ACM по принципам операционных систем - SOSP '67 . С. 11.1–11.17. дои : 10.1145/800001.811675 . ISBN 978-1-4503-7370-8 . S2CID 17709902 . Проверено 20 декабря 2023 г.
^ Баярди 1988
^ Jump up to: ^а ^б Левин 75
^ Деннинг 1980
^ Немер, Юрген (1991). «Бессмертие операционных систем, или: исследования операционных систем все еще оправданы?» . Конспекты лекций по информатике; Том. 563. Материалы международного семинара по операционным системам 90-х и последующих лет . стр. 77–83. дои : 10.1007/BFb0024528 . ISBN 3-540-54987-0 . Последние 25 лет показали, что исследования архитектуры операционных систем оказали незначительное влияние на существующие основные [ sic ] системы.
^ Леви 84, стр. 1, цитата: «Хотя сложность компьютерных приложений увеличивается с каждым годом, базовая аппаратная архитектура приложений остается неизменной на протяжении десятилетий».
^ Jump up to: ^а ^б ^с Леви 84, стр. 1, цитата: «Обычные архитектуры поддерживают один привилегированный режим операция. Такая структура приводит к монолитной конструкции; любой модуль, нуждающийся в защите, должен быть частью единого ядра операционной системы. Если бы вместо этого любой модуль мог выполняться в защищенном домене, системы можно было бы построить как набор независимых модулей, расширяемых любым пользователем».
^ Jump up to: ^а ^б «Открытые исходные коды: голоса революции открытого исходного кода» . 1-56592-582-3 . 29 марта 1999 г. Архивировано из оригинала 1 февраля 2020 г. . Проверено 24 марта 2019 г.
^ Записи дебатов между Торвальдсом и Таненбаумом можно найти на dina.dk. Архивировано 3 октября 2012 г. на Wayback Machine , groups.google.com. Архивировано 26 мая 2013 г. на Wayback Machine , oreilly.com. Архивировано 9 сентября 2014 г. -21 на Wayback Machine и на сайте Эндрю Таненбаума. Архивировано 5 августа 2015 г. на Wayback Machine.
^ Jump up to: ^а ^б Мэтью Рассел. «Что такое Дарвин (и как он работает в Mac OS X)» . О'Рейли Медиа . Архивировано из оригинала 8 декабря 2007 г. Проверено 9 декабря 2008 г. Тесно связанная природа монолитного ядра позволяет ему очень эффективно использовать базовое оборудование [...] Микроядра, с другой стороны, запускают гораздо больше основных процессов в пользовательской среде. [...] К сожалению, эти преимущества достигаются за счет того, что микроядру приходится передавать много информации в пространство ядра и из него посредством процесса, известного как переключение контекста. Переключение контекста приводит к значительным накладным расходам и, следовательно, к снижению производительности.
^ «Операционные системы/модели ядра — Викиверситет» . ru.wikiversity.org . Архивировано из оригинала 18 декабря 2014 г. Проверено 18 декабря 2014 г.
^ Jump up to: ^а ^б ^с ^д Лидтке 95
^ Хард 97
^ Хансен 73, раздел 7.3, стр. 233 « Взаимодействие между различными уровнями защиты требует передачи сообщений по значению »
^ Маги, Джим. WWDC 2000, сессия 106 — Mac OS X: ядро . Через 14 минут. Архивировано из оригинала 30 октября 2021 г.
^ «Наноядерная архитектура KeyKOS» . Архивировано из оригинала 21 июня 2011 г.
^ Бауманн, Эндрю; Бархам, Пол; Даганд, Пьер-Эварист; Харрис, Тим; Айзекс, Ребекка; Питер, Саймон; Роско, Тимоти; Шюпбах, Адриан; Сингхания, Ахилеш (2009). Многоядерность: новая архитектура ОС для масштабируемых многоядерных систем (PDF) . 22-й симпозиум по принципам операционных систем.
^ «Операционная система Barrelfish» .
^ Болл: Проекты встроенных микропроцессоров, с. 129
^ Хансен 2001 (ос), стр. 17–18.
^ «Версия BSTJ документа C.ACM Unix» . bell-labs.com . Архивировано из оригинала 30 декабря 2005 г. Проверено 17 августа 2006 г.
^ Корбато, Ф.Дж. ; Высоцкий В.А. Введение и обзор системы Multics . Осень 1965 г. Объединенная компьютерная конференция. Архивировано из оригинала 9 июля 2011 г.
^ Jump up to: ^а ^б «Единая спецификация Unix» . Открытая группа . Архивировано из оригинала 4 октября 2016 г. Проверено 29 сентября 2016 г.
^ «Месть Юникса» . asymco.com . 29 сентября 2010 года. Архивировано из оригинала 9 ноября 2010 года . Проверено 2 октября 2010 г.
^ Уилер, Дэвид А. (12 октября 2004 г.). «Ядро Linux 2.6: оно стоит большего!» .
^ Это сообщество в основном собирается на сайтах Bona Fide OS Development , архивировано 17 января 2022 г. на Wayback Machine , доске объявлений Mega-Tokyo, архивировано 25 января 2022 г. на Wayback Machine , и на других веб-сайтах энтузиастов операционных систем.
^ Сингх, Амит (декабрь 2003 г.). «XNU: Ядро» . Архивировано из оригинала 12 августа 2011 г.
^ «Windows — Официальный сайт ОС Microsoft Windows 10 Home и Pro, ноутбуков, ПК, планшетов и многого другого» . windows.com . Архивировано из оригинала 20 августа 2011 г. Проверено 24 марта 2019 г.
^ «Семейство микроядер L4 — Обзор» . os.inf.tu-dresden.de . Архивировано из оригинала 21 августа 2006 г. Проверено 11 августа 2006 г.
^ «Микроядро Fiasco — Обзор» . os.inf.tu-dresden.de . Архивировано из оригинала 16 июня 2006 г. Проверено 10 июля 2006 г.
^ Золлер (неактивен), Хайнц (7 декабря 2013 г.). «Л4Ка — Проект Л4Ка» . www.l4ka.org . Архивировано из оригинала 19 апреля 2001 года . Проверено 24 марта 2019 г.
^ «Операционные системы QNX» . blackberry.qnx.com . Архивировано из оригинала 24 марта 2019 г. Проверено 24 марта 2019 г.

Источники

Рох, Бенджамин (2004). «Монолитное ядро против микроядра» (PDF) . Архивировано из оригинала (PDF) 1 ноября 2006 г. Проверено 12 октября 2006 г.
Зильбершац, Авраам ; Джеймс Л. Петерсон; Питер Б. Гэлвин (1991). Концепции операционной системы . Бостон, Массачусетс : Аддисон-Уэсли. п. 696. ИСБН 978-0-201-51379-0 .
Болл, Стюарт Р. (2002) [2002]. Встроенные микропроцессорные системы: конструкции из реального мира (первое изд.). Эльзевир Наука. ISBN 978-0-7506-7534-5 .
Дейтел, Харви М. (1984) [1982]. Введение в операционные системы (пересмотренное первое издание). Аддисон-Уэсли. п. 673 . ISBN 978-0-201-14502-1 .
Деннинг, Питер Дж. (декабрь 1976 г.). «Отказоустойчивые операционные системы». Обзоры вычислительной техники ACM . 8 (4): 359–389. дои : 10.1145/356678.356680 . ISSN 0360-0300 . S2CID 207736773 .
Деннинг, Питер Дж. (апрель 1980 г.). «Почему бы не инновации в компьютерной архитектуре?» . Новости компьютерной архитектуры ACM SIGARCH . 8 (2): 4–7. дои : 10.1145/859504.859506 . ISSN 0163-5964 . S2CID 14065743 .
Хансен, Пер Бринч (апрель 1970 г.). «Ядро мультипрограммной системы». Коммуникации АКМ . 13 (4): 238–241. CiteSeerX 10.1.1.105.4204 . дои : 10.1145/362258.362278 . ISSN 0001-0782 . S2CID 9414037 .
Хансен, Пер Бринч (1973). Принципы операционной системы . Энглвудские скалы : Прентис-холл. п. 496 . ISBN 978-0-13-637843-3 .
Хансен, Пер Бринч (2001). «Эволюция операционных систем» (PDF) . Архивировано (PDF) из оригинала 25 июля 2011 г. Проверено 24 октября 2006 г. включено в книгу: Пер Бринч Хансен, изд. (2001). «1 Эволюция операционных систем». Классические операционные системы: от пакетной обработки к распределенным системам . Нью-Йорк: Springer-Verlag. стр. 1–36. ISBN 978-0-387-95113-3 .
Хартиг, Герман; Хохмут, Майкл; Лидтке, Йохен ; Шенберг, Себастьян; Уолтер, Джин (5–8 октября 1997 г.). «Производительность систем на базе μ-ядра» . Материалы шестнадцатого симпозиума ACM по принципам операционных систем - СОСП '97 . 16-й симпозиум ACM по принципам операционных систем (SOSP'97). Сен-Мало, Франция. дои : 10.1145/268998.266660 . ISBN 978-0-89791-916-6 . S2CID 1706253 . Архивировано из оригинала 17 февраля 2020 г. , Хартиг, Герман; Хохмут, Майкл; Лидтке, Йохен; Шенберг, Себастьян (декабрь 1997 г.). «Производительность систем на базе μ-ядра» . Обзор операционных систем ACM SIGOPS . 31 (5): 66–77. дои : 10.1145/269005.266660 .
Хоудек, Мэн; Солтис, ФГ ; Хоффман, Р.Л. (1981). «Поддержка IBM System/38 для адресации на основе возможностей» . Материалы 8-го Международного симпозиума ACM по компьютерной архитектуре . АКМ/IEEE. стр. 341–348.
Руководство разработчика программного обеспечения для архитектуры IA-32, Том 1: Базовая архитектура (PDF) . Корпорация Интел . 2002.
Левин Р.; Коэн, Э.; Корвин, В.; Поллак, Ф.; Вульф, Уильям (1975). «Разделение политики и механизмов в Гидре» . Обзор операционных систем ACM Sigops . 9 (5): 132–140. дои : 10.1145/1067629.806531 .
Леви, Генри М. (1984). Компьютерные системы, основанные на возможностях . Мейнард, Массачусетс: Digital Press. ISBN 978-0-932376-22-0 . Архивировано из оригинала 13 июля 2007 г. Проверено 18 июля 2007 г.
Лидтке, Йохен (декабрь 1995 г.). «О построении µ-ядра» . Учеб. 15-й симпозиум ACM по принципам операционных систем (SOSP) . Архивировано из оригинала 13 марта 2007 г.
Линден, Теодор А. (декабрь 1976 г.). «Структуры операционной системы для поддержки безопасности и надежного программного обеспечения». Обзоры вычислительной техники ACM . 8 (4): 409–445. дои : 10.1145/356678.356682 . hdl : 2027/mdp.39015086560037 . ISSN 0360-0300 . S2CID 16720589 . , «Структуры операционной системы для поддержки безопасности и надежного программного обеспечения» (PDF) . Проверено 20 декабря 2023 г.
Лорин, Гарольд (1981). Операционные системы . Бостон, Массачусетс : Аддисон-Уэсли. стр. 161–186 . ISBN 978-0-201-14464-2 .
Шредер, Майкл Д .; Джером Х. Зальцер (март 1972 г.). «Аппаратная архитектура для реализации защитных колец». Коммуникации АКМ . 15 (3): 157–170. CiteSeerX 10.1.1.83.8304 . дои : 10.1145/361268.361275 . ISSN 0001-0782 . S2CID 14422402 .
Шоу, Алан К. (1974). Логическое проектирование операционных систем . Прентис-Холл. п. 304 . ISBN 978-0-13-540112-5 .
Таненбаум, Эндрю С. (1979). Структурированная компьютерная организация . Энглвуд Клиффс, Нью-Джерси : Прентис-Холл. ISBN 978-0-13-148521-1 .
Вульф, В .; Э. Коэн; В. Корвин; А. Джонс; Р. Левин; К. Пирсон; Ф. Поллак (июнь 1974 г.). «ГИДРА: ядро многопроцессорной операционной системы» (PDF) . Коммуникации АКМ . 17 (6): 337–345. дои : 10.1145/355616.364017 . ISSN 0001-0782 . S2CID 8011765 . Архивировано из оригинала (PDF) 26 сентября 2007 г. Проверено 18 июля 2007 г.
Баярди, Ф.; А. Томази; М. Ваннески (1988). Архитектура вычислительных систем, том 1 (на итальянском языке). Франко Анджели. ISBN 978-88-204-2746-7 . Архивировано из оригинала 27 июня 2012 г. Проверено 10 октября 2006 г.
Свифт, Майкл М.; Брайан Н. Бершад; Генри М. Леви. Повышение надежности стандартных операционных систем (PDF) . Архивировано (PDF) из оригинала 19 июля 2007 г. Проверено 16 июля 2007 г.
Геттис, Джеймс; Карлтон, Филип Л.; МакГрегор, Скотт (1990). «Система X Window, версия 11». Программное обеспечение: практика и опыт . 20 : С35–С67. дои : 10.1002/спе.4380201404 . S2CID 26329062 .
Майкл М. Свифт; Брайан Н. Бершад; Генри М. Леви (февраль 2005 г.). «Повышение надежности стандартных операционных систем». Транзакции ACM в компьютерных системах . 23 (1). Ассоциация вычислительной техники: 77–110. дои : 10.1145/1047915.1047919 . eISSN 1557-7333 . ISSN 0734-2071 . S2CID 208013080 .

Дальнейшее чтение

Эндрю С. Таненбаум , Альберт С. Вудхалл, Операционные системы: проектирование и внедрение (третье издание) ;
Эндрю С. Таненбаум, Герберт Бос, Современные операционные системы (четвертое издание) ;
Дэниел П. Бовет, Марко Чесати, «Понимание ядра Linux» (третье издание) ;
Дэвид А. Паттерсон , Джон Л. Хеннесси , Компьютерная организация и дизайн (шестое издание) , Морган Кауфманн ( ISBN 978-0-12-820109-1 ;
Б.С. Чок, А.Т. Картер, Р.В. Хинд, Компьютерная организация и архитектура: введение (второе издание) , Пэлгрейв Макмиллан ( ISBN 978-1-4039-0164-4 ).

Внешние ссылки

Подробное сравнение ядер наиболее популярных операционных систем.

[5] Это может зависеть от архитектуры компьютера.

[36] Виртуальная адресация чаще всего достигается с помощью встроенного блока управления памятью .

[52] Самый высокий уровень привилегий имеет разные названия в разных архитектурах, например режим супервизора, режим ядра, CPL0, DPL0, кольцо 0 и т. д. в разделе Защитное кольцо . Дополнительную информацию см.

[Linfo-1] Jump up to: ^а ^б «Ядро» . Линфо . Группа пользователей Linux Bellevue. Архивировано из оригинала 8 декабря 2006 года . Проверено 15 сентября 2016 г.

[2] Рэндал Э. Брайант; Дэвид Р. О'Халларон (2016). Компьютерные системы: взгляд программиста (Третье изд.). Пирсон. п. 17. ISBN 978-0-13-409266-9 .

[3] см . Демон (вычисления)

[mono-micro-4] Jump up to: ^а ^б Рох 2004 г.

[Wulf74-6] Jump up to: ^а ^б ^с ^д ^и ^ж ^г Вульф 1974, стр. 337–345.

[OS-Concepts-7] Jump up to: ^а ^б Серебряное сокровище 1991 г.

[8] Таненбаум, Эндрю С. (2008). Современные операционные системы (3-е изд.). Прентис Холл. стр. 50–51. ISBN 978-0-13-600663-3 . . . . почти все системные вызовы вызываются из программ на языке C путем вызова библиотечной процедуры. . . Библиотечная процедура. . . выполняет инструкцию TRAP для переключения из пользовательского режима в режим ядра и начала выполнения. . .

[Denning76-9] Деннинг 1976

[Swift05Denning76-10] Swift 2005, стр. 29, цитата: «изоляция, контроль ресурсов, проверка решений (проверка) и восстановление ошибок».

[Schroeder72-11] Шредер 72

[LindenCapabilityAddressing-12] Jump up to: ^а ^б Линден 76

[EranianMosberger-13] Эранян, Стефан; Мосбергер, Дэвид (2002). «Виртуальная память в ядре Linux IA-64» . Ядро Linux IA-64: проектирование и реализация . Прентис Холл PTR. ISBN 978-0-13-061014-0 .

[14] Зильбершац и Гэлвин, Концепции операционной системы, 4-е изд., стр. 445 и 446.

[HochBrowne-15] Хох, Чарльз; Дж. К. Браун (июль 1980 г.). «Реализация возможностей PDP-11/45» . Обзор операционных систем ACM SIGOPS . 14 (3): 22–32. дои : 10.1145/850697.850701 . S2CID 17487360 .

[Schneider-16] Jump up to: ^а ^б Шнайдер, Фред Б.; Морриссетт, Грег; Харпер, Роберт. «Языковой подход к безопасности» (PDF) . Архивировано (PDF) из оригинала 22 декабря 2018 г.

[Loscocco98-17] Jump up to: ^а ^б ^с Лоскокко, Пенсильвания; Смолли, SD; Макельбауэр, Пенсильвания; Тейлор, Р.С.; Тернер, С.Дж.; Фаррелл, Дж. Ф. (октябрь 1998 г.). «Неизбежность неудачи: ошибочное предположение о безопасности в современных вычислительных средах» . Материалы 21-й Национальной конференции по безопасности информационных систем . стр. 303–314. Архивировано из оригинала 21 июня 2007 г.

[18] Лепре, Джей; Форд, Брайан; Хиблер, Майк (1996). «Постоянная актуальность локальной операционной системы для глобальных приложений». Материалы 7-го семинара по Европейскому семинару ACM SIGOPS Системная поддержка для мировых приложений - EW 7 . стр. 133–140. дои : 10.1145/504450.504477 . ISBN 978-1-4503-7339-5 . S2CID 10027108 .

[19] Андерсон, Дж. (октябрь 1972 г.). Исследование планирования технологий компьютерной безопасности (PDF) (Отчет). Том. II. Отдел электронных систем ВВС. ЭСД-ТР-73-51, Том. II. Архивировано (PDF) из оригинала 21 июля 2011 г.

[20] Джерри Х. Зальцер; Майк Д. Шредер (сентябрь 1975 г.). «Защита информации в компьютерных системах» . Труды IEEE . 63 (9): 1278–1308. CiteSeerX 10.1.1.126.9257 . дои : 10.1109/PROC.1975.9939 . S2CID 269166 . Архивировано из оригинала 8 марта 2021 г. Проверено 15 июля 2007 г.

[21] «Тонкая изоляция ядра» . Марс-research.github.io . Проверено 15 сентября 2022 г.

[22] Фетцер, Мэри. «Автоматическая изоляция драйверов устройств защищает от ошибок в операционных системах» . Университет штата Пенсильвания через techxplore.com . Проверено 15 сентября 2022 г.

[23] Хуан, Юнчжэ; Нараянан, Викрам; Детвейлер, Дэвид; Хуан, Кайминг; Тан, Банда; Джагер, Трент; Бурцев, Антон (2022). «KSplit: автоматизация изоляции драйверов устройств» (PDF) . Проверено 20 декабря 2023 г.

[24] Джонатан С. Шапиро; Джонатан М. Смит; Дэвид Дж. Фарбер (1999). «ЭРОС». Обзор операционных систем ACM Sigops . 33 (5): 170–185. дои : 10.1145/319344.319163 .

[Dijkstra65-25] Дейкстра, EW Сотрудничающие последовательные процессы . Математика. Департамент технологического университета, Эйндховен, сентябрь 1965 г.

[Hansen70-26] Jump up to: ^а ^б ^с ^д ^и Бринч Хансен 70 стр. 238–241

[27] Харрисон, MC; Шварц, Дж.Т. (1967). «SHARER, система разделения времени для CDC 6600» . Коммуникации АКМ . 10 (10): 659–665. дои : 10.1145/363717.363778 . S2CID 14550794 .

[28] Хакстейбл, DHR; Уорик, Монтана (1967). «Динамические супервизоры – их проектирование и конструкция» . Материалы симпозиума ACM по принципам операционных систем - SOSP '67 . С. 11.1–11.17. дои : 10.1145/800001.811675 . ISBN 978-1-4503-7370-8 . S2CID 17709902 . Проверено 20 декабря 2023 г.

[29] Баярди 1988

[Levin75-30] Jump up to: ^а ^б Левин 75

[Denning80-31] Деннинг 1980

[Nehmer91-32] Немер, Юрген (1991). «Бессмертие операционных систем, или: исследования операционных систем все еще оправданы?» . Конспекты лекций по информатике; Том. 563. Материалы международного семинара по операционным системам 90-х и последующих лет . стр. 77–83. дои : 10.1007/BFb0024528 . ISBN 3-540-54987-0 . Последние 25 лет показали, что исследования архитектуры операционных систем оказали незначительное влияние на существующие основные [ sic ] системы.

[33] Леви 84, стр. 1, цитата: «Хотя сложность компьютерных приложений увеличивается с каждым годом, базовая аппаратная архитектура приложений остается неизменной на протяжении десятилетий».

[Levy84privilegedmode-34] Jump up to: ^а ^б ^с Леви 84, стр. 1, цитата: «Обычные архитектуры поддерживают один привилегированный режим операция. Такая структура приводит к монолитной конструкции; любой модуль, нуждающийся в защите, должен быть частью единого ядра операционной системы. Если бы вместо этого любой модуль мог выполняться в защищенном домене, системы можно было бы построить как набор независимых модулей, расширяемых любым пользователем».

[Linuxisobsoletedebate-35] Jump up to: ^а ^б «Открытые исходные коды: голоса революции открытого исходного кода» . 1-56592-582-3 . 29 марта 1999 г. Архивировано из оригинала 1 февраля 2020 г. . Проверено 24 марта 2019 г.

[TorvaldsTanenbaum-37] Записи дебатов между Торвальдсом и Таненбаумом можно найти на dina.dk. Архивировано 3 октября 2012 г. на Wayback Machine , groups.google.com. Архивировано 26 мая 2013 г. на Wayback Machine , oreilly.com. Архивировано 9 сентября 2014 г. -21 на Wayback Machine и на сайте Эндрю Таненбаума. Архивировано 5 августа 2015 г. на Wayback Machine.

[MatthewRussell-38] Jump up to: ^а ^б Мэтью Рассел. «Что такое Дарвин (и как он работает в Mac OS X)» . О'Рейли Медиа . Архивировано из оригинала 8 декабря 2007 г. Проверено 9 декабря 2008 г. Тесно связанная природа монолитного ядра позволяет ему очень эффективно использовать базовое оборудование [...] Микроядра, с другой стороны, запускают гораздо больше основных процессов в пользовательской среде. [...] К сожалению, эти преимущества достигаются за счет того, что микроядру приходится передавать много информации в пространство ядра и из него посредством процесса, известного как переключение контекста. Переключение контекста приводит к значительным накладным расходам и, следовательно, к снижению производительности.

[39] «Операционные системы/модели ядра — Викиверситет» . ru.wikiversity.org . Архивировано из оригинала 18 декабря 2014 г. Проверено 18 декабря 2014 г.

[Liedtke95-40] Jump up to: ^а ^б ^с ^д Лидтке 95

[Hartig97-41] Хард 97

[Hansen73SupervisorMode-42] Хансен 73, раздел 7.3, стр. 233 « Взаимодействие между различными уровнями защиты требует передачи сообщений по значению »

[43] Маги, Джим. WWDC 2000, сессия 106 — Mac OS X: ядро . Через 14 минут. Архивировано из оригинала 30 октября 2021 г.

[44] «Наноядерная архитектура KeyKOS» . Архивировано из оригинала 21 июня 2011 г.

[45] Бауманн, Эндрю; Бархам, Пол; Даганд, Пьер-Эварист; Харрис, Тим; Айзекс, Ребекка; Питер, Саймон; Роско, Тимоти; Шюпбах, Адриан; Сингхания, Ахилеш (2009). Многоядерность: новая архитектура ОС для масштабируемых многоядерных систем (PDF) . 22-й симпозиум по принципам операционных систем.

[46] «Операционная система Barrelfish» .

[Ball2002-47] Болл: Проекты встроенных микропроцессоров, с. 129

[Hansen2001RC4k-48] Хансен 2001 (ос), стр. 17–18.

[49] «Версия BSTJ документа C.ACM Unix» . bell-labs.com . Архивировано из оригинала 30 декабря 2005 г. Проверено 17 августа 2006 г.

[50] Корбато, Ф.Дж. ; Высоцкий В.А. Введение и обзор системы Multics . Осень 1965 г. Объединенная компьютерная конференция. Архивировано из оригинала 9 июля 2011 г.

[unix-51] Jump up to: ^а ^б «Единая спецификация Unix» . Открытая группа . Архивировано из оригинала 4 октября 2016 г. Проверено 29 сентября 2016 г.

[53] «Месть Юникса» . asymco.com . 29 сентября 2010 года. Архивировано из оригинала 9 ноября 2010 года . Проверено 2 октября 2010 г.

[54] Уилер, Дэвид А. (12 октября 2004 г.). «Ядро Linux 2.6: оно стоит большего!» .

[55] Это сообщество в основном собирается на сайтах Bona Fide OS Development , архивировано 17 января 2022 г. на Wayback Machine , доске объявлений Mega-Tokyo, архивировано 25 января 2022 г. на Wayback Machine , и на других веб-сайтах энтузиастов операционных систем.

[56] Сингх, Амит (декабрь 2003 г.). «XNU: Ядро» . Архивировано из оригинала 12 августа 2011 г.

[57] «Windows — Официальный сайт ОС Microsoft Windows 10 Home и Pro, ноутбуков, ПК, планшетов и многого другого» . windows.com . Архивировано из оригинала 20 августа 2011 г. Проверено 24 марта 2019 г.

[l4-58] «Семейство микроядер L4 — Обзор» . os.inf.tu-dresden.de . Архивировано из оригинала 21 августа 2006 г. Проверено 11 августа 2006 г.

[59] «Микроядро Fiasco — Обзор» . os.inf.tu-dresden.de . Архивировано из оригинала 16 июня 2006 г. Проверено 10 июля 2006 г.

[60] Золлер (неактивен), Хайнц (7 декабря 2013 г.). «Л4Ка — Проект Л4Ка» . www.l4ka.org . Архивировано из оригинала 19 апреля 2001 года . Проверено 24 марта 2019 г.

[61] «Операционные системы QNX» . blackberry.qnx.com . Архивировано из оригинала 24 марта 2019 г. Проверено 24 марта 2019 г.

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ а ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]

[ 11 ]

[ 12 ]

[ 13 ]

[ 14 ]

[ 15 ]

[ 16 ]

[ 17 ]

[ 18 ]

[ 19 ]

[ 20 ]

[ 21 ]

[ 22 ]

[ 23 ]

[ 24 ]

[ 25 ]

[ 26 ]

[ 27 ]

[ 28 ]

[ 29 ]

[ 30 ]

[ 31 ]

[ 32 ]

[ 33 ]

[ 34 ]

[ б ]

[ 35 ]

[ 36 ]

[ 37 ]

[ 38 ]

[ 39 ]

[ 40 ]

[ 41 ]

[ 42 ]

[ 43 ]

[ 44 ]

[ 45 ]

[ 46 ]

[ 47 ]

[ 48 ]

[ 49 ]

[ с ]

[ 50 ]

[ 51 ]

[ 52 ]

[ 53 ]

[ 54 ]

[ 55 ]

[ 56 ]

[ 57 ]

[ 58 ]