Прошло почти 9 месяцев с момента, как я сделал паузу в работе над моим хобби-проектом: игрушечной ОС. Примерно тогда же я опубликовал серию статей на Хабре, описывающих различные аспекты её устройства (1, 2, 3, 4 и 5). Далее я решил немного отвлечься и переключился на проект медицинского коллективного блога. Сейчас он стал забирать у меня меньше времени, и я вновь почувствовал интерес к изысканиям в области системного программирования. Начав новую итерацию кодирования, я остановился, решив вновь задуматься об архитектуре.
Моё предыдущее видение сводилось к следующим тезисам:
- Единое адресное пространство. Это позволит прикладному коду взаимодействовать с системой без необходимости в сериализации входных и выходных данных, сократит время переключения контекста, а также избавит от необходимости очищать TLB-кэш.
- Виртуальная машина для прикладного кода. Она не позволит приложениям пересекать границы отведённой им памяти (чтобы одно приложение не могло уронить систему или другое приложение). Кроме того, виртуальная машина полезна в распределённой среде, включающей в себя машины разных архитектур.
- Постоянная память проецируется на 64-битное адресное пространство. Используемые в настоящий момент страницы загружаются в оперативную память, а страницы, к которым давно не обращались, — выгружаются в постоянную память. То есть оперативная память кэширует постоянную, причём прозрачно для клиентского кода.
- Персистентные приложения. Т.е. они смогут пережить как перезагрузку машины, так и перемещение на другую машину. Это обеспечивается предыдущим пунктом, а также отсутствием дескрипторов (как, например, дескрипторов открытых файлов). Все обращения к ресурсу будут предполагать использование уникального идентификатора (как, например, полное имя файла), без необходимости предварительного получения дескриптора. С одной стороны такой подход тянет за собой дополнительные накладные расходы (даже с учётом кэширования), с другой — отвязывает клиента от времени и места (код, разбуженный после перезагрузки машины, или перенесённый на другую машину, сможет продолжить работу).
Домены, потоки и модули
На единое адресное пространство монтируются (проецируются) накопители. Под каждый накопитель выделяется диапазон адресов в зависимости от его размера. Эту область адресного пространства будем называть доменом.
После монтирования в домене запускаются потоки, уснувшие во время последнего размонтирования. Поскольку домен может быть монтирован на произвольный адрес, его код должен быть перемещаемым (PIC). Кроме выполняющихся потоков домен содержит код, разбитый на модули. Каждый модуль имеет UUID и поддерживает некоторый интерфейс. Кроме кода модули ещё в себе инкапсулируют и данные. Такой схема делает файлы ненужными. В самом деле, зачем нужны файлы, когда модули персистентны и просто хранят всю информацию в памяти?
Одни модули могут использовать функционал других модулей (вызывать их функции). Такие вызовы бывают трёх видов:
- Внутридоменные, когда оба модуля находятся в одном и том же домене. Это самые эффективные вызовы, поскольку модули находятся в одном адресном пространстве (т.е. нет необходимости в сериализации при обмене данными) и, будучи в одном домене, не меняют адресного смещения относительно друг друга, а также одновременно монтируются и размонтируются.
- Междоменные, когда оба модуля находятся в разных доменах. Они не такие эффективные, как внутридоменные, поскольку ситуация, при которой один из доменов размонтируется в процессе вызова, должна корректно обрабатываться (не будем вдаваться в логику такой обработки). Поскольку оба модуля находятся в едином адресном пространстве, по-прежнему нет необходимости в сериализации при обмене данными.
- Удалённые, когда оба модуля находятся на разных машинах. Очевидно, это самый тяжеловесный вид вызова, предполагающий как сериализацию данных, так и издержки сетевой маршрутизации (по UUID модуля нужно найти IP-адрес машины) и пересылки.
Итак, я грубыми штрихами набросал моё текущее видение законченной системы. Буду очень признателен, если вы укажете мне на ошибки и потенциальные недостатки обрисованной конструкции (не хочу двигаться в тупиковом направлении).
Автор: ababo
