Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 30
По-моему, делать ОС, которая и для сервера и для десктопа так себе идея. Слишком разные требования.
Семейство убунты разве не этим же занимается? У меня и на десктопе, и на сервере и gh раннеры
Ну я на работе пишу под чисто серверную систему, а на десктопах у меня винда и линукс. Огромная разница в том, как реализовано на сервере и как на десктопе.
Описывать разницу будет слишком долго. Потому что все иначе.
Если интересно - можно почитать Ф.Солтис "Основы AS/400" Там много как общей, так и технической информации о внутренней организации системы.
Windows и Linux пытаются работать и на сервере, и на десктопе практически без изменения ядра — отсюда и компромиссы, и форки.
В OptimaOS ядро содержит только самый минимум (память, IPC, безопасность, планировщик с настройками). Всё остальное — сеть, файловые системы, GUI — вынесено в userspace и собирается в нужную конфигурацию через runtime-профили. Под сервер подкладывается один набор политик и сервисов, под десктоп — другой, под edge — третий. Ядро при этом одно и то же.
Получится ли обойти те противоречия, о которых вы говорите, — покажет время. Но архитектурно я заложил возможность настраивать поведение под задачу, а не пытаться сделать «одну систему, которая всем хороша».
Десктопные и серверные системы, все-таки, отличаются не только наличием GUI. У серверных систем совершенно другие требования по нагрузке - они работают у условиях огромного количества одновременно выполняющихся заданий и тут сразу встают вопросы изолированности заданий друг от друга так, чтобы даже самая кривая программа в одном задании не могла оказать влияние на все остальные. Не скажу за линукс, но винду я легко могу загнать в дикие лаги одной программой. Всю винду. Так, что даже завершить процесс будет сложно.
Второй момент - время переключения контекста заданий. В винде/линуксе это достаточно большие накладные расходы.
Третий момент - системное логирование, журналирование изменения объектов. На серверной ОС всем этим должна заниматься система (системные журналы, логи заданий...).
Четвертый момент - поддержка исключений на уровне системы, а не ЯП. Т.е. вы не должны ориентироваться на языковые исключения, а иметь в доступе простой механизм использования системных с возможностью проброса их на любой уровень стека вызовов по необходимости.
А то, что Вы описываете - тут скорее надо смотреть как реализованы микроядерные ОС. Например, QNX
Apple так делал, вполне нормальный вариант при микроядерной архитектуре.
Странное желание… В то время, как Rust и C++ работают над тем, чтобы как можно больше можно было перенести в compile-time вы разворачиваетесь в обратном направлении и для специализированных систем предлагаете решать, что им нужно в runtime… Зачем? Чтобы энтузиасты смогли запустить Doom на еще одном устройстве?
Согласен, тренд в C++ и Rust — это максимальный перенос в compile-time. Но здесь важно разделить что мы выносим в runtime и почему.
В OptimaOS в runtime вынесена не логика работы драйверов или ядра — она вся скомпилирована и статически верифицирована. В runtime вынесены решения о конфигурации, которые заранее неизвестны. Эти решения невозможно принять в compile-time, если мы не хотим превратиться во фрагментированный зоопарк форков — ровно ту проблему, которую я пытаюсь решить.
Зоопарк форков потому и появляется, что форк – это просто compile-time решение для конфигурации конкретного устройства. Все равно, что feature-флаг в Rust или дефайн в С++ – только живет не в общей базе кода, а у конкретного производителя (в общей зачем ему быть, если железо, для которого он нужен, есть только у конкретной компании?). Зачем там грузить что-то в runtime, если это всегда будет одно и то же?
А Redox OS не закрывает необходимый функционал? Я жду выхода финальной версии, мне кажется очень иниересный и перспективный проект
Напомнило
Без совместимости с NTAPI или *nix (то есть теми самыми 30-летними ядрами и всем их техдолгом) вы теряете драйвера, прикладное ПО, программистов и пользователей. Имитировать их сисколлы программно, делать обёртки и прослойки к вашему ядру - это долго и дорого (плюс накладные расходы на все операции), что не есть хорошо.
Может проще было сразу пилить *nix-like ядро, а не городить Linux ABI/API поверх? Меньше слоёв абстракции - лучше, или нет?
Да, было бы проще, но не интереснее и потенциально полезнее. Моя гипотеза в том, что можно построить одно безопасное ядро с минимальным TCB, а совместимость с экосистемой обеспечить через прослойку, которая будет достаточно тонкой, чтобы не убивать производительность, но достаточно полной, чтобы не плодить форки.
Redox OS, кстати, идёт похожим путём — они тоже реализуют совместимость с Linux. И у них это работает.
Для совместимости с существующим ПО в архитектуру с самого начала заложен linux-compat — не как надстройка или эмуляция, а как слой, транслирующий Linux syscall’ы в нативный optima_syscall_v0.
построить одно безопасное ядро с минимальным TCB, а совместимость с экосистемой обеспечить через прослойку, которая будет достаточно тонкой, чтобы не убивать производительность, но достаточно полной
Идейно схоже с Fuchia OS и Zircon?
слой, транслирующий Linux syscall’ы в нативный optima_syscall_v0
В этом-то и проблема: надо будет не просто транслировать сисколлы, а имитировать баги, специфическое поведение, поддерживать workaround'ы разработчиков вокруг всего этого. По итогу, вы придёте к подобию линухового ядра, под которым лежит ваше ядро, только в отличие от Linux, у вас будет меньше разработчиков. MS от первой версии WSL не просто так отказалась, хотя вам с вашим ядром проще будет это реализовать.
Настоящий линукс тоже, как не удивительно, реализует Linux ABI/API поверх внутренней инфраструктуры ядра, Которая не тождественна публичному API…
Просто сил и удачи!
То есть это будет микроядро полностью (memory-safe + unsafe) на Rust и с бинарной совместимостью с Linux и в т. ч. с линуксовыми драйверами? А какая лицензия планируется для кода в репозитории после публикации?
Бинарная совместимость с Linux не с ядром, а с пользовательским пространством Linux. Т.е. это userspace ABI, а не драйверная модель Linux. По лицензии — пока склоняюсь к MIT + Apache 2.0, окончательного решения не принял.
Fucshia делает не тоже самое?
я конечно вообще не спец в этом направлении. Но недавно поразмышляв о современных ОС, лично я пришел к выводу, что системы слишком архаичны, и несут за собой большой груз технического долга и множество попыток адаптации всего и вся. Что в свою очередь сталкивается с современными тенденциями и будущего данного направления.
Желаю успехов в данном проекте, надеюсь всё получится, на крайний случай, как минимум будет протестированная теория, которая либо окажется успешной, либо нет, либо вообще даст новое видение на всё это. Я пока больше теоретик только, и то начинающий, очень интересно будущее данного проекта. И в целом мне близки ваши мысли судя по вашим другим постам и идеям, относительно того же мессенджера
Изоляция процессов от памяти у вас через MPU/MMU ?
Уверены, что только профилем без подгрузки бинарного модуля получится обеспечить виртуальную память там где она есть и поддержать MPU там где её нет и который может быть вообще опционален, ведь трансляция адреса протекает во всю семантику внутренних структур ?
Видели TockOS (https://www.tockos.org/) как они решили изоляцию капсулами ?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Одно ядро для всех: строим современную ОС на Rust — от идеи до рабочего прототипа