Память.

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

void *a, int i;

a = i;

в фантоме "не бывает". Соответствующей операции просто нет в наборе команд виртуальной машины. Идея взята из i432, этим обеспечивается несоизмеримый с традиционными ОС уровень защищённости системы, это раз, и два - гарантируется отсутствие потерь на security, так как понятие "проверка прав доступа" отсутствует. Правом доступа является владение адресом объекта. Если я знаю адрес - я могу доступиться. Не знаю - не могу.

(Здесь уместна ссылка на литературу, но мне сейчас некогда.)

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

Все объекты, кроме базовых типов содержат только указатели. То есть

class test {

int i, j;

}

на самом деле содержит два указателя - на объекты класса int.

отличие

class test1 { int i; }

от

class test2 {int *p; }

лишь языковое - в первом случае элемент класса константен, а присвоение переменной i трактуется как вызов оператора = класса int для объекта, на который указывает элемент класса, во втором случае присвоение идёт указателю.

Указатель - встроенная сущность, не имеет собственного класса.

Вся без исключения "наземная" память - динамическая, со сбором мусора. (Вся подземная, насколько я вижу сейчас - статическая, но тут я могу ошибаться.)

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

(Комментарий: Такая организация памяти означает, что часть дискового пространства используется непроизводительно. Интуитивно представляется, что эта часть не превышает размера своп-файла в других ОС.)

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

Сей факт означает необходимость оповещения части объектов о том, что произошёл "разрыв времени". Проблема в том, что оповещение, вообще говоря, должно быть сделано до рестарта системы. Более того - оно должно быть сделано для всех нуждающихся в нём объектов одновременно. Причём получивший в рамках оповещения управление объект не должен передавать его (управление) другому объекту, так как это грозит приходом управления в нуждающийся в оповещении другой объект до того, как он получил оповещение.

На сегодня я вижу такой путь. Каждый нуждающийся в оповещении класс должен иметь специальный метод (положим, crash), который будет вызван системой для каждого объекта класса при восстановлении, но до запуска всех нитей. Во время работы метода crash ВСЕ VMT (таблицы методов - а в фантоме все методы виртуальны, значит все вызовы косвенны) временно обнуляются. Точнее, код выборки адреса из VMT модифицируется так, чтобы попытка любого вызова метода приводила к завершению нити. Это позволит любому классу привести перед рестартом в порядок себя и не тронуть других.

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

В принципе, оба варианта могут сосуществовать без проблем.

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

Подключение и отключение дисков - это ясно, как. Подключение - примерно как swapon в unix - некоторое устройство вводится в пул доступных для размещения страниц системы виртуальной памяти. Отключение - сложнее. Выполняется в два этапа. На первом система запрещает размещение новых страниц на данном устройстве и постепенно переносит с него не меняющиеся страницы (implementation hint: достаточно просто метить их как изменившиеся - в первом же цикле создания среза они уйдут на другое устройство, а во втором - освободятся на старом). Как только на устройстве не останется занятых страниц (второй этап) - оно свободно и может быть выведено из обращения. Очевидно, что это возможно только если на остальных дисках достаточно места под всё, что есть в системе.

В целом все несъёмные диски равноправны, хотя пейджер может располагать хинтами на тему того, где лучше располагать какую страницу. Например, часто меняющиеся - на быстром диске, редко - на медленном. В plan9 предлагалось даже выносить страницы на WORM, но это было во времена, когда гигабайт дисковой памяти стоил дорого... нынче, думаю, уже не актуально.

Инсталляция ОС

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

Сменная память.

Пока что я не вижу идеального решения. Понятно, что встраивать её в адресное пространство системы бессмысленно. Разве что только если речь идёт о CDROM - тогда, в принципе, на нём можно "поселить" какую-то группу объектов, и при установке диска "пристёгивать" его в окно в адресном пространстве системы. Проблемы очевидны.

Интересный вариант - считать каждый сменный носитель самостоятельной инкарнацией ОС фантом. Тогда установка его в дисковод будет равноценна запуску ещё одной, самостоятельной виртуальной машины фантом. При этом вся константная информация (исполняемый код ОС и библиотек классов, например) берётся из "копилки" основной ОС. Доступ к "гостевой ОС" сменного носителя может осуществляться тем же способом, что и доступ по сети к другим машинам под управлением фантома.

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

Реализация

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