Mach (ядро) - Mach (kernel)

Мах
Оригинальный автор (ы)Университет Карнеги Меллон
изначальный выпуск1985; 35 лет назад (1985)
Стабильный выпуск
3.0 / 1994; 26 лет назад (1994)
ТипМикроядро
Интернет сайтПроект Мах

Мах (/мɑːk/)[1] это ядро разработан в Университет Карнеги Меллон поддерживать Операционная система исследования, в первую очередь распределен и параллельные вычисления. Мах часто упоминается как один из самых ранних примеров микроядро. Однако не все версии Mach являются микроядрами. Производные Маха являются основой ядра операционной системы в GNU Hurd и из яблоко с XNU ядро, используемое в macOS, iOS, iPadOS, tvOS, и watchOS.

Проект в Карнеги-Меллон работал с 1985 по 1994 год.[2] заканчивается на 3,0 Маха, что является истинным микроядро. Mach был разработан как замена ядра в BSD версия Unix, поэтому нет необходимости разрабатывать новую операционную систему на его основе. Mach и его производные существуют в ряде коммерческих операционных систем. К ним относятся все, использующие XNU ядро операционной системы, которое включает в себя более ранний не-микроядерный Mach в качестве основного компонента. Мах виртуальная память система управления также была принята в 4.4BSD разработчиками BSD в CSRG,[3] и появляется в современных Unix-системах, основанных на BSD, таких как FreeBSD.

Мах - логический преемник концепции Карнеги-Меллона. Акцентное ядро. Ведущий разработчик проекта Mach, Ричард Рашид, работал в Microsoft с 1991 года занимал различные руководящие должности, связанные с Microsoft Research разделение. Еще один из первых разработчиков Mach, Ави Теванян, ранее был руководителем отдела программного обеспечения в Следующий, затем директор по программным технологиям в Apple Inc. до марта 2006 г.[4]

История

Имя

В то время как разработчики однажды на этапе наименования должны были ехать на велосипеде на обед по дождливым грязевым лужам Питтсбурга, Теванян пошутил слово гадость может служить backronym для них MокончательноUсер (или Mсверхпроцессор Uуниверсальный) Cобщение KЭрнель. Итальянский инженер CMU Дарио Джузе позже спросил руководителя проекта Рика Рашида о текущем названии проекта и получил в качестве ответа «MUCK», хотя и не прописанный, а просто произносимый как IPA:[mʌk] который он, согласно Итальянский алфавит, писал как Mach. Рашиду так понравилось написание Джузе «Мах», что оно возобладало.[5]

Unix каналы

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

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

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

Новые концепции

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

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

Алеф был реализован на Данные General Eclipse миникомпьютеры и был тесно связан с ними. Эта машина была далека от идеала, поскольку требовала копирования памяти между программами, что приводило к значительным накладным расходам производительности. К тому же это было довольно дорого. Тем не менее, Алеф доказал, что базовая система работоспособна, и продолжил демонстрировать компьютерная кластеризация копируя память на ранний Ethernet интерфейс.

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

Эта концепция была подхвачена в Карнеги-Меллон, который адаптировал Алеф для Рабочая станция PERQ и реализовал это с помощью копирования при записи. Перенос прошел успешно, но в результате Акцентное ядро имел ограниченное практическое применение, поскольку не запускал существующее программное обеспечение. Более того, Accent был так же тесно связан с PERQ, как Алеф - с Eclipse.

Мах

Основным изменением между этими экспериментальными ядрами и Mach было решение сделать версию существующего ядра 4.2BSD, повторно реализованную на основе концепций передачи сообщений Accent. Такое ядро ​​будет двоично-совместимо с существующим программным обеспечением BSD, что сделает систему незамедлительно полезной для повседневного использования, оставаясь при этом полезной экспериментальной платформой. Кроме того, новое ядро ​​с самого начала будет спроектировано для поддержки нескольких процессорных архитектур, даже позволяя создавать гетерогенные кластеры. Чтобы привести систему в рабочее состояние как можно быстрее, система должна быть реализована, начиная с существующего кода BSD и повторно внедряя его постепенно, как межпроцессного взаимодействия -программы (на базе IPC). Таким образом, Mach будет начинаться как монолитная система, подобная существующим UNIX-системам, и со временем будет развиваться в сторону концепции микроядра.[4]

