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

Для использования в других целях см. Ядро (значения).
"Ядро (вычисления)" перенаправляется сюда. Для использования в других целях см. Ядро (значения).
«Ядро (информатика)» перенаправляется сюда. Не следует путать с Вычислить ядро, Метод ядра, или же Ядро (обработка изображений).

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

Ядро соединяет программное обеспечение к оборудованию компьютера.

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

Ядро интерфейс это низкий уровень слой абстракции. Когда процесс запрашивает службу к ядру, оно должно вызывать системный вызов, обычно через функцию оболочки, которая предоставляется приложениям пользовательского пространства системными библиотеками, которые встраивают ассемблерный код для входа в ядро ​​после загрузки регистров ЦП с номером системного вызова и его параметрами (например, UNIX-подобные операционные системы выполняют эту задачу с помощью Стандартная библиотека C ).

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

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

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

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

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

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

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

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

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

Дальнейшая информация: Управление памятью (операционные системы)

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

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

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

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

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

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

  • Прямое взаимодействие
  • Использование высокоуровневого интерфейса (Видео 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]

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

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

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

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

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

К недостаткам можно отнести:

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

Примеры систем с языковой защитой включают: JX и Microsoft с Сингулярность.

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

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

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

Идея ядра, в котором устройства ввода / вывода обрабатываются одинаково с другими процессами, как параллельные взаимодействующие процессы, была впервые предложена и реализована Бринч Хансен (хотя подобные идеи были предложены в 1967 г.[23][24]). В описании этого Хансеном "общие" процессы называются внутренние процессы, а устройства ввода / вывода называются внешние процессы.[22]

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

Подходы к дизайну ядра

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

Принцип разделение механизма и политики Это существенная разница между философией микро и монолитного ядра.[25][26] Здесь механизм - это поддержка, которая позволяет реализовать множество различных политик, в то время как политика - это особый «режим работы». Пример:

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

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

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

Пер Бринч Хансен представил аргументы в пользу разделения механизма и политики.[5][22] Неспособность должным образом выполнить это разделение является одной из основных причин отсутствия существенных инноваций в существующих операционных системах.[5] проблема, распространенная в компьютерной архитектуре.[27][28][29] Монолитный дизайн вызван архитектурным подходом к защите "режим ядра" / "режим пользователя" (технически называемый домены иерархической защиты ), что является обычным явлением в обычных коммерческих системах;[30] Фактически, каждый модуль, нуждающийся в защите, поэтому предпочтительно включен в ядро.[30] Эта связь между монолитным дизайном и «привилегированным режимом» может быть преобразована в ключевой вопрос разделения механизма и политики;[5] на самом деле архитектурный подход «привилегированного режима» объединяет механизм защиты с политиками безопасности, в то время как основной альтернативный архитектурный подход, адресация на основе возможностей, четко различает их, что, естественно, приводит к микроядерному дизайну[5] (видеть Разделение защиты и безопасности ).

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

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

Основная статья: Монолитное ядро
Схема монолитного ядра

В монолитном ядре все службы ОС работают вместе с основным потоком ядра, поэтому они также находятся в одной области памяти. Такой подход обеспечивает широкий и мощный доступ к оборудованию. Некоторые разработчики, такие как UNIX разработчик Кен Томпсон, утверждают, что «проще реализовать монолитное ядро»[31] чем микроядра. Основными недостатками монолитных ядер являются зависимости между компонентами системы (ошибка в драйвере устройства может привести к сбою всей системы) и тот факт, что большие ядра могут стать очень сложными в обслуживании.

