Я решил сделать небольшой перерыв в своем ежедневном увлечении программированием и поделиться с вами описанием того, чем я на самом деле занимаюсь.
Итак, я пытаюсь разработать и реализовать виртуальную машину для несуществующей операционной системы, которую, возможно, тоже когда-нибудь начну реализовывать.
Не буду с пеной у рта спорить, доказывая, зачем нужна еще одна ОС, отвечу кратко: в основном потому, что она мне интересна.
Итак, мое нынешнее видение архитектуры системы.
1. Существует две основные сущности: модуль и поток.
2. Модуль содержит неизменяемый код и изменяемые данные.
3. Модуль постоянный.
Последний пункт означает, что модуль существует всегда.
На практике это должно реализовываться через виртуальную память.
Те.
Страницы модуля, используемые в данный момент, загружаются в ОЗУ, а неиспользуемые страницы загружаются на диск.
Поддержка постоянства должна быть на уровне системы, т. е.
полностью прозрачна для программиста приложения.
Это можно считать свопом, доведённым до логического завершения, когда нам больше не нужно загружать модуль в оперативную память, так как он будет находиться в «вечном» свопе и будет автоматически загружаться по требованию.
Другими словами, файловая система больше не понадобится.
4. В модуле имеется множество внешних процедур, которые можно вызывать извне.
Данные модуля доступны только косвенно, через его внешние процедуры.
5. Модуль имеет UUID экземпляра (ID) и UUID типа (TID).
6. При копировании модуля для копии генерируется новый идентификатор, но старый TID сохраняется.
7. Модуль можно найти по идентификатору в глобальной сети или по TID на локальном хосте.
Каждый TID на локальном хосте соответствует только одному модулю, даже если существует несколько модулей с одинаковым TID. 8. Поток может вызвать внешнюю процедуру по идентификатору модуля и числовому идентификатору.
9. Поток может вызвать внешнюю процедуру по TID своего модуля, расположенного на том же хосте, и его числовому идентификатору.
Грубо говоря, TID необходим для использования модулей как динамически загружаемых библиотек.
На самом деле на хостах будет много идентичного кода (системное ПО, кодеки и т.п.
), доступ к которому должен быть очень эффективным, и использовать который удаленно не имеет смысла.
Теперь модель многопоточной синхронизации.
1. Вызов внешней процедуры синхронный.
2. Внешняя процедура может быть функцией (f-процедура), считывателем (r-процедура) или писателем (w-процедура).
F-процедура не использует модифицируемые данные модуля, r-процедура считывает модифицируемые данные, а w-процедура их модифицирует. 3. Вызов f-процедур модуля вызывается без блокировки.
4. Вызов r-процедуры не блокируется, если в этом модуле уже вызваны другие r-процедуры.
5. Вызов r-процедуры и w-процедуры блокируется, если в этом модуле уже была вызвана w-процедура.
6. Если r-процедуры и w-процедуры заблокированы, то при разблокировке сначала выполняется w-процедура.
Те.
может быть много читателей без писателя или только один писатель.
Писатель имеет более высокий приоритет перед читателями.
В приведенных выше тезисах многого не хватает. В частности, полностью отсутствует архитектура безопасности.
Увы, я пока не могу это сформулировать.
В последующих постах я опишу общую архитектуру виртуальной машины, а также детали ее реализации вплоть до текущего состояния проекта.
Кстати, текущая реализация способна выполнять программы факториала и быстрой сортировки.
Для преждевременно любопытных предоставляю ссылку на репозиторий: github.com/ababo/AntOS-VM-Prototype Теги: #Виртуализация #архитектура #ОС #виртуальная машина
-
Социальная Инженерия И Социальные Сети
19 Oct, 24 -
Кто Построил Египетские Пирамиды?
19 Oct, 24 -
Новые Цвета Для Онлайн-Карт 2Гис
19 Oct, 24 -
Руководство По Источникам Llvm
19 Oct, 24 -
Как Lte Борется С Межсотовыми Помехами
19 Oct, 24