Mach начинал в основном как попытку создать четко определенный, основанный на UNIX, переносимый Accent. В результате получился краткий список общих концепций:[6][7]

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

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

Под Mach, как и в UNIX, операционная система снова становится в первую очередь набором утилит. Как и в случае с UNIX, Mach сохраняет концепцию драйвера для работы с оборудованием. Следовательно, все драйверы для существующего оборудования должны быть включены в микроядро. Другие архитектуры на основе Уровень аппаратной абстракции или же экзоядра мог переместить драйверы из микроядра.

Основное отличие UNIX в том, что вместо утилит, обрабатывающих файлы, они могут обрабатывать любую «задачу». Больше кода операционной системы было перемещено из ядра в пространство пользователя, что привело к гораздо меньшему количеству ядра и появлению термина микроядро. В отличие от традиционных систем, под Mach процесс или «задача» может состоять из нескольких потоков. Хотя это обычное явление в современных системах, Mach была первой системой, которая определяла задачи и потоки таким образом. Задача ядра была сокращена с того, чтобы быть операционной системой, до обслуживания «утилит» и планирования их доступа к оборудованию.

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

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

Поддержка потоков и параллелизма выиграла от передачи сообщений с помощью механизмов IPC, поскольку задачи теперь состояли из нескольких потоков кода, которые Mach мог «замораживать» и «размораживать» во время обработки сообщений. Это позволяло распределить систему по нескольким процессорам либо напрямую, как в большинстве сообщений Маха, либо путем добавления кода для копирования сообщения на другой процессор, если это необходимо. В традиционном ядре это сложно реализовать; система должна быть уверена, что разные программы не пытаются записывать в одну и ту же память с разных процессоров. Однако порты Mach, их процесс доступа к памяти, делают это четко определенным и легко реализуемым, и были сделаны первоклассный гражданин в этой системе.

Система IPC изначально имела проблемы с производительностью, поэтому было разработано несколько стратегий для минимизации воздействия. Как и его предшественник, Акцент, Mach использовал единый механизм разделяемой памяти для физической передачи сообщения от одной программы к другой. Физическое копирование сообщения будет слишком медленным, поэтому Mach полагается на блок управления памятью (MMU) для быстрого отображения данных из одной программы в другую. Только если данные записываются, их нужно будет физически скопировать, процесс называется "копирование при записи ".

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

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

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

В отличие от UNIX, который был разработан без учета многопроцессорности, Mach полностью поддерживает многопроцессорность. Его поддержка многопроцессорности также является чрезвычайно гибкой - от систем с общей памятью до систем без памяти, разделяемой между процессорами. Mach предназначен для работы в компьютерных системах с числом процессоров от одного до нескольких тысяч. Вдобавок Mach легко переносится на множество компьютерных архитектур. Ключевой целью Mach является создание распределенной системы, способной работать на разнородном оборудовании. (Приложение B, Понятия операционной системы )

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

Разработка

Изначально Mach был размещен как дополнительный код, написанный непосредственно в существующем ядре 4.2BSD, что позволяло команде работать над системой задолго до ее завершения. Работа началась с уже работающей системы IPC / портов Accent и перешла к другим ключевым частям ОС, задачам, потокам и виртуальной памяти. По мере того, как части были завершены, различные части системы BSD были переписаны для вызова в Mach, и во время этого процесса также были внесены изменения в 4.3BSD.

К 1986 году система была завершена до такой степени, что могла работать самостоятельно на DEC VAX. Несмотря на то, что это мало что представляло практической ценности, цель создания микроядра была реализована. Вскоре за этим последовали версии о ПК IBM RT и для Sun Microsystems 68030 на базе рабочих станций, доказывающих портативность системы. К 1987 г. в список вошли Encore Multimax и Последовательный баланс машины, проверяющие способность Маха работать на многопроцессорных системах. В том же году был выпущен общедоступный Релиз 1, а в следующем - Релиз 2.

