как сделать свою ос на ядре windows
Как сделать свою ос на ядре windows
Приветствую всех своих читателей!
В начальный загрузчик осталось внести всего пару дополнений и он будет полностью готов грузить любые 32-битные ядра.
Определение объёма оперативной памяти
1) Его следует использовать до включения страничной адресации, чтобы иметь доступ ко всей физической памяти, либо устраивать запись через «окно» временной страницы. Лишняя трата времени, при условии, что тестирование памяти BIOS и так выполняет при начальной инициализации, а мы делаем двойную работу.
2) Всё хорошо пока память представляет собой непрерывный участок адресов, но на современных системах с большим объёмом памяти это правило может быть нарушено. К тому же BIOS пишет в самую обычную память таблицы ACPI, которые пригодятся операционной системе и не стоит их затирать до прочтения.
Из этого следует, что лучше спросить про объём оперативной памяти у BIOS, благо он предоставляет все необходимые функции.
Что такое «сконфигурированная» память производители BIOS судя по всему не договорились, поэтому надо просто, если в AX и BX нули, брать значение из CX и DX.
Каждый элемент карты памяти имеет следующую структуру (напишу в синтаксисе Си, потому что разбор данных мы будем делать уже в ядре):
Последний элемент структуры не обязателен. Ещё в одном источнике видел, что перед запросом элемента стоит поместить туда единичку. Конечно, сейчас мы не поддерживаем ACPI, но лучше заранее позаботится о том, чтобы получить как можно больше данных. В отличии от параметров памяти, всё остальное можно легко узнать и из защищённого режима напрямую, без BIOS.
Регионы памяти, описываемые картой, могут быть нескольких типов:
Ну вот и готов наш начальный загрузчик для 32-битных ядер. В заключение привожу его полный код и мы перейдём к ядру.
Первое ядро
Сборка ядра
Собрать всё ядро можно следующими командами:
Сборка образа диска
Обойдусь без лишних комментариев и просто приведу линуксовый скрипт сборки образа:
Он предполагает, что все скомпилированные файлы лежат в bin в текущем каталоге, а ещё имеется каталог disk, в котором лежит boot.cfg следующего содержания:
Если вы всё сделали правильно, полученный образ можно запустить в эмуляторе или даже на реальном железе и вы получите подобную картину:
Загрузчик считывает конфигурационный файл, загружает ядро, переходит в защищённый режим и передаёт ему управление. Получив его, наше ядро выводит последнюю строку на экран. Это лишь начало долгого пути, мы переходим к самой интересной части разработки. Теперь выпуски будут гораздо более простым для восприятия, благодаря использованию языка высокого уровня, который как я надеюсь все и так знают. Если вы не хотите разбираться с Assembler, можете просто взять мой готовый загрузчик и startup.asm и изменять уже только содержимое main.c, поскольку весь код до этого не диктует жёстко какие-либо параметры ядра (кроме ФС с которой мы загружаемся) и позволяет построить на своей базе что угодно.
Автоматизация сборки или Makefile
Вы могли заметить, что вручную набивать столько команд достаточно утомительно. К тому же не всегда есть необходимость перекомпилировать все файлы. Например, если startup.asm не был изменён, можно не вызывать fasm. Специально для упрощения компиляции приложений была придумана утилита make, которая входит в стандартную поставку GCC и MinGW.
Любой Makefile стоит из набора правил с такой структурой:
Этот текст необходимо сохранить в файл с именем Makefile (без расширения) в каталог с исходными текстами ядра. Теперь достаточно выполнить команду make без параметров, находясь в этом каталоге и мы получим файл kernel.bin (либо сообщения об ошибках, если что-то пошло не так).
А вот так я собираю загрузчик:
Ну и наконец расскажу про вызов других Makefile из одного. Я достаточно ленив, чтобы даже заходить в каталоги с каждым компонентом системы, поэтому создал 1 Makefile, который собирает сразу всю систему. У меня есть папка src, в ней подкаталоги: boot, kernel, make_listfs. В самой src находится вот такой Makefile:
Теперь, находясь в каталоге src я просто пишу make и получаю полностью собранную систему, а если написать make clean, то все двоичные файлы будут удалены и останутся только исходники.
Ну и в довершение последний скрипт, который выполняет полную компиляцию и сборку всех компонентов и образа диска. В одном каталоге с ним надо разместить src, пустой каталог bin и каталог disk с файлом boot.cfg.
С таким набором скриптов сборка система становится предельно простой, особенно если учесть, что последний скрипт можно запускать двойным кликом из файлового менеджера. Различные команды вроде dd, cp, rm не существуют под Windows, поэтому её пользователям пригодится пакет MSYS или Cygwin. Однако простая сборка всех компонентов будет работать даже если у вас есть только GCC и fasm (make_listfs легко скомпилируется и запустится в виде Windows-приложения).
Примечание для пользователей ОС Windows
Заодно уберите строку OUTPUT_FORMAT(«binary») из script.ld. Теперь и под Windows получится собрать ядро системы.
Загрузка системы на реальной машине
После таких успехов у некоторых может возникнуть желание опробовать новую ОС на реальном железе. Это не представляет проблем. С помощью HxD в Windows откройте дискету или флешку, выбрав вариант «Открыть диск». При открытии флешки важно открыть именно саму флешку, а не её раздел. В другой вкладке откройте disk.img, выделите его содержимое полностью и скопируйте на диск с его самого начала. После этого можно нажать «Сохранить» и дождаться окончания записи. Все данные на флешке или дискете при этом будут уничтожены, а для того, чтобы её использовать снова по назначению, её придётся заново отформатировать!
Вместо sdX надо подставить настоящее имя устройства (sda, sdb, sdc, sdd и т. д.). Главное при этом не перепутать и не записать образ на системный диск, уничтожив все данные. Разумеется, обе команды должны выполняться от имени root или с помощью sudo.
После этого надо настроить в BIOS загрузку с дискеты или флешки (старые BIOS не поддерживают флешки) и наслаждаться видом «Hello world».
Пишем свою ОС: Выпуск 1
Данный цикл статей посвящён низкоуровневому программированию, то есть архитектуре компьютера, устройству операционных систем, программированию на языке ассемблера и смежным областям. Пока что написанием занимаются два хабраюзера — iley и pehat. Для многих старшеклассников, студентов, да и профессиональных программистов эти темы оказываются весьма сложными при обучении. Существует много литературы и курсов, посвящённых низкоуровневому программированию, но по ним сложно составить полную и всеохватывающую картину. Сложно, прочитав одну-две книги по ассемблеру и операционным системам, хотя бы в общих чертах представить, как же на самом деле работает эта сложная система из железа, кремния и множества программ — компьютер.
Каждый решает проблему обучения по-своему. Кто-то читает много литературы, кто-то старается поскорее перейти к практике и разбираться по ходу дела, кто-то пытается объяснять друзьям всё, что сам изучает. А мы решили совместить эти подходы. Итак, в этом курсе статей мы будем шаг за шагом демонстрировать, как пишется простая операционная система. Статьи будут носить обзорный характер, то есть в них не будет исчерпывающих теоретических сведений, однако мы будем всегда стараться предоставить ссылки на хорошие теоретические материалы и ответить на все возникающие вопросы. Чёткого плана у нас нет, так что многие важные решения будут приниматься по ходу дела, с учётом ваших отзывов.
Возможно, мы умышленно будем заводить процесс разработки в тупик, чтобы позволить вам и себе полностью осознать все последствия неверно принятого решения, а также отточить на нем некоторые технические навыки. Так что не стоит воспринимать наши решения как единственно верные и слепо нам верить. Еще раз подчеркнём, что мы ожидаем от читателей активности в обсуждении статей, которая должна сильно влиять на общий процесс разработки и написания последующих статей. В идеале хотелось бы, чтобы со временем некоторые из читателей присоединились к разработке системы.
Мы будем предполагать, что читатель уже знаком с основами языков ассемблер и Си, а также элементарными понятиями архитектуры ЭВМ. То есть, мы не будем объяснять, что такое регистр или, скажем, оперативная память. Если вам не будет хватать знаний, вы всегда можете обратиться к дополнительной литературе. Краткий список литературы и ссылки на сайты с хорошими статьями есть в конце статьи. Также желательно уметь пользоваться Linux, так как все инструкции по компиляции будут приводиться именно для этой системы.
А теперь — ближе к делу. В оставшейся части статьи мы с вами напишем классическую программу «Hello World». Наш хеллоуворлд получится немного специфическим. Он будет запускаться не из какой-либо операционной системы, а напрямую, так сказать «на голом железе». Перед тем, как приступить непосредственно к написанию кода, давайте разберёмся, как же конкретно мы пытаемся это сделать. А для этого надо рассмотреть процесс загрузки компьютера.
Итак, берем свой любимый компьютер и нажимаем самую большую кнопочку на системном блоке. Видим веселую заставку, системный блок радостно пищит спикером и через какое-то время загружается операционная система. Как вы понимаете, операционная система хранится на жёстком диске, и вот тут возникает вопрос: а каким же волшебным образом операционная система загрузилась в ОЗУ и начала выполняться?
На картинке изображена поверхность дискового накопителя. У дискеты 2 поверхности. На каждой поверхности есть кольцеобразные дорожки (треки). Каждый трек делится на маленькие дугообразные кусочки, называемые секторами. Так вот, исторически сложилось, что сектор дискеты имеет размер 512 байт. Самый первый сектор на диске, загрузочный сектор, читается BIOS’ом в нулевой сегмент памяти по смещению 0x7С00, и дальше по этому адресу передается управление. Начальный загрузчик обычно загружает в память не саму ОС, а другую программу-загрузчик, хранящуюся на диске, но по каким-то причинам (скорее всего, эта причина — размер) не влезающую в один сектор. А поскольку пока что роль нашей ОС выполняет банальный хеллоуворлд, наша главная цель — заставить компьютер поверить в существование нашей ОС, пусть даже и на одном секторе, и запустить её.
Как устроен загрузочный сектор? На PC единственное требование к загрузочному сектору — это содержание в двух его последних байтах значений 0x55 и 0xAA — сигнатуры загрузочного сектора. Итак, уже более-менее понятно, что нам нужно делать. Давайте же писать код! Приведённый код написан для ассемблера yasm.
Эта короткая программа требует ряда важных пояснений. Строка org 0x7C00 нужна для того, чтобы ассемблер (имеется в виду программа, а не язык) правильно рассчитал адреса для меток и переменных ( puts_loop, puts_loop_exit, message ). Вот мы ему и сообщаем, что программа будет загружена в память по адресу 0x7C00.
В строках
происходит установка сегмента данных ( ds ) равным сегменту кода ( cs ), поскольку в нашей программе и данные, и код хранятся в одном сегменте.
В строке « times 0x1FE-finish+start db 0 » производится заполнение остатка кода программы (за исключением последних двух байт) нулями. Делается это для того, чтобы после компиляции в последних двух байтах программы оказалась сигнатура загрузочного сектора.
С кодом программы вроде разобрались, давайте теперь попробуем скомпилировать это счастье. Для компиляции нам понадобится, собственно говоря, ассемблер — выше упомянутый yasm. Он есть в большинстве репозиториев Linux. Программу можно откомпилировать следующим образом:
Полученный файл hello.bin нужно записать в зарузочный сектор дискеты. Делается это примерно так (разумеется, вместо fd нужно подставить имя своего дисковода).
Поскольку далеко не у всех остались дисководы и дискеты, можно воспользоваться виртуальной машиной, например, qemu или VirtualBox. Для этого придётся сделать образ дискеты с нашим загрузчиком и вставить его в «виртуальный дисковод».
Создаём образ диска и заполняем его нулями:
Записываем в самое начало образа нашу программу:
Запускаем полученный образ в qemu:
После запуска вы должны увидеть окошко qemu с радостной строчкой «Hello World!». На этом первая статья заканчивается. Будем рады увидеть ваши отзывы и пожелания.
Что нужно знать, чтобы написать операционную систему
Авторизуйтесь
Что нужно знать, чтобы написать операционную систему
Создание операционной системы — одна из сложнейших задач в программировании, поскольку требует обширных и комплексных знаний о работе компьютера. Каких именно? Разбираемся ниже.
Что такое ОС
Операционная система (ОС) — это программное обеспечение, которое работает с компьютерным железом и его ресурсами и является мостом между аппаратной и программной частью компьютера.
Компьютеры первого поколения не имели операционных систем. Программы на первых ЭВМ включали в себя код для непосредственной работы системы, связи с периферийными устройствами и вычислений, для выполнения которых эта программа и писалась. Из-за такого расклада даже простые по логике работы программы были сложны в программной реализации.
По мере того как компьютеры становились более разнообразными и сложными, писать программы, которые работали и как ОС, и как приложение, стало попросту неудобно. Поэтому, чтобы программы было легче писать, владельцы компьютеров начали разрабатывать программное обеспечение. Так и появились операционные системы.
ОС предоставляет всё необходимое для работы пользовательских программ. Их появление означало, что теперь программам не нужно контролировать весь объём работ компьютера (это отличный пример инкапсуляции). Теперь программам нужно было работать именно с операционной системой, а система уже сама заботилась о ресурсах и работе с периферией (клавиатура, принтер).
Кратко об истории операционных систем
Первая операционная система была создана в 1956 году компанией General Motors для единственного компьютера IBM. Остальные владельцы этих компьютеров последовали примеру и начали создавать собственные ОС.
Как можно догадаться, первые ОС сильно отличались друг от друга. Почти на каждом компьютере стояла своя система. Хоть они и облегчали написание программ, использовать такие программы можно было только на одном компьютере.
В 1960-х годах IBM стала первой выпускающей компьютеры компанией, которая взяла на себя процесс написания ОС под свои же компьютеры. Компания начала распространять компьютеры вместе со своей операционной системой.
В эти же годы компании Control Data Corporation, Computer Sciences Corporation, Burroughs Corporation, GE, Digital Equipment Corporation и Xerox тоже начали реализовывать свои ОС.
В конце 60-х была разработана первая версия ОС Unix. Написанная на Си, свободно доступная первые годы, Unix привлекала всё больше внимания и аудитории. Она легко портировалась на новые системы и начала набирать обороты.
Многие современные ОС, включая Apple OS X и все разновидности Linux-систем, являются дальними потомками Unix.
Microsoft Windows, в свою очередь, была написана для ряда персональных компьютеров IBM.
Первая ОС от Microsoft называлась не Windows, а MS-DOS. Эта система была создана в 1981 году, когда систему 86-DOS купили у компании Seattle Computer Products и модифицировали её под требования IBM.
Всем привычное название Windows появилось в 1985, когда MS-DOS обзавелась графическим интерфейсом.
Apple OS X, Microsoft Windows и ряд Linux-систем (включая Android) сейчас контролируют большую часть рынка операционных систем.
Составляющие операционной системы
ОС состоит из двух основных частей:
Ядро (англ. kernel)
Сердце операционной системы. Именно оно запускается первым при включении компьютера (не считая BIOS и загрузчик). Ядро контролирует ресурсы компьютера и обрабатывает запросы от системных программ.
Системные программы
Работают поверх ядра. Такие программы нужны, в целом, не для пользователя, а для связи ядра с пользовательскими приложениями и периферией. Примеры системных программ: драйвера устройств, файловая система, сетевые программы, утилиты для дефрагментации диска.
Пользовательские программы
Не являются частью операционной системы. Именно эти программы уже имеют конкретное назначение. Текстовые редакторы, браузеры, медиа-плееры — всё это пользовательские программы. Они контролируются ядром и используют системные программы для доступа к периферии.
Что необходимо знать
Список вещей, которые необходимо знать для создания собственной ОС, очень длинный. Но в нём есть три основных пункта, на которые нужно обратить внимание в первую очередь:
Изучение информатики
Разработка ОС — это не тоже самое, что, скажем, веб-разработка. Тут нельзя будет просто и быстро разобраться в базовых вещах. Для начала нужно получить крепкий базис информатики и только потом переходить к другим темам.
Coursera: Computer Science 101 — это курс, который подойдёт для тех, кто только начал осваиваться в информатике и программировании. Если у вас уже имеются элементарные знания в в этой области, то пропустите этот курс и переходите к следующему.
Udacity: Intro to Computer Science использует веб-разработку в качестве подхода к обучению компьютерной науке. Хоть курс и не направлен на непосредственную разработку ОС, он даёт мощный базис в области программирования.
edX: Introduction to Computer Science — этот курс является самым исчерпывающим и углублённым в этом списке. Несмотря на это, он полностью бесплатен. Курс был разработан в Гарвардском Университете. В нём вас научат алгоритмам, структурам данных, управлению ресурсами, разработке ПО, а так же познакомят с такими языками программирования, как C, PHP и JavaScript.
Подборка книг для самостоятельного изучения Computer Science.
Изучение программирования
С крепкими знаниями в области информатики и хотя бы базовым пониманием программирования вам нужно набраться опыта в разработке проектов.
Udacity: Software Development Process — отличный курс для тех, кто ещё не принимал участие в крупных проектах. Тут вас ознакомят с подробностями рабочего процесса и работой с инструментарием (например Git), а также расскажут о настройке интегрированной среды разработки.
Изучение языков программирования
Для разработки операционной системы вам понадобится освоить минимум два языка программирования:
Первый используется для работы напрямую с процессором. Процессор «понимает» только машинный код, и для каждого типа процессора есть только один соответствующий язык. Одной из самых популярных архитектур процессора является x86. Она была разработана компанией Intel и на текущий момент широко используется многими производителями компьютерного железа, включая AMD. По этой причине в этой статье акцент будет именно на архитектуру x86.
Высокоуровневые языки программирования, в свою очередь, работают сразу на нескольких архитектурах. Самый популярный из таких языков — Cи. Чаще всего именно на нём и пишутся операционные системы. Но это не означает, что этот язык единственный. Для написания ОС можно использовать и более высокоуровневые языки, например C++ или Python.
Прим. перев. Есть пример написания «игрушечных» операционных систем на C#. Cosmos — некий конструктор ОС. В этой статье на практическом примере показывают написание системы всего в нескольких десятках строк.
Язык ассемблера для x86
«x86 Assembly Guide» — неплохо подойдёт для начального изучения ассемблера. Несмотря на то, что эта статья коротка для полного курса, в ней содержится всё необходимое для дальнейшего углубления.
Книга «Programming from the Ground Up» Джонатана Бартлетта является одной из основных по изучению ассемблера. В ней основами языка программирования подкрепляются базисы информатики.
Для изучения ассемблера есть ещё одна показательная книга — «The Art of Assembly Language», написанная Рэнди Гайдом. Изначально книга писалась специально для курсов, которые вёл автор в Калифорнийском университете Cal Poly и UC Riverside. В середине 90-х годов книга была признана определяющей в этой сфере.
Если вдруг вышеописанные материалы вам не подошли, вот ещё пара отличных книг:
Язык Cи
Как уже упоминалось выше, для написания ОС есть несколько высокоуровневых языков программирования. Однако самый популярный из них — Си.
Начать изучать этот язык можно отсюда. Этот ресурс ознакомит вас с базовыми понятиями и подготовит к более сложным задачам.
«Learn C the Hard Way» — название ещё одной книги. Кроме привычной теории в ней собрано много практических решений. Этот учебник расскажет обо всех аспектах языка.
Либо же можете выбрать одну из этих книг:
Разработка ОС
После освоения всего необходимого, что касается информатики, языка ассемблера и Cи, вам стоит прочесть хотя бы одну или две книги про непосредственную разработку ОС. Вот несколько ресурсов для этого:
«Linux From Scratch». Здесь рассматривается процесс сборки операционной системы Linux (учебник переведён на много языков, в том числе и на русский). Тут, как и в остальных учебниках, вам предоставят все необходимые базовые знания. Полагаясь на них можно попробовать себя в создании ОС. Чтобы сделать программную часть ОС более профессиональной, присутствуют дополнения к учебнику: «Beyond Linux from Scratch», «Automated Linux from Scratch», «Cross Linux from Scratch» или «Hardened Linux from Scratch».
«The little book about OS development» Эрика Хэйлина и Адама Ренберга. Этот учебник разработан в рамках продвинутого курса информатики и на момент его написания авторы являлись студентами Королевского Института Технологий в Стокгольме. В этой книге рассматривается разработка ОС для архитектуры x86 (причём с самого начала — с установки среды разработки). В этом курсе рассказывается о многих интересных темах, включая многозадачность, управление памятью и разработку файловой системы.
«Operation System Development Series» Broken Thorn Entertainment — серия из 25 уроков, посвящённых разработке ОС с нуля.
Примечание Эти уроки рассчитаны на то, что вы уже знакомы с IDE и владеете как языком ассемблера, так и Cи.
Вот ещё три книги, которые помогут вам ознакомиться с дисциплиной разработки ОС:
Сообщества, посвященные разработке ОС
Заниматься разработкой ОС в одиночку смело, но сложно. Гораздо проще найти единомышленников, которые, как и вы, решили попытать удачу в этом нелёгком деле. Существует пара подходящих мест:
Заключение
Обучение разработке ОС — достаточно сложная задача. Однако в процессе вы разберётесь в работе процессора и аппаратного уровня, что поможет лучше понимать работу и оптимизацию высокоуровневых приложений и их взаимодействие друг с другом. Ну и в глазах коллег вы наверняка будете выглядеть очень крутым (но это не точно).
Создаем новую OS. Действительно новую, реально операционную, и правда – систему
Общие характеристики системы
Основные принципы, лежащие в основе работы ОС
▍Знакомьтесь, Resource-Owner-Service (ROS) модель
Назовем экземпляры этих объектов «каналами». Канал – это разделяемый объект, содержащий как код, так и данные и предназначенный для передачи данных и управления между задачами. Заметьте, что здесь намеренно отсутствует разграничение на провайдера и потребителя услуг (то есть, сервер и клиент), так как каждая задача может и предоставлять, и потреблять определенный набор сервисов. Из исключительности каналов как средства взаимодействия задач следует еще одно свойство ROS-модели: коммуникационная синхронизация. Любая передача управления между задачами по определению может осуществляться только в связке с получением\предоставлением услуги, то есть, каналы становятся синхронизационными объектами, однозначно определяющими место и назначение синхронизации задач.
ОС не имеет никакой информации и не делает никаких предположений о предназначении каждого канала. Так что каналы должны предоставлять идентификаторы, однозначно определяющие тип, цель или иную информацию, необходимую для конкретного взаимодействия.
Для обеспечения исполнения задач система создает для каждой задачи специальный системный канал.
Дизайн ОС включает в себя два вида каналов: дуальные и мульти. Как видно из названия, у первых число присоединенных задач не может превышать 2, а у последних ограничения по количеству подключенных задач отсутствуют (определяются исключительно объемом доступной памяти и особенностями конкретной реализации ОС). Каждый канал имеет два «противоположных» конца. Задачи, присоединенные к ним, называются экспортерами и импортерами канала, соответственно. Разница между этими двумя типами задач несущественна – оба должны создать экземпляр канала, то есть, выделить память и таким образом поместить канал в свое адресное пространство. Единственная цель разделения на экспортеров и импортеров – поддержка задач с традиционной семантикой клиент-сервер, т.е. производитель и потребитель услуг.
На рисунке ниже представлена принципиальная схема ROS OS:
Все крайне просто. Серо-голубым цветом помечены физические компоненты системы – процессоры (CPU), память (memory). Dev (Device) – это физическое устройство хранения данных.
Ядро ОС владеет ресурсами процессоров и памяти. Остальными ресурсами системы могут владеть привилегированные задачи (P-task), предоставляющие в свою очередь сервисы задачам пользовательского уровня (U-task) посредством коммуникационных каналов (channel).
ROS OS реализует: Менеджер Памяти (ME-M), Менеджер Каналов (CH-M), Менеджер Системных Каналов (SC-M), Менеджер Задач (TA-M), и Диспетчер Задач (TA-D). Ядро идентифицирует задачи и запросы на сервисы посредством системных каналов (syschan).
Управление задачами
▍Скоординированное вытеснение (cooperative preemption)
В отличие от Windows и Linux, которые сохраняют контекст задач при их переключении, потребляя при этом значительное количество памяти на размещение стека, а также теряя производительность на инструкциях сохранения регистров, предлагаемая OS дает возможность каждой задаче сообщить ядру, что сохранять ее контекст не требуется.
Вместо этого, задачи предоставляют окружение исполнения, состоящее из четырех указателей в форме , так что ядро может очистить стек задачи, а затем, непосредственно перед активацией, выделить задаче новый (или предоставить существующий пустой) стек, после чего позвать функцию func с данными параметрами. При этом, значения остальных, не используемых в передаче этого окружения регистров остаются неопределенными или обнуляются, что быстрее сохранения\восстановления корректного значения.
Непосредственно перед активацией задачи система очищает окружение из 4-ех указателей, чтобы исключить ошибочное преждевременное вытеснение задачи.
Заметим, что скоординированное вытеснение (при условии, что все задачи в системе ему следуют) означает, что при идеальных условиях исполнения для каждого ядра CPU будет существовать только один стек. Дополнительные стеки будут выделяться, только если задача будет вытеснена преждевременно, перед тем, как она инициализирует контекст из 4-ех указателей.
▍Модель передачи управления для потоков (Yield-To)
Дизайн ОС не предполагает явных функций ожидания (wait) или взаимного исключения для потоков. Вместо этого межпотоковая синхронизация достигается явной передачей управления другим задачам, идентифицируемым при помощи указателя на канал и номера задачи в канале. То есть, управление передается не конкретной задаче, а любому агенту, который предоставляет соответствующий сервис и проиндексирован в своем сервисном канале. При этом, за конкретную эффективную внутреннюю реализацию протокола для синхронизации отвечают сами коммуникационные агенты.
Операционная система может поддерживать множественные стратегии передачи управления задачами, такие как «уступить любой», «уступить заданной» и «разрешить исполнение заданной». Последняя стратегия подразумевает, что уступающая задача не намеревается отдавать контроль на «своем» CPU, так что новая задача должна быть активирована в параллель с текущей на другом CPU.
▍Детерминированное планирование задач
Каждая задача активируется системным таймером (как и в существующих ОС), но, с учетом применимости ROS OS к системам реального времени, каждая задача должна задать требования к планировщику задач в виде двух параметров: частоты и продолжительности активации. Помимо своего основного назначения, эти параметры используются для оценки предполагаемой загрузки системы, количества ожидаемых конфликтов задач и выделения в соответствии с этим необходимых ресурсов (тех же стеков)
В идеале, суммарная продолжительность активаций всех задач должна быть меньше или равна минимальному заданному периоду активации, а периоды должны быть кратны минимальному. Выполнение этих условий будет гарантировать отсутствие конфликтов планировки.
Но в нашем несовершенном мире некоторые задачи могут превысить свою заявленную продолжительность, в таком случае они могут быть вытеснены другими, готовыми к исполнению задачами и помещены в список «на будущее исполнение» в ближайшие свободные слоты.
▍Производительность
Так как в ROS модели может существовать несколько провайдеров одного и того же сервиса (по сети или даже локально), единственным критерием выбора между различными провайдерами будет их производительность в данных конкретных условиях.
Для управления производительностью программ системный канал имеет счетчики-таймеры активного времени и времени ожидания, предоставляющие информацию о состоянии текущей задачи. Так как обычно известно, какой задаче (каналу) было передано управление, производительность может быть оценена просто по значению соответствующего таймера по возвращении в вызывающую задачу.
Сравнив производительности нескольких каналов, задача может переключиться на использование более быстрых из них, что может оказаться особенно полезным в условиях динамической адаптации к меняющимся условиям (обширные сети, физически нестабильные окружения и т.д.).
▍Упрощение структуры кода
Поскольку каналы представляют собой динамические структуры данных, разделяемые между адресными пространствами задач и подверженные возможным перемещениям в памяти ядром ОС, код каналов, да и задач в общем случае должен быть написан так, чтобы не зависеть от статичного положения данных в памяти (или располагать их относительно вызывающего кода) и позиции самого кода. Отсутствие статичных структур, независимость от позиции и контекст из 4-ех указателей позволяют обойтись без сложных заголовков программ и определяет следующую простейшую структуру программы:
Каждая программа представляется в памяти в виде двух частей: кода и данных (с опциональным разграничением между ними для обеспечения защиты доступа). Начало куска кода – это стартовая функция задачи, принимающая на вход три указателя, как описано выше.
▍Создание и структура задач
Задача может быть создана из любого фрагмента кода. Адрес начала кода будет являться адресом стартовой функции задачи – той самой, с прототипом четырех указателей – func(chan, sys, loc), где chan и loc – опциональные (так, loc – может указывать на локальные данные), а sys – указывает на созданный для задачи системный канал. Заметим, что код задачи копируется на новое место в памяти для упрощения дальнейших операций с каналами – например, если часть кода будет экспортирована в качестве канала.
Внутренняя структура задач выглядит так:
Каждая задача содержит дескриптор, описывающий ее тип (type) – пользовательский или привилегированный, а также указатели на: таблицы страниц адресного пространства (address space), локальную память (heap), стек (stack) и обработчик исключений (exception handler).
Помимо этого, дескриптор задачи включает список отображенных каналов – (task2chan), т.е. список пар: «индекс-дескриптор канала, указатель на код данного канала».
В случае, когда задачи разделяют общее адресное пространство, указатели каналов могут пропускаться с целью оптимизации использования памяти.
Первый элемент списка отображенных каналов – это всегда системный канал задачи. Он хранит контекст исполнения и другие свойства, как описано дальше.
▍Диспетчеризация задач
Дизайн ОС предусматривает два типа активации задач: (а) по системному таймеру согласно запрашиваемому расписанию и (б) по явной передаче управления из другой задачи.
Расписание активации может быть запрошено в виде периода и продолжительности активации. Эти два параметра определяют следующую диаграмму состояния задачи
Граф изменения состояния задач.
Изначально, при активации задачи, она входит в защищенное (active-protected) состояние, то есть, она не подлежит вытеснению. После того, как задача превышает заявленную продолжительность, защита от вытеснения снимается. В случае, когда в листе готовых к исполнению задач (ready list) есть другая задача, система может вытеснить первую задачу, поместить ее дескриптор в ready list и активировать другую задачу. Вновь активированная задача возобновляет исполнение либо в активном состоянии (если она была вытеснена ранее), либо в защищенном состоянии (в случае запланированного исполнения или вообще для всех задач, в зависимости от конкретной реализации)
Важный момент: задание расписания исполнения на основе периода позволяет ядру системы гарантировать задачам реального времени определенную частоту активации, а не предельный срок ее начала. Таким образом, система может сдвигать задачи во времени, если это не нарушает частоту активации. Задание продолжительности позволяет избежать проблем, связанных с приоритетом задач, посредством определения для них предварительно запланированного (запрошенного) отношения активности/ожидания. Конкретные реализации ОС могут ограничить продолжительность максимальной длиной кванта времени, чтобы «жадные» задачи не занимали процессор бесконечно. Все вышесказанное упрощает схему планировщика и обеспечивает его быстрое функционирование.
Планировка на основе заданных периода и продолжительности активации позволяет планировщику определять неизбежные конфликты (см. рисунок ниже) и либо отклонять запрос на активацию, либо смягчать требования планировки реального времени.
Помимо вытесняющей многозадачности, система поддерживает и кооперативную. Явная передача управления может осуществляться с помощью специального системного метода yield(). Вызов этого метода приведет к передаче управления задаче, идентифицируемой при помощи указателя на канал и номера задачи в нем, и исполнению данной задачи на заданном процессоре. Также, как было сказано выше, возможно передать управление не конкретной задаче, а любому агенту, который предоставляет соответствующий сервис и проиндексирован в своем сервисном канале.
Каждый конфликт планировки (включая динамический, когда задачу вытесняют по превышению продолжительности исполнения) в общем случае приводит к выделению ядром ОС дополнительных ресурсов – нового стека для активированной задачи. Поэтому для оптимального использования системных ресурсов каждая задача может сообщить ядру ОС, что она не нуждается в сохранении регистров и данных стека. В этом случае ОС при вызове yield() может освободить стек задачи и сбросить содержимое регистров. При активации такой задачи система вызовет прототип
Для обеспечения запланированной или вытесняющей активации задачи диспетчер задач поддерживает список готовых к выполнению задач. Это – кольцевой буфер, содержащий индексы-дескрипторы (или указатели) задач и запланированное время активации, как показано на рисунке ниже. Для вытесненных задач это время будет, конечно, нулевым.
Время может выражаться в абсолютных или относительных единицах (по отношению к максимальному периоду), и обновляться в соответствии с запрошенными периодами активации. Когда задача вытесняется или уступает контроль, ее дескриптор помещается в первый свободный слот кольцевого буфера. Отметим, что так как список упорядочен по времени, задача может быть вставлена в список перед другими, если крайний срок ее активации наступает раньше.
Готовые к исполнению задачи могут выбираться из листа, начиная с конца (хвоста) или с указателей на листы задач (task list pointers), содержащихся в Блоках управления процессорами, которые описаны ниже.
Накладные расходы планировки задач разделяются на статические и динамические. Первые – это постоянное время инициализации процессорного контекста задачи (напомним, что именно это время уменьшает кооперативная многозадачность), а вторые – накладные расходы самого диспетчера задач, пропорциональные количеству операций поиска в листе готовности задач (как для поиска текущей готовой к исполнению задачи, так и для вставки новой). При этом, нет необходимости поиска задачи для активации, так как она всегда будет находиться в «хвосте» списка.
Накладные расходы на вставку задач будут минимальными, если все задачи запросили периоды активации одинаковой продолжительности. Если же периоды разные, то поиск займет логарифмическое число операций, так как лист готовности включает набор следующих друг за другом, по большей мере, сортированных данных, а несортированные элементы могут быть найдены по цепочке ссылок.
▍Управление каналами
Каждому каналу в системе присваивается дескриптор, который хранит информацию о топологии канала (type), его идентификатор (guid), а также указатели: на тело канала (body pointer) в общем адресном пространстве, где размещены все каналы; и на дескрипторы задач (chan2task), которые присоединены к данному каналу. То есть, система хранит таблицу дескрипторов каналов, показанную на рисунке ниже:
Обратные ссылки каналов на задачи необходимы для идентификации задач посредством указателя на канал и внутриканального индекса (для передачи управления между задачами). В этой схеме внутриканальный индекс – это позиция дескриптора задачи (task descidx) в соответствующем листе chan2task.
▍Системные вызовы и управление контекстом
Системные каналы – это комплекс средств для идентификации задач, сохранения их контекста, получения системной информации, генерации системных вызовов и передачи управления другим задачам.
На рисунке ниже показана структура системного канала.
Как видно, аргументы системных вызовов не передаются через стек или регистры, а копируются в соответствующие структуры системного канала.
В системном канале размещается информация о свойствах и возможностях компьютерной платформы, позволяя ее использование без дополнительных накладных расходов на системный вызов.
Комбинация в одном канале четырех-указательного окружения исполнения и контекста исполнения может быть удобной для целей удаленной отладки\мониторинга.
Информация о хронометраже каждой задачи обновляется ядром ОС в реальном времени. Наличие полей, относящихся к каждому процессору системы, позволяет параллельную активацию задач (идентификация задач происходит на основе таблицы дескриптора канала).
Конкретные реализации системы могут выделить один регистр (доступный для чтения непривилегированным задачам – например, при наличии поддержки в железе, сегментный регистр) для хранения постоянного указателя на текущий системный канал задачи. В этом случае задачам не требуется сохранять указатель на системный канал, вместо этого они могут ссылаться на него через соответствующий макрос.
Системный канал должен обязательно поддерживать следующие функции, которые, фактически, будут являться системным API:
То есть, весь системный API состоит менее, чем из 10 функций!!
▍Управление процессорами
Каждому процессору в системе присваивается Блок Управления Процессором, который содержит некоторые свойства текущей выполняемой задачи, как показано на рисунке ниже.
Также в соответствие процессору ставятся некоторые другие управляющие таблицы – прерываний (включая межпроцессорные) и таблица системных дескрипторов.
Уровни сложности системы
Сложность определенной реализации системы может зависеть от доступного объема памяти, процессорных возможностей и производительности конкретной платформы. Ниже описаны возможности регулировки сложности ядра ОС.
▍Реализация управления каналами
Каналы, являясь основой дизайна ОС, допускают значительную вариативность. Например, разработчики ОС могут выбрать поддержку исключительно дуальных каналов, исключая таким образом необходимость динамического выделения списков членов каналов. Кроме того, система может не поддерживать каналы с кодом (или, по крайней мере, смешанные каналы для кода и данных), вследствие чего упрощается использование традиционных компиляторов и сред разработки, так как пропадает необходимость агрегирования кода и данных.
Каналы могут идентифицироваться уникальными 128-битными идентификаторами либо определенными индексами, валидность которых может контролироваться локальной (масштаба системы или сети) или глобальной службой.
Еще одна возможность – присвоение каналам имен, образованных в виде иерархических путей, подобных системным файловым путям существующих ОС.
▍Реализация управления задачами
Так же, как и в современных ОС, предлагаемый дизайн операционной системы подразумевает возможность реализации задач как в форме процессов, так и в форме потоков, то есть, задачи могут быть как изолированными (логически и физически, если это позволяют возможности процессорной системы), так и разделять одно адресное пространство, а значит, и передавать данные через разделяемые переменные.
Еще одна возможная, но очень важная особенность реализации – это уровень привилегий задач, то есть, доступность задачам определенных системных и процессорных ресурсов (например, межпроцессорных прерываний, таблиц дескрипторов процессоров, входных-выходных портов).
Возможное решение – это поддержка исключительно привилегированных задач, что приведет к экономии усилий по реализации изоляции задач, защите памяти и процессорных ресурсов.
Если же поддерживаются как привилегированные, так и непривилегированные задачи, дизайн ОС предусматривает две возможности для реализации привилегированных операций.
В первом случае, все привилегированные операции могут исполняться только ядром, то есть, все привилегированные программы становятся частью ядра ОС и исполняются в его контексте (или контексте запрашивающей стороны). Назовем это «общей схемой». Достоинства этого подхода – обслуживание привилегированных операций может не требовать переключения контекста задач (операции выполняются в контексте запрашивающей стороны) в случае, когда адресное пространство ядра ОС отображается на адресное пространство каждой задачи. Кроме того, так как системное ядро всегда распараллелено по числу процессоров системы, параллельные задачи, запрашивающие привилегированные операции, не будут простаивать даже при отсутствии возможности исполнения их контекста. Недостаток – запрашивающая задача не сможет продолжить исполнение до тех пор, пока запрос не будет обработан.
Во втором случае все привилегированные задачи могут быть отделены от ядра («раздельная схема»).
Это решает проблему параллельного исполнения запрашивающих и выполняющих запросы задач, но вносит дополнительное переключение контекста по каждому запросу и получению прерывания (так как прерывания, принадлежащие привилегированным задачам, могут произойти во время исполнения любой другой задачи).
Поэтому полезным решением может стать объединение общей и раздельной схем. По умолчанию, все привилегированные операции могут быть выполнены от лица запрашивающих их задач (как часть ядра), но, по мере необходимости, могут создавать другие привилегированные задачи, исполняемые отдельно, и передать им управление и данные с помощью каналов.
Для реализации комбинированного подхода может потребоваться дополнительное расширение к вышеописанной функциональности ядра – системный вызов, соединяющий вектор прерываний и его обработчик – сервисную функцию, вызываемую ядром системы при передаче управления привилегированному каналу, владелец которого – часть ядра, а не отдельная задача.
При вызове этой функции система проверяет привилегии инициатора запроса и текущий индекс задачи. Ядро ОС гарантирует при получении каждого прерывания из указанного вектора переключение контекста на привилегированную задачу – инициатора запроса. Нулевой параметр handler удаляет предварительно установленный обработчик прерываний.
Дескриптор канала в этом случае будет содержать функцию- обработчик прерываний.
Примеры коммуникаций посредством каналов
▍Дуальные каналы
Простейшая модель коммуникации задач – это дуальные каналы. Они гарантируют обслуживание только двух коммуницирующих агентов, хотя каждый из них может соединяться с более чем одним каналом того же ID. То есть, и один провайдер сервиса может предоставлять его нескольким клиентам (каждому – в отдельном канале), и один потребитель получать одну и ту же услугу от разных поставщиков.
Дуальные каналы являются эффективным средством передачи данных в случае, когда присоединенные к ним агенты копируют свои данные в разделяемое внутриканальное хранилище и извещают друг друга о завершении операции копирования\обработки данных (так что ожидающие агенты не тратят попусту вычислительные ресурсы).
Дуальные каналы кода практически эквивалентны каналам с данными, единственное отличие – они предоставляют разделяемый интерфейс, который инкапсулирует операции обработки и передачи данных, что может оказаться более удобным в некоторых случаях объектно-ориентированного дизайна. В этом случае операции передачи управления могут осуществляться внутриканальным кодом по поручению текущей задачи.
Здесь и на последующих рисунках U-Task означает пользовтельскую задачу.
▍Мульти-каналы
Мульти-каналы могут использоваться для обеспечения вычислительного сервиса – то есть, для разделения кода между несколькими задачами (подобно динамическим библиотекам во многих традиционных ОС).
Разделяемый код при этом необязательно должен поддерживаться своей задачей-экспортером.
Задача может первоначально экспортировать канал и завершиться, а внутриканальный код при импорте разместит локальные данные в адресном пространстве импортирующей задачи и, таким образом, будет являться как полностью интегрированным с импортером, так и изолированным от других импортеров (для случаев, когда конкретная реализация ОС поддерживает изоляцию адресных пространств).
Ниже обсуждаются более сложные случаи мульти-канальных конфигураций.
▍Пулы задач
Предназначение пулов задач – поддержка синхронизационных моделей, традиционно используемых в симметричной многопроцессорности (SMP). Каналы данных, к которым присоединены несколько задач, могут быть как контейнером для разделяемых (обрабатываемых параллельно) данных, так и служить средством синхронизации, то есть, включать в себя счетчик числа задач-пользователей канала и, опционально, их индексов в канале.
Пулы задач могут использовать возможности планировки задач ОС и обеспечивать эффективную синхронизацию параллельных задач – в противоположность наиболее примитивным схемам опроса каналов для синхронизации.
Экспортер канала может взять на себя обязанности распределения работы и, так как количество процессоров и распределяемых задач известно, экспортер может передать управление определенным задачам на определенных ЦПУ. Когда задачи-исполнители завершат обработку данных, они могут вернуть управление распределяющей работу задаче.
▍Пулы запросов
Пулы запросов могут оказаться эффективными в условиях, когда создание отдельного канала для каждого клиента потребовало бы значительных затрат памяти – при разделении больших буферов памяти и\или обслуживании большого числа клиентов.
Эти пулы обеспечивают интерфейсы, которые можно назвать арбитражными. Победитель арбитража может поместить запрос (передать данные), а другие инициаторы запросов могут быть переключены в неактивное состояние (прозрачным образом – с использованием внутриканального кода). Когда обслуживание победителя арбитража завершается, победитель извещается об этом, копирует свои выходные данные, и арбитражный процесс возобновляется – из остальных участников арбитража выбирается победитель, пробуждается операцией yield, и процесс полностью повторяется.
▍Маркеры доступа
Маркеры доступа (Access tokens) позволяют реализовать модель разделения данных (и\или получения одинакового обслуживания ) между несколькими задачами без установки каналов передачи данных. Вместо этого, единственный провайдер сервисов управляет всеми ресурсами или обеспечивает сервисы всем активным агентам в системе. Каждый агент может запросить у него маркер доступа, который и будет являться ключом к разделяемым данным. Затем агенты могут «поделиться» маркером с другими доверенными агентами (посредством специального канала обмена), в результате чего доверенные агенты смогут получить тот же самый тип обслуживания или доступа к данным.
▍Параллельный доступ к устройствам
Прежде чем говорить о работе с физическими устройствами, заметим, что драйвера в ROS OS – это не особые выделенные сущности, а обычные привилегированные задачи, предоставляющие свои сервисы посредством каналов.
Во многих случаях необходимо обеспечить нескольким задачам одновременный доступ к потокам данных, производимым или потребляемым физическим устройством. На рисунке ниже показаны 2 типичных примера параллельной коммуникации с устройством.
Первый будет эффективным, если ядро ОС различает процессы и потоки. В этом случае специальная задача может обрабатывать все операции с устройством и буферизовать входящие\исходящие потоки данных, в то время как фактическое обслуживание задач-потребителей данных будет производиться потоками, имеющими полный доступ ко внутренним буферам и, соответственно, возможности проверить наличие данных и избежать ненужных задержек. На рисунке данная схема показана слева.
Второй вариант реализации может быть использован в случае пакетной обработки данных. В этом случае обслуживающая задача, непосредственно взаимодействующая с устройством, может выделить необходимые буфера в экспортируемых ей каналах (так как размер пакета известен и ограничен – так же, как и размер буферов). Обе стороны, подключенные к каналам, будут сообщать о готовности данных друг для друга – так, что обслуживающая задача сможет по получении одного запроса безотносительно от того, откуда он получен, обслужить все каналы, таким образом облегчая реализацию параллелизма в системе. Эту схему иллюстрирует правая сторона рисунка.
▍Удаленное использование каналов
В соответствии с дизайном ОC – независимостью работы с компонентами от их расположения, каждый агент в локальной системе может соединиться с каналом, экспортируемым удаленно. Для поддержки этого механизма в систему вводятся так называемые репликаторы каналов, которые помимо поддержки обычной функциональности экспорта\импорта каналов опрашивают свои локальные системы на предмет имеющихся каналов, проверяют наличие сетевых запросов на эти каналы, и, при их наличии, поддерживают пары (наборы) удаленно синхронизированных каналов максимально прозрачным образом для удаленных клиентов этих каналов. Иллюстрация описанному механизму – ниже.
Здесь и на последующих рисунках P-Task означает пользовтельскую задачу.
Отметим, что для эффективной поддержки удаленных репликаторов каналов необходим дополнительный системный вызов
Здесь guid[] – массив индексов каналов, size[]предоставляет размеры каналов, а type[] содержит типы\топологию запроса канала (импортированный, экспортированный или мульти).
▍Поддержка со стороны языков программирования
Существующие языки программирования потребуют небольшого расширения для поддержки ROS модели и облегчения разработки для предлагаемой ОС. В случае C++, расширение, затрагивающее семантику языка, это модификатор типа – “channel”, показывающий тип содержимого, которое должно быть объединено в форму, пригодную для межпроцессной коммуникации. Оставшиеся проблемы, связанные с канальной коммуникацией, решаются с использованием функций ROS OS API, как показано ниже.
То есть, сначала требуется объявить тип вашего канала (используя модификатор типа channel), а также выделить стандартным способом области памяти для экспортера и импортера канала. После чего канал, очевидно, должен быть присоединен посредством экспорта с одной стороны и импорта с другой. Для этого используются специальные функции export() и import(), в которые передаются указатели на ваш канал, системный канал и указывается вид канала (мульти или дуальный).
Проверки указателей, приведенные после вызовов этих функций, приведены здесь для сред с разделяемым адресным пространством, где существует вероятность, что ядро ОС передвинет тело канала в памяти с выделенного ранее места.
Каждые агент, подсоединенный к каналу, имеет свой внутриканальный индекс, получаемый функцией self(), который остается неизменным де тех пор, пока агент не отключится от канала (вызовом disconnect()) и не присоединится к нему снова (посредством import() и export()). Остальные связанные с каналами функции в соответствии с дизайном ОС рекомендуется определить так, чтобы они принимали указатель на ваш канал, текущий системный канал, а также указатель на локальное хранилище данных или опциональный параметр.
Ниже приведен прототип функции chanfunc, которая может являться как функцией запуска задачи с семантикой (arg0, sys, arg1), так и функцией инициализации канала (которая выделит локальное хранилище данных и вернет его указатель loc), либо вообще любой служебной внутриканальной функцией
▍Генерация кода
При написании программ для ROS ОС с использованием существующих компиляторов, предназначенных для других ОС, надо соблюдать осторожность. Так, разработчик должен позаботиться о неиспользовании статических переменных и работать только с автоматически (стек) и динамически выделяемыми данными и/или пользоваться возможностями некоторых компиляторов по генерации кода, не зависящего от адреса загрузки. В идеале специальный компилятор для данной ОС должен быть способен обнаружить ссылки на статические данные и сгенерировать вычисление соответствующего адреса в памяти относительно к адресу использующей эти данные функции.
Еще одна проблема, которая не может быть решена традиционными компиляторами (кроме ассемблера) – это поддержание комбинированных каналов кода и данных. Специализированный компилятор данной ОС должен уметь объединять тела канальных функций и данные в единый монолитный объект, который может быть отображен, передвинут и обработан ОС.
Для процессорных архитектур, поддерживающих защиту исполнения данных, агрегация кода и данных должна проходить на базисе раздельных страниц, чтобы не компрометировать безопасность системы.
Выводы
Основа предлагаемой модели ОС – сервисно-ориентированный подход к параллельному исполнению программ реализует новые принципы передачи управления, планировки задач и управления ресурсами, а также новые логические топологии программной коммуникации и синхронизации, которые удовлетворяют потребности современных параллельных и распределенных компьютерных систем, включая как мощные сервера, так и сети беспроводных сенсоров.
При этом, система продумана с точки зрения связывания вместе железных и программных компонентов компьютерной системы, и максимально проста в реализации.
Многие из описанных принципов дизайна ОС были первоначально воплощены ее автором еще в прошлом веке (1999 году) как часть легковесной ОС, служившей предсказуемой и полностью контролируемой средой тестирования для исполняемых файлов Windows NT. И, конечно же, с тех пор многое было добавлено и улучшено.
Как видите, создать свою ОС на базе описанных принципов возможно. Было бы желание. Если оно у вас есть, то автор идеи, несомненно заинтересованный в ее реализации, с удовольствием вам поможет – проконсультирует и поддержит.