Операционная Система «Сивелькирия»: технологии

Привет, Хабр.

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

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

Исполнители модулей

Для обеспечения загрузки, запуска и исполнения модулей в «Сивелькирии» вводится концепция исполнителей. Исполнители сами являются модулями и по отношению к исполняемым ими модулям берут на себя следующие обязанности:

1. Загрузку используемых модулей в оперативную память, инициализацию, финализацию и выгрузку;
2. Связывание API, предоставляемого операционной системой, с исполняемым кодом модулей: обеспечение прохождения вызовов и данных из API операционной системы в код модулей и обратно;
3. Загрузку и подготовку необходимого модулю окружения времени выполнения;
4. Перевод кода модуля из любого промежуточного представления (исходный код на интерпретируемом языке; байт-код; промежуточный язык; сборка, предназначенная для другой платформы) в последовательность машинных команд. Конкретные действия на этом шаге (интерпретация скрипта, интерпретация байт-кода, JIT-компиляция, эмуляция и т. д.) определяются способом доставки модуля;
5. Сокрытие способа работы модуля от операционной системы и других модулей.

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

Данная концепция позволяет использовать различные способы сборки модулей в общей системе. Например, машинный код, полученный компиляцией кода на C++, будет загружаться исполнителем, поддерживающим непосредственное исполнение, в отдельное адресное пространство, и компоноваться с необходимым окружением времени выполнения. Управляемый код на IL может загружаться исполнителем, поддерживающим исполнение управляемого кода, причём изоляция может быть выполнена как на уровне операционной системы (загрузкой различных модулей в различные адресные пространства), так и на уровне исполнителя (загрузкой различных модулей в общее адресное пространство, но в разные домены окружения).

Исключением является случай запуска машинного кода под «Сивелькирией», выполняемой в рамках основной операционной системы в качестве набора библиотек и/или процессов. Прямой запуск машинного кода в этих условиях разрешён только в случае, если гарантируется отсутствие обращений из машинного кода к основной операционной системе в обход «Сивелькирии», либо если такие обращения необходимы с точки зрения системы. Например, это условие может быть выполнено в контролируемой корпоративной среде, а также для проектов с открытым исходным кодом. С другой стороны, модули, осуществляющие доступ к ресурсам основной операционной системы, по определению нуждаются в способе вызова её функций. В случае, если «чистота» машинного кода не может гарантироваться, такой код может запускаться в режиме эмуляции (как и код, собранный для иной платформы).

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

Упомянутое выше окружение времени выполнения, специфичное для конкретного языка и компилятора, является первым из двух исключений из правила, предписывающего вести обмен данными между всеми модулями только через объектные интерфейсы системы, поскольку загрузка его в адресное пространство модуля необходима для его работы. Концепция динамически связываемых библиотек, используемых несколькими модулями, в «Сивелькирии» в общем случае не поддерживается, поскольку она направлена на реализацию совместного использования кода, что и так уже реализуется через интерфейсы модулей.

Второе исключение — это разрешение использовать динамически связываемые библиотеки нескольким модулям, поставляемым совместно в рамках одного пакета. При этом возможности подключить ту же библиотеку к другим модулям, как и подсистемы поиска динамических библиотек, «Сивелькирия» не предоставляет.

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

Другие архитектурные решения

Ниже приводится краткий неструктурированный список вторичных принципов построения архитектуры ОС «Сивелькирия». Они не настолько важны, как изложенные ранее основные принципы, но, тем не менее, заслуживают упоминания.