Все это время обещание «настоящего» микроядра еще не реализовывалось. Эти ранние версии Mach включали большую часть 4.3BSD в ядро, систему, известную как POE Server, в результате чего ядро ​​было больше, чем UNIX, на котором оно было основано. Идея, однако, заключалась в том, чтобы переместить уровень UNIX из ядра в пространство пользователя, где с ним можно было бы легче работать и даже полностью заменить. К сожалению, производительность оказалась серьезной проблемой, и для решения этой проблемы был внесен ряд архитектурных изменений. Неуклюжие проблемы с лицензированием UNIX также беспокоили исследователей, поэтому эта ранняя попытка предоставить нелицензионную системную среду, подобную UNIX, продолжала находить применение и в дальнейшем развитии Mach.

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

Видимость Маха значительно улучшилась, когда Фонд открытого программного обеспечения (OSF) объявили, что будут размещать будущие версии OSF / 1 на 2,5 Маха, а также исследовали 3 Маха. 2,5 Маха было также выбрано для Следующий шаг система и ряд коммерческих производителей мультипроцессоров. Mach 3 привел к ряду попыток портировать другие части операционных систем для микроядра, включая IBM с ОС на рабочем месте и несколько усилий яблоко создать кроссплатформенную версию классическая Mac OS.[8]

Проблемы с производительностью

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

Некоторые из более эзотерических функций Маха также были основаны на том же механизме IPC. Например, Mach с легкостью поддерживал многопроцессорные машины. В традиционном ядре необходимо провести большую работу, чтобы повторно въезжающий или же прерываемый, поскольку программы, работающие на разных процессорах, могут одновременно обращаться к ядру. В соответствии с Mach, части операционной системы изолированы на серверах, которые могут работать, как и любая другая программа, на любом процессоре. Хотя теоретически ядро ​​Mach также должно быть реентерабельным, на практике это не проблема, потому что время его отклика настолько велико, что он может просто ждать и обслуживать запросы по очереди. Mach также включал сервер, который мог пересылать сообщения не только между программами, но даже по сети, что было областью интенсивного развития в конце 1980-х - начале 1990-х годов.

К сожалению, использование IPC почти для всех задач оказало серьезное влияние на производительность. Тесты на оборудовании 1997 года показали, что на базе Mach 3.0 UNIX односерверные реализации были примерно на 50% медленнее, чем собственный UNIX.[9][10]

Изучение точной природы проблем с производительностью выявило ряд интересных фактов. Во-первых, проблема заключалась не в IPC: были некоторые накладные расходы, связанные с отображением памяти, необходимым для его поддержки, но это добавляло лишь небольшое количество времени для выполнения вызова. Остальное, 80% затраченного времени, было связано с дополнительными задачами, которые ядро ​​выполняло над сообщениями. Основными среди них были проверка прав порта и достоверность сообщений. В тестах на 486 DX-50, стандартный системный вызов UNIX занимал в среднем 21мкс до завершения, в то время как эквивалентная операция с Mach IPC составила в среднем 114 мкс. Только 18 мкс из них были связаны с оборудованием; остальное было ядром Mach, выполнявшим различные процедуры для сообщения.[11] При системном вызове, который ничего не делает, полный цикл туда и обратно в BSD потребует около 40 мкс, тогда как в системе Маха пользовательского пространства это займет чуть менее 500 мкс.

Когда Mach впервые серьезно использовался в версиях 2.x, производительность была ниже, чем у традиционных монолитных операционных систем, возможно, на 25%.[1] Однако эта стоимость не вызывала особого беспокойства, потому что система также предлагала поддержку нескольких процессоров и легкую переносимость. Многие считали, что это ожидаемая и приемлемая плата. Когда Mach 3 попытался переместить большую часть операционной системы в пространство пользователя, накладные расходы стали еще выше: тесты между Mach и Ultrix на MIPS R3000 показал снижение производительности на 67% на некоторых рабочих нагрузках.[12]

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

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

