Введение
Unix-вариант с возможностями операционной системы реального времени.
MERT включала в себя переработанное модульное ядро, способное запускать Unix-программы и привилегированные процессы вычислений в реальном времени. Структуры данных этих процессов были изолированы от других процессов, а передача сообщений являлась предпочтительным способом межпроцессного взаимодействия (IPC), хотя также поддерживалась общая память. MERT также имела собственную файловую систему со специальной поддержкой больших, непрерывных файлов фиксированного размера, используемых в приложениях баз данных реального времени. При разработке MERT учитывался опыт, полученный при создании систем THE от Дейкстры, Monitor от Хансена и CP 67 от IBM. Операционная система MERT имела четырехслойную архитектуру, с уменьшением уровня защиты сверху вниз:
Ядро: распределение ресурсов памяти, времени процессора и обработка прерываний.
Процессы режима ядра, включая драйверы устройств ввода/вывода (I/O), менеджер файлов, менеджер подкачки, корневой процесс, соединяющий менеджер файлов с диском (обычно объединенный с менеджером подкачки).
Операционный надзорщик.
Пользовательские процессы.
Kernel: resource allocation of memory, CPU time and interrupts
Kernel mode processes including input/output (I/O) device drivers, file manager, swap manager, root process that connects the file manager to the disk (usually combined with the swap manager)
Operating system supervisor
User processes
Стандартным надзорщиком был MERT/UNIX – эмулятор Unix с расширенным интерфейсом системных вызовов и оболочкой, обеспечивающим использование пользовательских механизмов IPC MERT, хотя также существовал эмулятор RSX 11.
Ядровые и неядерные процессы
Одной из интересных особенностей, представленных в DMERT – UNIX RTR, было понятие процессов ядра. Это связано с истоками его архитектуры, близкой к микроядру. В поддержку этого существует отдельная команда (/bin/kpkill) вместо (/bin/kill), которая используется для отправки сигналов процессам ядра. Вероятно, существуют также два различных системных вызова (kill(2) и kpkill(2), первый для завершения пользовательского процесса, а второй – процесса ядра). Неизвестно, в какой степени в /bin/kpkill реализован обычный механизм сигнализации пользовательского пространства; предполагая наличие системного вызова для этой команды, неясно, можно ли отправлять различные сигналы или только один. Также неизвестно, есть ли у процесса ядра возможность перехватывать сигналы, которые ему отправляются. Возможно, разработчики UNIX RTR реализовали целый интерфейс прикладного программирования (API) для сигналов и обмена сообщениями, предназначенный для процессов ядра.