RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Вернемся к обсуждению Ядра системы.


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Pavel Shtemenko
To : Igor Vaskov
Subj : Вернемся к обсуждению Ядра системы.
> > > Обновилась статья
> > > core002.html
> > >
> > > Я надеюсь, что время на споры потрачено не зря. Теперь предлагаю взглянуть на дискуссию сверху и взять из нее самое ценное.
> >
> > Мда, ну какой наф L4, K42 e.t.c. Никуда нам от обычного осевого ядра не дется, иначе получится просто очередной линукс. Путей аж по пальцам одной руки можно посчитать, дизассемблировать 104a SMP и смотря туда писать свое, или тоже самое и смотря с свиснутые сорцы опять таки писать свое. Ни в один из этих вариантов L4 не впишется. После того будет полное соотвествие (по работе) со 104a SMP, да тогда можно приступать к выкидышу лишнего и добавления фич. В принципе часть можно сразу херить при переписывании, например гибернат, он уже точно устарел на все 100% процентов.
> Тоже путь. Во всяком случае видно начало и конец процесса. Но и камней подводных дофигищи. Дизассеблированный код не факт, что соберется обратно. И не факт, что в нем можно будет разобраться учитывая объем.

А зачем его собирать обратно? Надо идти по началу загрузки, посматривая в оба и просто писать. И лично я совсем не уверен что это лучше писать на C

> А по поводу никуда не деться от старого ядра - вопрос спорный. Никто не мешает заменить центральное ядро на микроядро и сделать соответствующую обвязку API. Только надо быть реалистами и не разивать рта на кусок, который ну никак не проглотить. Соответственно реалистичный путь предполагает наличие этапов. Таким этапом должно стать ядро с старой Осевой моделью распределения памяти, поддерживающее 16-и битный код и те же самые драйвера точно также, как сейчас все это поддреживает OS/2. Но построенное на архитектуре микроядра с возможностью гибкого управления драйверами, с возможностью развития и т.д.

Сдается мне что приспособление микроядер для загрузки будет скажем так весьма затруднительно. Напомню, что у ядра есть несколько стадий загрузки, не буду говорить что там все правильно, но вот для IFS это весьма правильно, Хотя получается и несколько запутано.

> Следующий этап - перевод на полные 32 бита всех драйверов и реализация решения для 16-и битного кода (мне ближе он-лайн эмулятор).
> И только потом отказ от 16-и битных режимов (перево в эмуляцию), смена модели распределения памяти и прочие сверхреволюционные вещи.
>

Великий карриер, ну чего вы так цепляетесь к 16 бит коду? писать на ем не сложнее, то что там доступно тока 64к это миф созданный явно M$ чтоб оправдать свои ошибки, скорость таже что и в 32. Кроме того все драйвера написаны на 16 бит и пока не видится толпы желающих переводить их в 32. Если имеется ввиду дальний прицел перевода на 64 бит, то уверяю, с тем 32 бит кодом, что имеется (или будет имется) будет не меньше проблем чем с 16

Thu 26 Jul 2007 02:00 Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.5) Gecko/20041



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.