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

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> > Да? Что-то я не заметил. Ты вроде, про _Индивидуальную_ поддержку писал. А я -- про поддержку классов, что в общем-то, не одно и то же.
> 
> И несколько раз подчёркивал, _что_именно_ я называю индивидуальной поддержкой: информацию, к какому классу относится каждый используемый драйвер. Хочешь, чтобы я поднялся вверх по дереву и цитаты привёл?
>   
> >> И что получается? L4 - микроядро, а не операционная система, поэтому своих драйверов у него нет, и  даже стандартизированных интерфейсов к драйверам нет. 
> > 
> > В рамках l4env и в рамках Kenge/Iguana -- есть свои стандартизованные интерфейсы. Только они -- не одни, а в 2-ух экземплярах. Каждый волен выбирать, какой стандарт использовать.
> 
> Вот и я об этом. Потому как сказанное тобой и означает отсутствие стандарта.
> 
> > Да, есть проблемы при переносе ОС, ориентированных на разные стандарты. Но их тоже, в принципе, решить можно.
> 
> "Мелкий" нюанс: решать их _придётся_.
> 
> >> Когда personality запущена одна, она может работать через свои драйверы. Но когда их одновременно несколько - они все должны работать через один общий набор драйверов. 
> > 
> > Желательно, но не обязательно через общий. Могут работать и через независимые наборы драйверов, лишь бы набор ресурсов, управляемых этими драйверами, разграничивался.
> 
> Я же не сказал, что все драйверы должны быть в одной ОС. Нет, они могут быть и в разных. Но у каждого ресурса может быть только один драйвер. А все вместе эти драйверы и составляют один набор.
> 
> > А также, более того, разные ОС могут использовать драйвера друг друга.
> 
> Могут конечно - через использование виртуальных драверов внутри этих ОС. Но уже даже две копии одной и той же ОС можно запустить, только если есть виртуальные версии _всех_ совместно используемых ими драйверов.
>  
> >> Но готового сейчас нет ни одного, а есть несколько конкурирующих проектов "в процессе разработки". Правда, встраивают все они исключительно линуксные драйверы, но нет же никакой гарантии, что при этом API сохраняется.
> > 
> > Почему это API не сохраняется? Раз используются линуксовые драйвера, то и API должны использоваться линуксовые.
> 
> API на границе "драйвер-ОС" не обязан совпадать с  API "ОС-приложение".
> 
> >> Дальше. Не совсем представляю, как в такой ситуации смогут безболезненно сосуществовать несколько разных оконных менеджеров (например, PM и X11). А ты представляешь?
> > 
> > Просто. Для этого (например), в l4env/DROPS существует проект Nitpicker. (Прочитать можно об основных идеях кратко -- в моей статье, и более подробно -- на сайте DROPS Demo CD: http://demo.tudos.org/eng_features.html).
> 
> При их подходе требуется, чтобы существующий оконный менеджер был переписан и стал клиентом 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).
> Потом я сообразил, что их можно вставлять, например, в адресное пространство пейджера этого процесса.

__, _, __, _,_ _, _ \|_ / \ \|_) \| \| \|\/\| \| \ / \| \ \| \| \| \| ~ ~ ~ ~ `~' ~ ~