OSDev

Таким образом можно вынести планировщик из ядра. Пусть ядро это загрузчик и редактор связей. В любом исполняемом файле системы в местах вызова кода других исполняемых файлов вставляется syscall инструкция. Загрузчик патчит ее jmp'ом с правильным адресом, или оставляет сискол, если вызываемый код в другом адресном пространстве. Для создания новых потоков, вызывается апи планировшика, который просто еще одна прдключаемая библиотека.

Процессы, получается, не нужны? То есть, реально в ядре будет таблица адрессных пространств вместо процессов. А вся система состоять из того, что сейчас называется статические и динамические библиотеки, которые могут быть в отдельном адресном пространстве. В ельф просто добавить информацию о зависимостях что бы статически их загружать.

Так можно развить идею к тому, что ядро это просто интерпретатор некоторого байткода. Он простой и может быть даже не тюринг полный, нужно только что бы в нем можно было делать динамическую загрузку машинного кода, а потом управлять им как объектом этого самого байткода. В машинном коде можно делать вставки этого байткода (его интерпретатор подменит на джампы).

Кооперативную многозадачность никто не отменял. Мысль. Если разделить стек вызовов и стек данных для функций, то это упростит переключение задач.


Процессы нужны для для изоляции программ друг от друга. Если одна упадёт она не похоронит всю систему. Плюс для ИБ что-бы одни задачи не могли без разрешения изменять память другого процесса. И не могла считать приватные ключи, пароли и тп.



Майкрософт экспериментировала с этим для C#.

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

Да, я это называл адресными пространствами.


Нет же. Я не предлагал писать приложения на байткоде, он у меня даже не тюринг полный. Вот сейчас в elf и pe файлах же не только машинный код, там хедер и другие структуры даных. Это тоже байткод со вставками машинного кода. ОС его интерпретирует. Только это убогость по сравнению с нормальным байткодом.

Планировать нужно не процесы, а потоки, здесь все без изменений. Только планировщик - отдельный бинарь, который линкуется ко всему остальному во время загрузки.