Монолитные ядра, которые традиционно использовались Unix-подобными операционными системами, содержат все основные функции операционной системы и драйверы устройств. Это традиционный дизайн систем UNIX. Монолитное ядро ​​- это одна программа, которая содержит весь код, необходимый для выполнения каждой связанной с ядром задачи. Каждая часть, доступная большинству программ, которая не может быть помещена в библиотеку, находится в пространстве ядра: драйверы устройств, планировщик, обработка памяти, файловые системы и сетевые стеки. Многие системные вызовы предоставляются приложениям, чтобы позволить им получить доступ ко всем этим службам. Монолитное ядро, изначально загруженное подсистемами, которые могут не понадобиться, может быть настроено так, чтобы оно было таким же быстрым, как или быстрее, чем то, которое было специально разработано для оборудования, хотя и более актуально в общем смысле. Современные монолитные ядра, такие как ядра Linux (одно из ядер GNU операционная система) и FreeBSD обе из которых относятся к категории Unix-подобных операционных систем, имеют возможность загружать модули во время выполнения, что позволяет легко расширять возможности ядра по мере необходимости, помогая при этом минимизировать объем кода, выполняемого в пространстве ядра. В монолитном ядре некоторые преимущества зависят от следующих моментов:

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

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

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

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

Примеры монолитных ядер: AIX ядро, ядро ​​HP-UX и ядро ​​Solaris.

Микроядра

Основная статья: Микроядро

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

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

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

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

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

Однако у микроядра есть недостатки. Некоторые:

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

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

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

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

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

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

Спектакль

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

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

Фактически, как предполагалось в 1995 году, причинами низкой производительности микроядер с таким же успехом могли быть: (1) фактическая неэффективность всего микроядра. подход, (2) частный концепции реализованы в этих микроядрах, и (3) конкретный выполнение этих концепций. Следовательно, оставалось изучить, будет ли решение для построения эффективного микроядра, в отличие от предыдущих попыток, применением правильных методов построения.[36]

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

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

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

Основная статья: Гибридное ядро

Гибридные ядра используются в большинстве коммерческих операционных систем, таких как Майкрософт Виндоус NT 3.1, NT 3.5, NT 3.51, NT 4.0, 2000, XP, Vista, 7, 8, 8.1 и 10. Apple Inc. собственный macOS использует гибридное ядро, называемое XNU который основан на коде из OSF / 1 с Ядро Маха (ОСФМК 7.3)[39] и FreeBSD с монолитное ядро. Они похожи на микроядра, за исключением того, что они включают некоторый дополнительный код в пространстве ядра для повышения производительности. Эти ядра представляют собой компромисс, который был реализован некоторыми разработчиками для учета основных преимуществ как монолитных, так и микроядер. Эти типы ядер являются расширениями микроядер с некоторыми свойствами монолитных ядер. В отличие от монолитных ядер, эти типы ядер не могут самостоятельно загружать модули во время выполнения. Гибридные ядра - это микроядра, которые имеют некоторый «несущественный» код в пространстве ядра, чтобы код выполнялся быстрее, чем в пользовательском пространстве. Гибридные ядра - это компромисс между монолитной и микроядерной конструкциями. Это подразумевает запуск некоторых служб (например, Сетевой стек или файловая система ) в пространстве ядра, чтобы снизить накладные расходы на производительность традиционного микроядра, но по-прежнему выполнять код ядра (например, драйверы устройств) в качестве серверов в пространстве пользователя.

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

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

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

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

Наноядра

Основная статья: Наноядро

Наноядро делегирует практически все услуги, включая даже самые простые, такие как контроллеры прерываний или таймер - к драйверы устройств сделать потребность ядра в памяти даже меньше, чем у традиционного микроядра.[40]

Экзоядра

Основная статья: Exokernel

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

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

История развития ядра

Ядра ранних операционных систем

Основная статья: История операционных систем

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

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

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

Основная статья: Совместное времяпровождение

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

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

Amiga

Основная статья: AmigaOS

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

Unix

Основная статья: Unix
Диаграмма семейных отношений предшественник / наследник для Unix-подобный системы

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

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

В модели Unix Операционная система состоит из двух частей: во-первых, огромного набора служебных программ, которые управляют большинством операций; во-вторых, ядро, которое запускает программы.[45] В Unix, с точки зрения программирования, разница между ними довольно тонкая; ядро - это программа, работающая в режиме супервизора,[46] который действует как загрузчик программ и контролирует небольшие служебные программы, составляющие остальную часть системы, и обеспечивает запирание и Ввод / вывод услуги для этих программ; кроме того, ядро ​​вообще не вмешивалось в пространство пользователя.

С годами модель вычислений изменилась, и подход Unix к все как файл или поток байтов больше не был таким универсальным, как раньше. Хотя Терминал может рассматриваться как файл или поток байтов, который печатается или читается из него, то же самое не похоже на графический интерфейс пользователя. Сети возникла другая проблема. Даже если сетевое взаимодействие можно сравнить с доступом к файлам, низкоуровневая пакетно-ориентированная архитектура имеет дело с дискретными фрагментами данных, а не с целыми файлами. По мере роста возможностей компьютеров Unix становилась все более загроможденной кодом. Это также связано с тем, что модульность ядра Unix широко масштабируется.[47] Хотя в ядрах могло быть 100000 строки кода в семидесятых и восьмидесятых годах ядра вроде Linux современных преемников Unix, таких как GNU, имеют более 13 миллионов строк.[48]

Современные производные от Unix обычно основаны на монолитных ядрах, загружающих модули. Примеры этого: Ядро Linux во многих распределения из GNU, IBM AIX, так же хорошо как Распространение программного обеспечения Беркли вариантные ядра, такие как FreeBSD, СтрекозаBSD, OpenBSD, NetBSD, и macOS. Помимо этих альтернатив, разработчики-любители поддерживают активную Сообщество разработчиков операционных систем, заполненные самописными ядрами для хобби, которые в большинстве случаев разделяют многие функции с ядрами Linux, FreeBSD, DragonflyBSD, OpenBSD или NetBSD и / или совместимы с ними.[49]

Mac OS

Основные статьи: Классическая Mac OS и macOS

яблоко впервые запустил классическая Mac OS в 1984 году вместе с Macintosh персональный компьютер. Apple перешла на дизайн наноядра в Mac OS 8.6. На фоне этого современные macOS (первоначально названная Mac OS X) основана на Дарвин, в котором используется гибридное ядро, называемое XNU, который был создан путем объединения 4.3BSD ядро и Ядро Маха.[50]

Майкрософт Виндоус

Основная статья: История 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 10.

В архитектура Windows NT Ядро считается гибридным, поскольку само ядро ​​содержит такие задачи, как диспетчер окон и диспетчеры IPC, с многоуровневой моделью подсистемы клиент / сервер.[51]

IBM Supervisor

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

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

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

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

Несмотря на то что Мах, разработанная в Университет Карнеги Меллон с 1985 по 1994 год является наиболее известным микроядром общего назначения, другие микроядра были разработаны с более конкретными целями. В Семейство микроядер L4 (в основном ядро ​​L3 и L4) было создано, чтобы продемонстрировать, что микроядра не обязательно медленные.[52] Новые реализации, такие как Фиаско и Фисташковый умеют бегать Linux рядом с другими процессами L4 в отдельных адресных пространствах.[53][54]

Кроме того, QNX это микроядро, которое в основном используется в встроенные системы,[55] и программное обеспечение с открытым исходным кодом МИНИКС изначально создавались для образовательных целей, но теперь ориентированы на то, чтобы быть очень надежный и самовосстановление микроядра ОС.

Смотрите также

