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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Юрий Пронякин
To : valerius
Subj : А вот вопрос, однако...
> Да? Что-то я не заметил. Ты вроде, про _Индивидуальную_ поддержку писал. А я -- про поддержку классов, что в общем-то, не одно и то же.

И несколько раз подчёркивал, _что_именно_ я называю индивидуальной поддержкой: информацию, к какому классу относится каждый используемый драйвер. Хочешь, чтобы я поднялся вверх по дереву и цитаты привёл?

>> И что получается? L4 - микроядро, а не операционная система, поэтому своих драйверов у него нет, и даже стандартизированных интерфейсов к драйверам нет.
>
> В рамках l4env и в рамках Kenge/Iguana -- есть свои стандартизованные интерфейсы. Только они -- не одни, а в 2-ух экземплярах. Каждый волен выбирать, какой стандарт использовать.

Вот и я об этом. Потому как сказанное тобой и означает отсутствие стандарта.

> Да, есть проблемы при переносе ОС, ориентированных на разные стандарты. Но их тоже, в принципе, решить можно.

"Мелкий" нюанс: решать их _придётся_.

>> Когда personality запущена одна, она может работать через свои драйверы. Но когда их одновременно несколько - они все должны работать через один общий набор драйверов.
>
> Желательно, но не обязательно через общий. Могут работать и через независимые наборы драйверов, лишь бы набор ресурсов, управляемых этими драйверами, разграничивался.

Я же не сказал, что все драйверы должны быть в одной ОС. Нет, они могут быть и в разных. Но у каждого ресурса может быть только один драйвер. А все вместе эти драйверы и составляют один набор.

> А также, более того, разные ОС могут использовать драйвера друг друга.

Могут конечно - через использование виртуальных драверов внутри этих ОС. Но уже даже две копии одной и той же ОС можно запустить, только если есть виртуальные версии _всех_ совместно используемых ими драйверов.

>> Но готового сейчас нет ни одного, а есть несколько конкурирующих проектов "в процессе разработки". Правда, встраивают все они исключительно линуксные драйверы, но нет же никакой гарантии, что при этом API сохраняется.
>
> Почему это API не сохраняется? Раз используются линуксовые драйвера, то и API должны использоваться линуксовые.

API на границе "драйвер-ОС" не обязан совпадать с API "ОС-приложение".

>> Дальше. Не совсем представляю, как в такой ситуации смогут безболезненно сосуществовать несколько разных оконных менеджеров (например, PM и X11). А ты представляешь?
>
> Просто. Для этого (например), в l4env/DROPS существует проект Nitpicker. (Прочитать можно об основных идеях кратко -- в моей статье, и более подробно -- на сайте DROPS Demo CD: demo.tudos.org).

При их подходе требуется, чтобы существующий оконный менеджер был переписан и стал клиентом Nitpicker. Всего лишь...

> Удивительно слышать. -- Так как, L4 чуть ли не самое высокопроизводительное микроядро. Хотя бы, по сравнению с QNX и Minix3. И уж, тем более, в сравнении с Mach/OS/2 PPC/MacOS X...

После ознакомления с тем, _как_ это сделано, становится уже не так удивительно: сервисы не просто вынесены в usel-level - они (в основном) исполняются в адресном пространстве текущего процесса, за счёт чего гораздо реже происходит переключение контекстов.

> Ну блин, IFS же тоже не в DD/OS. Я считал это подразумевающимся (и явно написал про это же немного ниже). Естественно, и драйвер диска, и IFS, и видимо, кое-что еще (менеджер томов?) должно стартовать

Вот и считай: драйвер диска вынесен из OS/2 - для OS/2 нужно написать виртуальный. Менеджер дисков (OS2DASD+OS2LVM) нужно написать виртуальный. И IFS нужно написать виртуальную - потому что иначе программы OS/2 к загрузочному диску доступа не получат - в результате даже boot.cfg/config.sys поредактировать невозможно будет.
Это только для начала. И всё ради того, чтобы один раз DDE не сделать?

>>Поэтому загрузчику придётся самому читать _всё_, несмотря на наличие драйвера.
>
> Какому загрузчику? GRUB или os2ldr?

GRUB.

> Почему все? ничего не понимаю.

Ну, если вышеперечисленные условия выполнены, то не надо.

>>> Драйверы DD/OS _могут_ перекочевать из config.sys в конфиг загрузчика. Вернее, не перекочевать, а они будут и там, и там.
>>
>> Ты видишь разницу между "дублироваться" и "и там, и там"?
>>
>
> Разницы нет. Я сказал, что драйвера будут прописаны в конфиге загрузчика (он будет грузить их в память) и в то же время, в config.sys -- ядро OS/2 увидит, например, "basedev=print01.sys /irq", и попытается прочитать его через os2boot. Os2boot, как я уже упоминал, читает из памяти то, что загрузил загрузчик, и отдает ядру. Ну, и какие проблемы это создает?

Пользователь - он иногда config.sys редактировать хочет. В твоей схеме ему придётся следить за согласованностью config.sys и boot.cfg.

> Какое указание? Все файлы после однократного их использования удаляются файл-сервером. Или, по крайней мере, они удаляются после завершения работы файл-сервера.

У тебя есть гарантии, что ОС при загрузке каждый файл читает только один раз? Вспомни - драйверы контроллеров USB грузятся по несколько экземпляров. А о том, что у базовой предполагается наличие всего своего, включая IFS, до сих пор ты не говорил.

>> Вот, и я об этом говорил. Драйверы менять надо на виртуальные. Объём работ растёт просто как снежный ком. Кто их выполнять будет? И как написать виртуальный драйвер, если у реального интерфейс не документирован?
>
> Да этих драйверов, как упоминалось, всего 6 штук. Переписать можно.

Какие 6? Виртуальную затычку нужно писать для _каждого_ драйвера, который исполняется не в этой ОС, а в соседней. (Плюс маппер внутри виртуализорованной ОС. Плюс диспетчер в базовой ОС, который будет перенаправлять запросы от виртуальных драйверов разных VM в те VM, где работают реальные драйверы.)

> Вот кернел -- самая сложная часть... Интерфейсы в основном документированы, в том же ddk или "Утекшие исходники Мерлина" никто не отменял. (Да, они "ворованные", но никто их 1 в 1 копировать не собирается, а общую идею можно использовать)

Ты забыл о драйверах с недокументированным интерфейсом. Я говорю не о том, что драйверу нужно от ОС, а о том, что драйвер предоставляет своим клиентам. Ты знаешь, как общаются между собой, например, драйверы в стеке TCP/IP или USB?

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

И я не зацикливаюсь - рассматриваем все варианты. Сейчас вот косточки этому перемываем. ТОчно так же можно взяться за подробное исследование других.

>> Секрет. Но не большой. Но в архитектуре L4, похоже, не реализуемо.
>
> Даже написанием аналогичного K42 набора серверов?

Я немного подумал и решил, что скорее всего не прав. Меня смутило то, что flexpage всегда передаётся из одного адресного пространства в другое. А для моей идеи за процессом должны числиться страницы физической памяти, не присутствующие в его адресном пространстве (в терминологии Intel).
Потом я сообразил, что их можно вставлять, например, в адресное пространство пейджера этого процесса.

Thu 28 Jun 2007 22:56 Mozilla/5.0 (OS/2; U; Warp 4.5; ru-RU; rv:1.7.12) 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.