Другие проблемы с производительностью были связаны с поддержкой Mach для мультипроцессор системы. С середины 1980-х до начала 1990-х годов производительность обычных ЦП росла примерно на 60% в год, но скорость доступа к памяти росла всего на 7% в год. Это означало, что стоимость доступа к памяти за этот период значительно выросла, и, поскольку Mach был основан на отображении памяти между программами, любой «промах в кэше» замедлял вызовы IPC.

Возможные решения

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

Большинство разработчиков вместо этого придерживались оригинальной концепции POE - единственного большого сервера, обеспечивающего функциональность операционной системы.[13] Чтобы упростить разработку, они позволили серверу операционной системы работать либо в пространстве пользователя, либо в пространстве ядра. Это позволило им развиваться в пространстве пользователя и обладать всеми преимуществами исходной идеи Mach, а затем переместить отлаженный сервер в пространство ядра для повышения производительности. С тех пор с помощью этого метода было создано несколько операционных систем, известных как совместное размещение, среди них Lites, MkLinux, OSF / 1 и NeXTSTEP / OPENSTEP / macOS. В Микроядро хоруса сделал это особенностью базовой системы, позволяющей поднимать серверы в пространство ядра с помощью встроенных механизмов.

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

К середине 1990-х работа над системами микроядра в значительной степени застопорилась, хотя рынок обычно считал что все современные операционные системы будут основаны на микроядрах к 1990-м годам. Основными оставшимися широко распространенными применениями ядра Mach являются macOS от Apple и ее родственная iOS, которые работают на сильно модифицированной гибридный Ядро Open Software Foundation Mach (OSFMK 7.3) называется "XNU "[14] также используется в OSF / 1.[8] В XNU файловые системы, сетевые стеки, а также функции управления процессами и памятью реализованы в ядре; файловая система, сеть, а также некоторые функции управления процессами и памятью вызываются из пользовательского режима через обычные системные вызовы вместо передачи сообщений;[15][16] Сообщения Mach XNU используются для связи между процессами пользовательского режима и для некоторых запросов от кода пользовательского режима к ядру и от ядра к серверам пользовательского режима.

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

Дальнейший анализ показал, что проблема производительности IPC не так очевидна, как казалось. Напомним, что односторонний системный вызов занял 20 мкс в BSD.[3] и 114 мкс на Mach, работающем в той же системе.[2] Из 114, 11 были связаны с переключением контекста, идентичным BSD.[10] Еще 18 были использованы MMU для отображения сообщения между пространством пользователя и пространством ядра.[3] В сумме это всего 29 мкс, больше, чем при традиционном системном вызове, но ненамного.

Остальное, большая часть реальной проблемы, была связана с выполнением ядром таких задач, как проверка сообщения на предмет прав доступа к порту.[5] Хотя может показаться, что это важная проблема безопасности, на самом деле это имеет смысл только в UNIX-подобной системе. Например, однопользовательская операционная система под управлением сотовый телефон или же робот может не нуждаться ни в одной из этих функций, и это именно та система, в которой операционная система Mach с выбором и выбором будет наиболее ценной. Точно так же Mach вызывал проблемы, когда операционная система перемещала память - еще одна задача, которая действительно имеет смысл только в том случае, если система имеет более одного адресного пространства. ДОС и ранний Mac OS есть единое большое адресное пространство используется всеми программами, поэтому в этих системах отображение не дает никаких преимуществ.

Эти осознания привели к ряду микроядра второго поколения, что еще больше снизило сложность системы и поместило почти все функции в пространство пользователя. Например, Ядро L4 (версия 2) включает всего семь системных вызовов и использует 12 КБ памяти,[3] тогда как Mach 3 включает около 140 функций и использует около 330 КБ памяти.[3] Вызовы IPC под L4 на 486DX-50 занимают всего 5 мкс,[16] быстрее, чем системный вызов UNIX в той же системе, и более чем в 20 раз быстрее, чем Mach. Конечно, при этом игнорируется тот факт, что L4 не обрабатывает разрешения или безопасность; но, оставив это на усмотрение программ пользовательского пространства, они могут выбрать столько или меньше накладных расходов, сколько им потребуется.

Потенциальный прирост производительности L4 сдерживается тем фактом, что приложениям пользовательского пространства часто приходится предоставлять многие функции, ранее поддерживаемые ядром. Чтобы протестировать сквозную производительность, MkLinux в совмещенном режиме сравнивался с портом L4, работающим в пользовательском пространстве. L4 добавил около 5-10% накладных расходов,[10] по сравнению с 29% Маха.[10]

Программное обеспечение на базе Mach

Ниже приведен список ядер операционных систем, производных от Mach, и операционных систем с ядрами, производными от Mach:

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

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

  1. ^ а б "Mach: определение Mach на Dictionary.com". Dictionary.com. Получено 12 декабря 2016.
  2. ^ а б "Домашняя страница CMU CS Project Mach".
  3. ^ а б c d е МакКьюзик, Маршалл Кирк; Бостик, Кит; Карелс, Майкл Дж.; Квартирант, Джон С. (30 апреля 1996 г.). Разработка и реализация операционной системы BSD 4.4. Эддисон-Уэсли. п. 123. ISBN  9780768684940.
  4. ^ а б Аль Сарачевич (27 марта 2006 г.). "Адиос Авие". Хроники технологий. Получено 23 января 2010.
  5. ^ а б Сингх, Амит (28 июля 2006 г.). «Техническая история операционных систем Apple». osxbook.com. п. 103. Получено 18 марта 2011.
  6. ^ Теванян, Авадис; Рашид, Ричард Ф.; Голуб, Давид Б .; Блэк, Дэвид Л .; Купер, Эрик; Янг, Майкл В. (1987). Потоки Маха и ядро ​​Unix: битва за контроль. Летняя конференция USENIX. USENIX. С. 185–197. CiteSeerX  10.1.1.41.3458.
  7. ^ Accetta, Майк; Барон, Роберт; Болоски, Уильям; Голуб, Давид; Рашид, Ричард; Теванян, Авадис; Янг, Майкл (1986). Mach: новый фундамент ядра для разработки UNIX (PDF). Летняя конференция USENIX. USENIX.
  8. ^ а б Дуглас М. Уэллс. «Надежная, масштабируемая среда операционной системы реального времени» (PDF). S2CID  5205380. Цитировать журнал требует | журнал = (помощь)
  9. ^ М. Кондикт; Д. Болинджер; Э. Макманус; Д. Митчелл; С. Левонтин (апрель 1994 г.). «Модульность микроядра с интегрированной производительностью ядра».
  10. ^ а б c d Хертиг, Германн; Хохмут, Майкл; Лидтке, Йохен; Шенберг, Себастьян; Вольтер, Жан (октябрь 1997 г.). Производительность систем на основе μ-ядра. 16-й симпозиум ACM по принципам операционных систем (SOSP'97). 31. Сен-Мало, Франция. п. 67. Дои:10.1145/269005.266660. ISBN  0-89791-916-5.
  11. ^ Йохен Лидтке (1993). Улучшение IPC за счет дизайна ядра. Материалы 14-го симпозиума ACM по принципам операционных систем (SOSP). CiteSeerX  10.1.1.55.9939. ISBN  978-0-89791-632-5.
  12. ^ Чен, Джей Би; Бершад Б. Н. (1993). «Влияние структуры операционной системы на производительность системы памяти». Обзор операционных систем ACM SIGOPS. 27 (5): 133. CiteSeerX  10.1.1.52.4651. Дои:10.1145/173668.168629.
  13. ^ Мэри Томпсон (14 апреля 1994 г.). «Краткое описание сервера POE».
  14. ^ Джим Маги. WWDC 2000 Сессия 106 - Mac OS X: ядро. 14 минут в.
  15. ^ «Обзор архитектуры ядра». Руководство по программированию ядра. Apple Inc. 8 августа 2013 г.. Получено 3 марта, 2015.
  16. ^ а б «Пограничные переходы». Руководство по программированию ядра. Apple Inc. 8 августа 2013 г.. Получено 3 марта, 2015.
  17. ^ Apple Inc. (26 февраля 2013 г.), Обзор Маха

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