Примечания

  1. ^ Это может зависеть от Компьютерная архитектура
  1. ^ а б «Ядро». Linfo. Группа пользователей Bellevue Linux. Получено 15 сентября 2016.
  2. ^ Рэндал Э. Брайант; Дэвид Р. О’Халларон (2016). Компьютерные системы: взгляд программиста (Третье изд.). Пирсон. п. 17. ISBN  978-0134092669.
  3. ^ ср. Демон (вычисления)
  4. ^ а б Рох 2004
  5. ^ а б c d е ж грамм Вульф, 1974, стр. 337–345
  6. ^ а б Зильбершатц 1991
  7. ^ Таненбаум, Эндрю С. (2008). Современные операционные системы (3-е изд.). Прентис Холл. С. 50–51. ISBN  978-0-13-600663-3. . . . почти все системные вызовы [вызываются] из программ C путем вызова библиотечной процедуры. . . Библиотечная процедура. . . выполняет инструкцию TRAP для переключения из пользовательского режима в режим ядра и начала выполнения. . .
  8. ^ Деннинг 1976
  9. ^ Swift 2005, стр.29 цитата: «изоляция, управление ресурсами, проверка решений (проверка) и устранение ошибок».
  10. ^ Шредер 72
  11. ^ а б Липа 76
  12. ^ Стефан Эраниан и Дэвид Мосбергер, Виртуальная память в ядре Linux IA-64, Prentice Hall PTR, 2002 г.
  13. ^ Зильбершатц и Гальвин, Концепции операционных систем, 4-е изд., Стр. 445 и 446
  14. ^ Хох, Чарльз; Дж. К. Браун (июль 1980 г.). «Реализация возможностей PDP-11/45». Обзор операционных систем ACM SIGOPS. 14 (3): 22–32. Дои:10.1145/850697.850701. S2CID  17487360.
  15. ^ а б Языковой подход к безопасности, Шнайдер Ф., Морриссетт Г. (Корнельский университет) и Харпер Р. (Университет Карнеги-Меллона)
  16. ^ а б c П. А. Лоскокко, С. Д. Смолли, П. А. Макельбауэр, Р. К. Тейлор, С. Дж. Тернер и Дж. Ф. Фаррелл. Неизбежность отказа: ошибочное предположение о безопасности в современных вычислительных средах В архиве 2007-06-21 на Wayback Machine. В материалах 21-й Национальной конференции по безопасности информационных систем, страницы 303–314, октябрь 1998 г. [1].
  17. ^ Лепро, Джей; Форд, Брайан; Хиблер, Майк (1996). «Постоянная актуальность локальной операционной системы для глобальных приложений». Труды 7-го семинара по европейскому семинару ACM SIGOPS Поддержка систем для всемирных приложений - EW 7. п. 133. Дои:10.1145/504450.504477. S2CID  10027108.
  18. ^ Дж. Андерсон, Исследование планирования технологий компьютерной безопасности В архиве 2011-07-21 на Wayback Machine, Air Force Elect. Системное отделение, ESD-TR-73-51, октябрь 1972 г.
  19. ^ * Джерри Х. Зальцер; Майк Д. Шредер (сентябрь 1975 г.). «Защита информации в компьютерных системах». Труды IEEE. 63 (9): 1278–1308. CiteSeerX  10.1.1.126.9257. Дои:10.1109 / PROC.1975.9939. S2CID  269166.
  20. ^ Джонатан С. Шапиро; Джонатан М. Смит; Дэвид Дж. Фарбер (1999). «EROS: система быстрых возможностей». Труды семнадцатого симпозиума ACM по принципам операционных систем. 33 (5): 170–185. Дои:10.1145/319344.319163.
  21. ^ Дейкстра, Э. В. Взаимодействующие последовательные процессы. Математика. Dep., Technological U., Эйндховен, сентябрь 1965 г.
  22. ^ а б c d е Бринч Хансен 70 с. 238–241
  23. ^ «SHARER, система разделения времени для CDC 6600». Получено 2007-01-07.
  24. ^ «Динамические супервайзеры - их конструкция и конструкция». Получено 2007-01-07.
  25. ^ Байарди 1988
  26. ^ а б Левина 75
  27. ^ Деннинг 1980
  28. ^ Юрген Нехмер "Бессмертие операционных систем, или: оправданы ли исследования операционных систем? ", Конспект лекций по информатике; Vol. 563. Труды международного семинара по операционным системам 90-х годов и не только. С. 77–83 (1991) ISBN  3-540-54987-0 [2] цитата: «Последние 25 лет показали, что исследования архитектуры операционной системы оказали незначительное влияние на существующий основной поток [sic ] системы ".
  29. ^ Леви 84, стр. 1 цитата: «Хотя сложность компьютерных приложений с каждым годом увеличивается, основная аппаратная архитектура приложений остается неизменной в течение десятилетий».
  30. ^ а б c Леви 84, стр. 1 цитата: «Обычные архитектуры поддерживают один привилегированный режим работы. Эта структура ведет к монолитной конструкции; любой модуль, нуждающийся в защите, должен быть частью единого ядра операционной системы.Если вместо этого любой модуль может выполняться в защищенном домене, системы могут быть построены как набор независимых модулей, расширяемых любым пользователем ».
  31. ^ «Открытые источники: голоса революции открытого исходного кода». 1-56592-582-3. 29 марта 1999 г.
  32. ^ Виртуальная адресация чаще всего достигается с помощью встроенного блок управления памятью.
  33. ^ Записи дебатов между Торвальдсом и Таненбаумом можно найти на dina.dk В архиве 2012-10-03 на Wayback Machine, groups.google.com, oreilly.com и Сайт Эндрю Таненбаума
  34. ^ а б Мэтью Рассел. «Что такое Дарвин (и как он работает в Mac OS X)». O'Reilly Media. цитата: «Сильно связанная природа монолитного ядра позволяет ему очень эффективно использовать базовое оборудование [...] Микроядра, с другой стороны, запускают гораздо больше основных процессов в пользовательском пространстве. [...] К сожалению, эти преимущества достигаются за счет того, что микроядру приходится передавать большой объем информации в пространство ядра и из него посредством процесса, известного как переключение контекста. Переключение контекста приводит к значительным накладным расходам и, следовательно, к снижению производительности ».
  35. ^ «Операционные системы / модели ядра - Викиверситет». en.wikiversity.org.
  36. ^ а б c d Liedtke 95
  37. ^ Härtig 97
  38. ^ Хансен 73, раздел 7.3 стр. 233 "взаимодействие между разными уровнями защиты требует передачи сообщений по значению"
  39. ^ Видео Apple WWDC (19 февраля 2017 г.). «Apple WWDC 2000, сессия 106 - Mac OS X: ядро» - через YouTube.
  40. ^ KeyKOS Nanokernel Архитектура В архиве 2011-06-21 на Wayback Machine
  41. ^ Ball: Конструкции встроенных микропроцессоров, стр. 129
  42. ^ Хансен 2001 (OS), стр.17–18
  43. ^ "BSTJ-версия документа C.ACM Unix". bell-labs.com.
  44. ^ Введение и обзор системы Multics, Ф. Х. Корбато и В. А. Высоцкий.
  45. ^ а б «Единая спецификация Unix». Открытая группа. Архивировано из оригинал на 2016-10-04. Получено 2016-09-29.
  46. ^ Наивысший уровень привилегий имеет разные имена в разных архитектурах, например, режим супервизора, режим ядра, CPL0, DPL0, кольцо 0 и т. Д. Кольцо (компьютерная безопасность) для дополнительной информации.
  47. ^ "Месть Unix". asymco.com. 29 сентября 2010 г.
  48. ^ Ядро Linux 2.6: оно того стоит!, Дэвид А. Уиллер, 12 октября 2004 г.
  49. ^ Это сообщество в основном собирается в Добросовестная разработка ОС, Доска объявлений Mega-Tokyo и другие веб-сайты энтузиастов операционных систем.
  50. ^ XNU: ядро В архиве 2011-08-12 на Wayback Machine
  51. ^ "Windows - официальный сайт ОС Microsoft Windows 10 Home и Pro, ноутбуков, ПК, планшетов и др.". windows.com.
  52. ^ «Семейство микроядер L4 - Обзор». os.inf.tu-dresden.de.
  53. ^ "Микроядро Fiasco - Обзор". os.inf.tu-dresden.de.
  54. ^ Золлер (инактив), Хайнц (7 декабря 2013 г.). «L4Ka - Проект L4Ka». www.l4ka.org.
  55. ^ «Операционные системы QNX». blackberry.qnx.com.

Рекомендации

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

внешняя ссылка