stringtranslate.com

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

Чрезмерное упрощение того, как ядро ​​соединяет прикладное программное обеспечение с аппаратным обеспечением компьютера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Защита

Важным фактором при проектировании ядра является поддержка, которую оно обеспечивает для защиты от ошибок ( отказоустойчивость ) и от вредоносного поведения ( безопасность ). Эти два аспекта обычно четко не разграничиваются, и принятие этого разграничения при проектировании ядра приводит к отказу от иерархической структуры защиты . [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 во встраиваемых системах .

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

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

Микроядра

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

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

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

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

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

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

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

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

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

К началу 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. Собственная macOS Apple использует гибридное ядро ​​под названием 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 году . используя ресурсы компьютера, а система разделения времени должна предоставлять время ЦП активному пользователю в эти периоды. Наконец, системы обычно предлагали иерархию памяти в несколько уровней, и разделение этого дорогостоящего ресурса привело к серьезным разработкам в системах виртуальной памяти .

Амига

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

Юникс

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

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

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

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

С течением времени вычислительная модель изменилась, и подход 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 была впервые выпущена в 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 с открытым исходным кодом , изначально созданное для образовательных целей, теперь ориентировано на то, чтобы стать высоконадежной и самовосстанавливающейся микроядерной ОС.

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

Примечания

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

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

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

Источники

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

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