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

редактировать
Ядро операционной системы компьютера

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

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

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

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

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

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

Содержание

  • 1 Оперативная память
  • 2 Управление вводом / выводом
  • 3 Управление памятью
  • 5 Управление устройствами
  • 6 Системные вызовы
  • 7 Структура ядра решения
    • 7.1 Защита
      • 7.1.1 Аппаратная или языковая защита
    • 7.2 Взаимодействие процессов
    • 7.3 Управление вводом / выводом
  • 8 Подходы к проектированию в масштабе всего ядра
    • 8.1 Монолитные ядра
    • 8.2 Микроядра
    • 8.3 Монолитные ядра и микроядра
      • 8.3.1 Производительность
    • 8.4 Гибридные (или модульные) ядра
    • 8.5 Наноядра
    • 8.6 Экзоядра
  • 9 История разработки ядра
    • 9.1 Ранние ядра ядра систем
    • 9.2 Операционные системы с разделением времени
    • 9.3 Amiga
    • 9.4 Unix
    • 9.5 Mac OS
    • 9.6 Microsoft Windows
    • 9.7 IBM Supervisor
    • 9.8 Разработка микроядер
  • 10 См.
  • 11 Примечания
  • 12 Ссылки
  • 13 Дополнительная литература
  • 14 Внешние ссылки

Память с произвольным доступом

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Решения по проектированию ядра

Защита

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

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

Поддержка доменов иерархической защиты обычно реализуется с режима ЦП.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Взаимодействие процессов

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

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

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

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

Подходы к проектированию в масштабе всего ядра

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

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

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

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

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

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

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

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

Схема монолитного ядра

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Гибридные ядра используются в коммерческих системах, таких как 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 <178.>, который основан на коде из OSF / 1 ядра Mach (OSFMK 7.3) и FreeBSD монолитного ядра. Они похожи на микроядра, за исключением того, что они включают некоторый дополнительный код в пространстве для повышения производительности. Эти устройства включают в себя компромисс, который был реализован некоторые устройства для учета основных преимуществ монолитных, так и микроядер. Эти типы ядер расширяются микроядер с некоторыми свойствами монолитных ядер. В отличие от монолитных ядер, эти типы ядер не могут самостоятельно загружать модули во время выполнения. Гибридные ядра - это микроядра, который имеет некоторый «несущественный» код в ядре для того, чтобы код выполнялся быстрее. Гибридные ядра - это компромисс между монолитной и микроядерной конструкцией. Это подразумевает запуск некоторых служб (таких как сетевой стек или файловая система ) в тестовом ядре, чтобы снизить накладные расходы на производительность традиционного этого микроядра, но при этом все еще запускает код ядра (например, драйверы устройств).) в качестве сервера в пользовательском пространстве.

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

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

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

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

Наноядро

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

Экзоядра

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

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

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

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

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

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

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

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

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

Amiga

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

Unix

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

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

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

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

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

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

Mac OS

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

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 считается гибридным ядром, потому что само ядро ​​содержит такие задачи, как диспетчер окон и диспетчеры IPC, с многоуровневой моделью подсистемы клиент / сервер.

IBM Supervisor

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

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

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

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

Хотя Mach, разработанная в Университете Карнеги-Меллона с 1985 по 1994 год, является лучшей. -известное микроядро общего назначения, другие микроядра были разработаны с более конкретными целями. Семейство микроядра L4 (в основном ядро ​​L3 и L4) было создано, чтобы продемонстрировать, что микроядра не обязательно медленные. Более новые реализации, такие как Fiasco, могут запускать Linux рядом с другими процессами L4 в отдельных адресных пространствах.

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

См. Также

Примечания

Ссылки

Дополнительная литература

  • Эндрю Таненбаум, Операционные системы - разработка и реализация (третье издание);
  • Эндрю Таненбаум, Современные операционные системы (второе издание);
  • , ядро ​​Linux;
  • , Паттерсон, Организация и дизайн компьютеров, (ISBN 1-55860-428-6 );
  • , Организация и архитектура компьютеров, Macmillan P. (ISBN 0-333-64551-0 ).

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

В Викиверситете есть обучающие ресурсы по моделям ядра в операционных системах / Kernel Models
Последняя правка сделана 2021-05-25 04:29:45
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте