✖


Jump to content

Мах (ядро)

Мах
Разработчик(и) Ричард Рашид
Авие Теванян
Первоначальный выпуск 1985 год ; 39 лет назад ( 1985 )
Стабильная версия
3.0 / 1994 ; 30 лет назад ( 1994 )
Платформа IA-32 , x86-64 , MIPS , ARM32 , Aarch64 , m88k
Тип Микроядро
Веб-сайт Проект Маха

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

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

Mach является логическим преемником ядра Accent Карнеги-Меллона . Ведущий разработчик проекта Mach Ричард Рашид работает в Microsoft с 1991 года; он основал исследовательское подразделение Microsoft . Другой из первоначальных разработчиков Mach, Ави Теванян, ранее был главой отдела программного обеспечения в NeXT , а затем директором по технологиям программного обеспечения в Apple Inc. до марта 2006 года [4] [2]

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

Имя [ править ]

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

Unix-каналы [ править ]

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

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

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

Новые концепции [ править ]

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

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

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

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

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

Мах [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

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

В отличие от UNIX, которая была разработана без учета многопроцессорности, Mach полностью поддерживает многопроцессорность. Его поддержка многопроцессорности также чрезвычайно гибка: от систем с общей памятью до систем без памяти, разделяемой между процессорами. Mach предназначен для работы на компьютерных системах с числом процессоров от одного до тысяч. Кроме того, Mach легко портируется на множество различных компьютерных архитектур. Ключевая цель Mach — стать распределенной системой, способной функционировать на гетерогенном оборудовании. [9]

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

Развитие [ править ]

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

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

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

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

Mach стал значительно популярнее, когда Фонд открытого программного обеспечения (OSF) объявил, что будет размещать будущие версии OSF/1 на скорости 2,5 Маха, а также исследовал возможность использования Mach 3. Скорость 2,5 Маха также была выбрана для системы NeXTSTEP и ряда коммерческих производителей мультипроцессоров. Mach 3 привел к ряду попыток портировать другие части операционных систем для микроядра, включая IBM Workplace OS , а также несколько усилий Apple по созданию кросс-платформенной версии классической Mac OS . [10] Поддержка запуска приложений DOS в среде Mach 3.0 была продемонстрирована исследователями в продолжение более ранней работы с классической Mac OS и MultiFinder под Mach 2.5. [11]

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

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

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

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

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

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

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

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

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

Возможные решения [ править ]

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

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

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

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

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

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

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

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

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

Программное обеспечение на базе Маха [ править ]

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

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

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

  1. ^ Jump up to: Перейти обратно: а б «Мах: определение Маха на Dictionary.com» . Словарь.com . Проверено 12 декабря 2016 г.
  2. ^ Jump up to: Перейти обратно: а б с «Домашняя страница проекта CMU CS Mach» .
  3. ^ Jump up to: Перейти обратно: а б с д и МакКьюсик, Маршалл Кирк ; Бостик, Кейт ; Карелс, Майкл Дж .; Квартерман, Джон С. (30 апреля 1996 г.). Проектирование и реализация операционной системы 4.4 BSD . Аддисон-Уэсли . п. 123. ИСБН  978-0-7686-8494-0 .
  4. ^ Jump up to: Перейти обратно: а б Аль Сарацевич (27 марта 2006 г.). «Адиос Авие» . Технологические хроники. Архивировано из оригинала 4 декабря 2011 года.
  5. ^ «Дарио А. Джузе, доктор философии, магистр, FACMI» . Архивировано из оригинала 23 августа 2020 года.
  6. ^ Jump up to: Перейти обратно: а б Сингх, Амит (28 июля 2006 г.). «Техническая история операционных систем Apple» . osxbook.com. Архивировано из оригинала 27 августа 2019 года . Проверено 18 марта 2011 г.
  7. ^ Теванян, Авадис ; Рашид, Ричард Ф .; Голуб, Дэвид Б.; Блэк, Дэвид Л.; Купер, Эрик; Янг, Майкл В. (1987). Потоки Маха и ядро ​​Unix: битва за контроль . Летняя конференция USENIX. УСЕНИКС . стр. 185–197. CiteSeerX   10.1.1.41.3458 .
  8. ^ Акчетта, Майк; Барон, Роберт; Болоски, Уильям; Голуб, Дэвид; Рашид, Ричард ; Теванян, Авадис ; Янг, Майкл (1986). Мах: Новый фонд ядра для разработки UNIX (PDF) . Летняя конференция USENIX. ЮСЕНИКС.
  9. ^ ( Приложение B , Основные понятия операционной системы )
  10. ^ Jump up to: Перейти обратно: а б Дуглас М. Уэллс (1994). Надежная масштабируемая среда операционной системы реального времени (PDF) . 1994 г. Конференция IEEE по технологиям и приложениям двойного назначения. S2CID   5205380 . Архивировано из оригинала (PDF) 22 августа 2017 г.
  11. ^ Малан, Джеральд; Рашид, Ричард; Голуб, Дэвид; Барон, Роберт (ноябрь 1991 г.). «DOS как приложение Mach 3.0» . Материалы симпозиума Usenix Mach . Ассоциация Усеникс: 27–40 . Проверено 19 января 2024 г.
  12. ^ М. Кондикт; Д. Болинджер; Э. Макманус; Д. Митчелл; С. Левонтин (апрель 1994 г.). «Модульность микроядра с интегрированной производительностью ядра» . Архивировано из оригинала 19 июня 2017 г. Проверено 19 февраля 2019 г.
  13. ^ Jump up to: Перейти обратно: а б с д Хартиг, Герман; Хохмут, Майкл; Лидтке, Йохен ; Шенберг, Себастьян; Уолтер, Джин (октябрь 1997 г.). Производительность систем на базе μ-ядра . 16-й симпозиум ACM по принципам операционных систем (SOSP'97). Том 31. Сен-Мало, Франция. п. 67. дои : 10.1145/269005.266660 . ISBN  0-89791-916-5 .
  14. ^ Йохен Лидтке (1993). «Улучшение IPC с помощью Kernel Design». Материалы 14-го симпозиума ACM по принципам операционных систем (SOSP) . CiteSeerX   10.1.1.55.9939 . дои : 10.1145/168619.168633 . ISBN  978-0-89791-632-5 .
  15. ^ Чен, Дж. Б.; Бершадь, Б. Н. (1993). «Влияние структуры операционной системы на производительность системы памяти». Обзор операционных систем ACM SIGOPS . 27 (5): 133. CiteSeerX   10.1.1.52.4651 . дои : 10.1145/173668.168629 .
  16. ^ Мэри Томпсон (14 апреля 1994 г.). «Краткое описание POE-сервера» .
  17. ^ Джим Мэги. WWDC 2000, сеанс 106 — Mac OS X: ядро . Через 14 минут. Архивировано из оригинала 11 декабря 2021 г.
  18. ^ «Обзор архитектуры ядра» . Руководство по программированию ядра . Apple Inc. , 8 августа 2013 г. Проверено 3 марта 2015 г.
  19. ^ Jump up to: Перейти обратно: а б «Переход границы» . Руководство по программированию ядра . Apple Inc., 8 августа 2013 г. Проверено 3 марта 2015 г.
  20. ^ Apple Inc. (26 февраля 2013 г.), Обзор Mach

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

Retrieved from "https://en.wikipedia.org/w/index.php?title=Mach_(kernel)&oldid=1229164081"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: c81d7f83d127b1a4dcdfd9c824e80b45__1718424000
URL1:https://arc.ask3.ru/arc/aa/c8/45/c81d7f83d127b1a4dcdfd9c824e80b45.html
Заголовок, (Title) документа по адресу, URL1:
Mach (kernel) - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)