1. Существует специальный сетевой протокол для связи между любыми устройствами, на которых выполняется операционная система «Сивелькирия». Все данные, доступные через интерфейсы, определённые в операционной системе, могут быть сериализованы и переданы по этому протоколу. В этом случае на втором конце линии операционной системой создаётся объект-прокси, все манипуляции с которым передаются на породившую оригинальный объект машину и там обрабатываются. Данная операция абсолютно прозрачна для потребителя объекта и не требует создания отдельных протоколов под каждую задачу. Таким образом возможно, например, при помощи программы просмотра изображений, запущенной на одном компьютере, просматривать файлы, находящиеся на другом, загружаемые на другое устройство по сети или создаваемые динамически выполняемыми на нём программами. Кроме того, данные могут пробрасываться сквозь устройства; так, данные с умных часов, соединённых со смартфоном по каналу Bluetooth, могут далее по WiFi передаваться на компьютер, не имеющий интерфейса Bluetooth, с полным сохранением контекста без необходимости дополнительного программирования. Поскольку все интерфейсы данных имеют чётко прописанное назначение, при передаче данных ОС может применять соответствующие обработки (например, при передаче данных видеозвонка пропущенные пакеты теряются, чтобы избежать нарастания задержки, но при передаче текста подобное выпадение пакетов недопустимо).
2. Интерфейсы данных могут использовать друг друга, способствуя повторному использованию кода. Например, интерфейс «Данные об изображении» будет включать элемент типа «Размеры изображения».
3. Интерфейсы данных могут наследоваться друг от друга, отражая переход от общего случая к частному. Например, интерфейсы «Растровое изображение» и «Векторное изображение» наследуются от интерфейса «Изображение». В контекстах, где тип изображения не важен, может быть использован более общий интерфейс.
4. Интерфейсы даных могут реализовывать другие интерфейсы просто по определению. Например, интерфейс «Содержимое директории» сам по себе содержит данные в специальном представлении (количество элементов, имя и тип каждого элемента, размер, описание и так далее), однако эти данные могут быть извлечены из него в табличном формате через интерфейс «Таблица с данными» для вставки в табличный процессор. Каждому модулю, реализующему интерфейс «Содержимое директории», не нужно заботиться о конвертации данных к интерфейсу «Таблица с данными», так как она осуществляется операционной системой (или вызываемым ею специализированным модулем) на уровне поддержки данных интерфейсов. Это позволяет использовать объекты данных в любых применимых контекстах.
5. При обмене данными интерфейсы сохраняют необходимую сопутствующую информацию, такую, как описание и происхождение измеряемых параметров и физические размерности, валюты и так далее. Например, размер изображения, заданный в пикселах, не смешивается с размером экрана, заданным в миллиметрах. Приложение-переводчик гарантированно получит данные о языке, на котором выведено переданное в него слово, что позволит избежать неоднозначности.
6. Модульная архитектура и резервирование функций управления ресурсами системы (потоки и т. п.) за операционной системой позволяют простой заменой соответствующих модулей существенно менять поведение системы. Так, для решения узкоспециализированных задач система может быть укомплектована модулями планировки заданий, реализующими стратегию операционной системы реального времени, тогда как для большинства приложений будет использоваться событие-ориентированный подход. Данные изменения не приведут к необходимости переписывания всех прикладных модулей.
7. На каждой аппаратной (или программной) платформе, на которой может быть запущена ОС «Сивелькирия», доступны модули виртуальных машин, позволяющие запускать модули, скомпилированные для других поддерживаемых платформ. Таким образом, модуль, доступный под одной платформой, может быть запущен на любой другой платформе, хоть и с потерей производительности.
8. Все данные, доступные через интерфейс, доступны через его основные элементы. Использование дополнительной информации (коллекции именованных свойств, расширения и т. п.) не допускается. Способа определить тип объекта и его происхождение по его интерфейсу не существует. Таким образом, создание проприетарных платформ обмена данными внутри операционной системы невозможно, и все данные будут доступны любому контексту.
9. Файловая система ориентирована на хранение объектов. В этом смысле байтовый массив, соответствующий файлу, является лишь одним из частных случаев такого объекта. Объекты в файловой системе могут хранить произвольную информацию — например, для поддержки кэша таких часто используемых данных, как миниатюра изображения или ссылка на кодек, используемый для его чтения. Ссылки между объектами являются одной из форм представления данных и замещают собой абсолютные и относительные пути. Таким образом достигается совместимость не только во время выполнения, но и на уровне хранимой информации: например, любой обработчик событий может использовать (и хранить в конфигурации) триггер любого типа, установленного в системе, просто сохранив ссылку на соответствующий объект.
10. Произвольное сканирование файловой системы модулями запрещено, кроме особых случаев: для реакции на действия пользователя или для совместимости с другими системами. Доступ возможен только к тем объектам, на которые у модуля существуют ссылки.
11. В большинстве случаев разницы между интерфейсом объекта, загруженного в память, и объекта, сохранённого на диск, нет — они рассматриваются как один. Абстрактный доступ к «собственно файлу» как набору байт осуществляется только модулем, который отвечает за отображение файла на некоторый объект (интерфейс данных). Вместо абстрактной работы с файлами программы работают с объектами, которые затем могут обрабатываться другими программами безотносительно формата хранения. Это не ограничивает возможностей доступа к содержимому файла в текстовом или бинарном представлении по мере необходимости.
12. Данные на диске поддерживают дополнительные по сравнению с традиционными файловыми системами операции: перемещение частей содержимого, транзакции, версионность и так далее. Версии файла, созданные одной программой, видны всем другим программам в удобном представлении. Если во время записи файла произошёл сбой, доступны и его состояние до перезаписи, и недописанная новая версия, причём отдельных усилий со стороны программиста это не требует.
13. Для пользователя поиск объектов на диске осуществляется не по расположению в иерархической структуре, а по признакам: типу, имени, категории, тегам, метаинформации, связям с людьми и объектами реального мира, связям с другими объектами, хронологии, способу доступа, происхождению и так далее. Организация хранения оказывается вторичной по отношению к классификации данных пользователем: например, пользователь может указать, что программы хранятся на быстром SSD, фотографии — на RAID-массиве с защитой от потери данных, личные записи — в облаке, а рабочие файлы автоматически дублируются между всеми устройствами. Пользователь может использовать предустановленную систему классификации объектов или настроить её на собственный вкус.
14. Настройка вида и способа представления графических программ осуществляется централизованно. Глобальные настройки вида затрагивают все пользовательские интерфейсы (но могут быть уточнены для конкретных контекстов). Например, пользователь может выбирать, насколько подробная техническая информация предоставляется ему по умолчанию (данные, интересующие опытного администратора, будут лишь мешать творческому работнику), используется ли классический стиль меню или значки (удобство для конкретного пользователя определяется типом восприятия и состоянием здоровья), соблюдается ли общая цветовая палитра для всех приложений, представляются ли данные в графическом или текстовом виде, используется ли при редактировании форматированного текста WYSIWYG-подход или разметка на специальном языке, и так далее. Каждый модуль не обязан поддерживать все возможные варианты, но информация о поддержке конкретных режимов доступна в репозитории.
15. С точки зрения операционной системы всё является объектами: и окно с его текущим состоянием, и документ, хранимый на диске. Как документ, так и окно могут быть сериализованы, сохранены, переданы на другое устройство и восстановлены операционной системой в любой момент без предупреждения (хотя смысл сериализации и десериализации может различаться для разных типов объекта). Например, в домашней сети пользователь может просмотреть окно, открытое на настольном компьютере, с мобильного телефона. Чтобы способствовать этому, модули, реализующие пользовательский интерфейс, могут адаптироваться к изменениям в типе устройства (разрешению и физическому размеру экрана, способу ввода и т. п.).
16. Существуют интерфейсы, соответствующие не конкретным объектам прикладной области, а парадигмам работы с ними. Например, интерфейс «Длительная операция» должен быть реализован любой операцией, занимающей значимое (например, от 1 секунды) время. Реализация этого интерфейса означает, что, независимо от природы операции, она может контролироваться из любого контекста: операции можно ставить в очередь, назначать обработчики (например, отключение устройства) их завершению, прерывать, просматривать статус, уровень прогресса и оставшееся время, выводить информацию о статусе важных операций в легко доступном месте, и так далее.
17. Данные, имеющие схожую природу, группируются операционной системой (причём, возможно, в рамках более чем одного устройства). Например, все программы используют общую систему логирования — в этом случае сведение логов в одну таблицу, например, при отслеживании сетевого сбоя, становится тривиальной задачей. Другой пример — это список запросов от программ на обслуживание (обновление, разрешение конфликтов и т. п.): сообщения, которые не являются экстренными, будут дожидаться момента, когда пользователю будет удобно их обработать, в соответствующем месте. Программы обмена сообщениями группируют переписку с каждым человеком в одном месте независимо от канала, по которому те были получены. Уведомления о событиях и публикациях, на которые пользователь был подписан, собираются в общем месте (аналоге «стены» в социальной сети). Рекомендации группируются здесь же, но с меньшим приоритетом. Способы управления подписками (например, немедленное уведомление о материалах конкретного автора) настраиваются в общем виде, независимо от поддержки таких настроек конкретным поставщиком содержимого (социальной сетью, видеохостингом и т. п.). Программы, отправляющие данные в общие места, не имеют доступа к данным друг друга. Таким образом, при использовании некоторой функции (обмен сообщениями, видеозвонок, просмотр уведомлений и т. п.) пользователю не нужно задумываться о том, какая конкретная программа реализует её.

Первая публикация цикла доступна здесь. Вторая — здесь. Четвёртая — здесь. Полный текст статьи доступен на сайте проекта.