Операционно-независимый C

[Maslov]

Ed_Em в сообщении #304915 писал(а):

в qemu есть еще один плюс: образы его дисков можно подмонтировать через mount -o loop ..., а вот образы VirtualBox - нельзя

Может быть, это и полезно в некоторых случаях, но мне как-то общих папок обычно хватало для обмена.

Ed_Em в сообщении #304915 писал(а):

И общаться с родительской системой в нем можно только через эмуляцию сети.

А в QEMU как?

[Ed_Em]

Я имел в виду обмен файлами между родительской системой и подмонтированным образом эмулированной.

[Circiter]

2kuraga
А ваши цели написания ОС ограничиваются лишь проработкой вопросов инициализации/загрузки или же какие-нибудь другие концепции хотите обкатать?

Я в своем недоделанном проекте proto_axis, например, преследовал четыре идеи, во-первых, $\mu$-ядро должно было содержать только самое необходимое, IPC/синхронизация/нити/etc. Даже страничный менеджер памяти должен был работать отдельно от ядра, не говоря уже о драйверах/файловой системе/и т.д.

Во-вторых, IPC должна была быть клиент-серверной с элементами объектной-ориентированности, пусть даже за счет снижения производительности;

В-третьих, ядро я писал на C++ (умные дядьки работающие над микроядрами L4, e.g. fiasco, доказали, что быстрые ядра все-таки можно писать на языках высокого уровня).

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

Этот метод, вместе с некоторыми хитрыми алгоритмами управления свопом, должен был позволить достичь высокой производительности (за счет локальности) и надежности (за счет сохранения "мелкозернистой" модульности) системы. К примеру, в предварительных испытаниях, прототип оказался устойчивым к fork-бомбам и прочим напастям.

К сожалению, проект был заброшен, и когда я к нему вернусь, неизвестно...

В общем, а вы не хотели-бы какую-нибудь экзотику реализовать в вашей ОС, например отказаться от файловой системы, оконного интерфейса или ещё какую-нибудь "глупость" совершить?

Это я к тому, что какая-нибудь интересная (пусть и сумасшедшая) идея-фича способна подогревать энтузиазм на протяжении достаточно длительного времени.

Я даже вначале, сосредоточившись на вопросах дизайна/архитектуры, не обращал внимания на все тонкости начальной загрузки. У меня только был небольшой (менее 100 строк) загрузчик на ассемблере, к которому директивой incbin (я использовал nasm) подключался сплошной бинарник ядра с точкой входа прямо в начале. А уже этот бинарник создавался прямо из C++ исходников (использовался g++, компоновка контролировалась специальным lds-файликом, который вам наврятли поможет).

То есть мне до сих пор интересны другие стили/способы загрузки ядра и я был бы рад если бы вы потом поделились описанием схемы загрузки, которой удалось воспользоваться вам.

[Ed_Em]

Цитата:

То есть мне до сих пор интересны другие стили/способы загрузки ядра и я был бы рад если бы вы потом поделились описанием схемы загрузки, которой удалось воспользоваться вам.

А как вы относитесь к идее включения микроядра в BIOS? Тогда можно получить минимальную систему сразу после включения компьютера. Ну а она уже будет подгружать с жестких дисков остальные модули, монтировать файловые системы, и т.п. Если в BIOS хватит места, туда можно даже базовые coreutils загнать :)

[Circiter]

2Ed_Em

Цитата:

А как вы относитесь к идее включения микроядра в BIOS? Тогда можно получить минимальную систему сразу после включения компьютера.

Очень интересно. Кажется нечто подобное используется в концепции тонких клиентов. Но все-равно хорошая идея. Я так понимаю, такие эксперименты вполне доступны, достаточно перепрошить BIOS, добавив свой код; хотя детали мне не ясны.

Вообще, помоему, что ни придумай, все уже где-нибудь да реализовано. :)

[kuraga]

Circiter в сообщении #305432 писал(а):

А уже этот бинарник создавался прямо из C++ исходников (использовался g++, компоновка контролировалась специальным lds-файликом, который вам наврятли поможет).

А все-таки, как компилировалось?

[Ed_Em]

Цитата:

А все-таки, как компилировалось?

Думаю, обычным g++ :)
Забудьте про ассемблер, если вы пишете под популярную архитектуру - все уже до вас сделано, вам только готовые библиотеки подключить надо.
Вот если вы на какую-нибудь новую архитектуру захотите писать - придется, конечно, с ассемблером повозиться. А для популярных: х86, MIPS, ARM, SPARC и иже с ними все давно готово.