2
kuragaА ваши цели написания ОС ограничиваются лишь проработкой вопросов инициализации/загрузки или же какие-нибудь другие концепции хотите обкатать?
Я в своем недоделанном проекте proto_axis, например, преследовал четыре идеи, во-первых,
-ядро должно было содержать только самое необходимое, IPC/синхронизация/нити/etc. Даже страничный менеджер памяти должен был работать отдельно от ядра, не говоря уже о драйверах/файловой системе/и т.д.
Во-вторых, IPC должна была быть клиент-серверной с элементами объектной-ориентированности, пусть даже за счет снижения производительности;
В-третьих, ядро я писал на C++ (умные дядьки работающие над микроядрами L4, e.g. fiasco, доказали, что быстрые ядра все-таки можно писать на языках высокого уровня).
Ну и в-четвертых, что самое интересное, ради увеличения производительности, ядро (а именно подсистема IPC) имело право модифицировать код исполняющихся программ "на лету". В простейших случаях это мало чем отличается от механизма динамической компоновки со связыванием при старте исполняемого модуля, используемой в большинстве осей (то есть дело ограничивается исправлением некоторых адресов); но в других случаях такая стратегия приводит к копированию достаточно больших участков обслуживающего кода (например из какой-нибудь библиотеки, или даже из драйвера или ядра) прямо в код прикладной программы для увеличения локальности кода и оптимизации использования кэша. Причем, в приложения могли встраиваться заглушки, "сочиненные" и скомпилированные ядром для конкретной ситуации.
Этот метод, вместе с некоторыми хитрыми алгоритмами управления свопом, должен был позволить достичь высокой производительности (за счет локальности) и надежности (за счет сохранения "мелкозернистой" модульности) системы. К примеру, в предварительных испытаниях, прототип оказался устойчивым к fork-бомбам и прочим напастям.
К сожалению, проект был заброшен, и когда я к нему вернусь, неизвестно...
В общем, а вы не хотели-бы какую-нибудь экзотику реализовать в вашей ОС, например отказаться от файловой системы, оконного интерфейса или ещё какую-нибудь "глупость" совершить?
Это я к тому, что какая-нибудь интересная (пусть и сумасшедшая) идея-фича способна подогревать энтузиазм на протяжении достаточно длительного времени.
Я даже вначале, сосредоточившись на вопросах дизайна/архитектуры, не обращал внимания на все тонкости начальной загрузки. У меня только был небольшой (менее 100 строк) загрузчик на ассемблере, к которому директивой incbin (я использовал nasm) подключался сплошной бинарник ядра с точкой входа прямо в начале. А уже этот бинарник создавался прямо из C++ исходников (использовался g++, компоновка контролировалась специальным lds-файликом, который вам наврятли поможет).
То есть мне до сих пор интересны другие стили/способы загрузки ядра и я был бы рад если бы вы потом поделились описанием схемы загрузки, которой удалось воспользоваться вам.
