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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : valerius
To : dixie
Subj : Вернемся с небес на землю (злосчастный кусок)
> > Но сегментные регистры "спрятаны" микроядром. То есть, опять придется вмешиваться
> > в механизмы микроядра? Не хотелось бы вводить что-то несовместимое с общепринятыми
> > механизмами микроядра и завязываться на это..

> Да что оно - это микроядро - священная корова что-ли?

Микроядро абстрагирует ОС от специфических особенностей платформы, а то, что было предложено, означает -- открыть все потроха наружу (сегментация и т. п.). И тем самым, аннулируется весь смысл использования микроядра: переносимость.

Если все "перелопатить", то в результате мы, скорее всего, получим "сферического коня в вакууме", который будет совместим только с нашим проектом ОС, не сможет запускать других ОС и будет притянут к архитектуре IA32. А хочется еще и поддержки других платформ, приложений других ОС.

> Сделать БОЛЬШОЙ проект на "как бы прогрессивном" микроядре невозможно без его изменений, перелопачивания и, в конце концов, выкидывания нафиг ;)

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

> Я ж просил определиться - что вообще от оси останется с этим L4?

Да все практически останется, за исключением возможности использовать 16-разрядные драйвера.

Драйвера, IP стек, конфиги - все, как я понимаю, будет линуксовое.

С чего оно линуксовое?

Драйвера. -- Поддержку линуксовых надо обязательно сделать, но наличие линуксовых не отменяет необходимость своих драйверов.

IP-стек. -- Как решим. Если будут собственные силы, можно написать и свой. Но проще конечно, портировать BSD-стек (не линуксовый, а скорее всего, из OpenBSD -- вроде, его хвалят). Он и качественнее, и менее затратен по ресурсам. Опять-таки. осевый стек, конечно, хорош, и прежде всего, устройство его неизвестно хакерам. Но внутренности его неизвестны и осевикам. Но все равно, время не стоит на месте. Рано или поздно появится острая необходимость в IP v.6. А как его добавить? Повторить его (стек) или модифицировать, проблематично. Исходники закрыты. Поэтому рано или поздно все равно придется портировать BSD-стек (или реализовать самим). Так что, сильно держаться за него тоже не стоит. Опять же, кто хочет старого стека, может юзать старое ядро, это никто не запрещает.

Конфиги -- с чего это они линуксовые? config.sys, protocol.ini -- линуксовые?, .rc, .ini-тоже линуксовые?

PM тоже сразу не взлетит, в отличие от X-ов. Ну и зачем тогда этот дистибутив линукса с довеском OS/2 API? ;) Ну только, VIO32 вместо консоли линуксовой будет - удобней, не отрицаю ;)

Не сразу, никто и не говорит, что сразу. Иксы будут в Linux personality, а не в OS/2. Причем здесь дистрибутив линукса? L4Linux параллелен и независим от OS/2.

Потом, разработка ядра в ring0 -- имхо, сложнее -- трапы и прочее. А если разрабатывать на микроядре, то должно быть проще -- все компоненты в usermode, можно пользоваться обычным отладчиком. И глюки должно быть искать проще -- они локализуются внутри отдельных компонентов, между которыми зависимости легче отследить -- компонентный подход, все-таки... То есть, хотя, с одной стороны, придется снова разрабатывать драйвера (тот же IP-стек), но трудоемкость должна быть поменьше, и дело должно двигаться быстрее.

Конечно, можно реализовать ядро "как было". Все 16-бит драйвера останутся. Исходники (ворованные) есть, и их можно использовать как справочник. Но получится ядро максимум 10-летней давности. Придется сохранить все как было -- останется предел в 512 Мб, общая шаренная память на все приложения и прочее. Можно конечно, прикрутить registry, start/stop driver и прочее. Но опять же, старые проблемы остаются.

Конечно, за каким вариантом ядра будущее, решать сообществу OS/2. Каждый вариант имеет свои плюсы и минусы. Мое мнение -- "оставить все как было" -- не решение. Ну хорошо, будет готово ядро, являющееся копией ядра OS/2. Оно по-прежнему завязано на 16-бит. Вдруг 16 бит полностью искореняется производителями, есть только 32 или 64 бит. -- Начинаем писать полностью 32-разрядное ядро. Написали. И тут же накрываются перспективы платформы x86. Теперь все компы повально переходят на платформу XXX. Снова переписываем ядро... На мой взгляд, гораздо умнее и дальновиднее сразу не завязываться на особенности x86. А реализовать API на основе микроядра. Сразу не завязываемся на 16 бит. Вот написали мы API. Если надо перенести этот API на другую платформу -- просто берем микроядро для этой платформы и перекомпилируем реализацию API под эту платформу. О микроядре заботятся его разработчики, если появляется новая перспективная платформа, а микроядро популярное, (а L4 как раз, наверное, самое популярное микроядро), то разработчики микроядра 100% позаботятся о его переносе на эту платформу. То есть, для нас этот перенос будет автоматическим, нам надо будет только перекомпилировать реализацию API. А не переписывать ядро почти с нуля. Все это к тому, что не стоит жить по принципу "пока гром не грянет, мужик не перекрестится", а заранее выбрать менее затратный и правильный вариант. А вариант с микроядром как раз, на мой взгляд, и правильный.

Потом, хочется запускать приложения других систем. Odin-конечно -- хорошая вещь, но это реализация WinAPI поверх OS/2 API. Это конечно, должно добавлять гордости осевикам, что их API-"главный". Но есть и минусы. 1) чертову уйму API надо реализовать с нуля или спортировать из wine 2) API меняется с каждой версией Windows, так что надо постоянно корректировать Odin и плестись в хвосте у разработчиков windows 3) WinAPI реализовано "поверх", значит производительность должна быть ниже, за счет врапперов. Если это сделать поверх микроядра, то 1) WinAPI будет параллельным -- никаких врапперов 2) Глючные приложения и драйверы windows не уронят всю систему (т.к. userlevel) 3) Разработка сваливается на плечи разработчиков WINE и ReactOS. Нам только надо "паравиртуализовать" ReactOS, а это можно сделать при помощи проекта Afterburner (о нем я пишу в своей статье, скоро будет). L4Linux есть уже готовый. Поэтому нам даже не надо заботиться о его переносе на L4, это можно "свалить" на его разработчиков. Драйвера Linux тоже можно использовать.

В общем, плюсов много у обеих вариантов. Но вариант с микроядром на мой взгляд, и более дальновиден, и менее затратен. На данный момент в варианте с микроядром единственный минус: отпадают 16-битные драйвера, в том числе, осевый стек (хотя, 32-битный API для драйверов, возможно, можно сохранить -- это предстоит выяснить -- тогда IP-стек не отпадает).


Thu 14 Jun 2007 19:34 Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.10) Gecko/2005



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.