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

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

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

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

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

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

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

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

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

Устройства ввода / вывода [ править ]

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

Управление ресурсами [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

Ядро должно поддерживать список доступных устройств. Этот список может быть известен заранее (например, во встроенной системе, где ядро ​​будет перезаписано при изменении доступного оборудования), настроен пользователем (обычно на старых ПК и в системах, которые не предназначены для личного использования) или обнаружен операционная система во время выполнения (обычно это называется plug and play ). В системах plug-and-play диспетчер устройств сначала выполняет сканирование на различных аппаратных шинах , таких как Peripheral Component Interconnect (PCI) или Universal Serial Bus (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 «s Singularity .

Процесс сотрудничества [ править ]

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

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

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

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

Подходы к дизайну ядра [ править ]

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

Принцип разделения механизма и политики - существенное различие между философией микро и монолитного ядра. ^{[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и пользовательские сеансы Hurd могут быть полными снимками самой системы или видами, как это называется. Сама суть архитектуры микроядра иллюстрирует некоторые ее преимущества:

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

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

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

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

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

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

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

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

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

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

Производительность [ править ]

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

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

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

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

Гибридные (или модульные) ядра [ править ]

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

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

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

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

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

Наноядра [ править ]

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

Экзоядра [ править ]

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

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

История развития ядра [ править ]

Ядра ранних операционных систем [ править ]

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

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

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

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

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

Амига [ править ]

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

Unix [ править ]

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

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

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

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

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

Mac OS [ править ]

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

Microsoft Windows [ править ]

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

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

Архитектура Windows NT ядер «s считается гибридным ядром , поскольку само ядро содержит такие задачи, как Window Manager и менеджер IPC, с клиентами / сервером слоистого подсистема модели. ^[51] Оно было разработано как модифицированное микроядро , поскольку ядро ​​Windows NT находилось под влиянием микроядра Маха, но не удовлетворяет всем критериям чистого микроядра.

IBM Supervisor [ править ]

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

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

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

Разработка микроядер [ править ]

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

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

См. Также [ править ]

• Сравнение ядер операционных систем
• Межпроцессного взаимодействия
• Операционная система
• Виртуальная память

Примечания [ править ]

Ссылки [ править ]

Дальнейшее чтение [ править ]

• Эндрю Таненбаум , Операционные системы - проектирование и реализация (третье издание) ;
• Эндрю Таненбаум, « Современные операционные системы» (второе издание) ;
• Дэниел П. Бове , Марко Чезати , ядро Linux ;
• Дэвид А. Петерсон , Нитин Индуркхья , Паттерсон, организация и дизайн компьютеров , Морган Коффман ( ISBN 1-55860-428-6 )  ;
• BS Chalk , Компьютерная организация и архитектура , Macmillan P. ( ISBN 0-333-64551-0 ). 

Внешние ссылки [ править ]

В Викиверситете есть учебные ресурсы о моделях ядра по адресу Операционные системы / модели ядра

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