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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : valerius
To : Юрий Пронякин
Subj : А вот вопрос, однако...
> >> Вот. А конфиг - это не та самая табличка? И именно это, напоминаю, было мной названо индивидуальной поддержкой.
> >
> > Маппер поддерживает _классы_ драйверов, то есть, то общее, что есть у драйверов одного типа, например, NDIS-драйвера. Он не завязывается на особенности каждого драйвера, а абстрагируется от них. Упомянутый предполагаемый конфиг лишь подсказывает, поддержку какого класса устройств применить к данному драйверу.
>
> Как интересно. Именно это я и писал тут раза четыре, наверное. Не читал?
>

Да? Что-то я не заметил. Ты вроде, про _Индивидуальную_ поддержку писал. А я -- про поддержку классов, что в общем-то, не одно и то же.

> > Только, в отличие от K42, и Minix3, L4 -- это база для множества ОС, userlevel службы существуют в L4 не в единственном экземпляре. То что ОС на базе L4 много, позволяет запускать эти ОС одновременно. То есть, это позволяет кроме OS/2 personality иметь также personalities не только для Linux, но и, например, для Minix, Darwin/MacOSX (в процессе разработки проект L4/Darwin по переносу Darwin на L4Ka::Pistachio)
>
> И что получается? L4 - микроядро, а не операционная система, поэтому своих драйверов у него нет, и даже стандартизированных интерфейсов к драйверам нет.

В рамках l4env и в рамках Kenge/Iguana -- есть свои стандартизованные интерфейсы. Только они -- не одни, а в 2-ух экземплярах. Каждый волен выбирать, какой стандарт использовать. Да, есть проблемы при переносе ОС, ориентированных на разные стандарты. Но их тоже, в принципе, решить можно. Никто не мешает, например, поверх l4env реализовать эмуляцию интерфейсов Iguana...

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

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

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

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

Хотя скорее всего, что так оно и есть, но вот Дарвину, расчитанному на несколько другие драйверы, от этого не поплохеет?
>

Не знаю. Если разграничивать ресурсы между разными ОС, то поплохеть не должно. К сожалению, про Darwin рассуждать не могу, бо сильно глубоко не копал в его сторону. Каким-то образом, им (команде ERTOS/NICTA) удалось запускать Wombat (паравиртуализованный Linux) и L4/Darwin одновременно, и даже проводятся эксперименты по их взаимодействию.

> Дальше. Не совсем представляю, как в такой ситуации смогут безболезненно сосуществовать несколько разных оконных менеджеров (например, PM и X11). А ты представляешь?
>

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

> Ну и, наконец, нынешние микроядра довольно похожи друг на друга, так что перенести уже сделанную систему с одного на другое - не так трудно. Микроядро K42 так вообще делали, используя L4 как образец.

Про это я в курсе.

> (Зачем делали? Не устраивала производительность. В результате получили нечто, больше похожее на экзо-, чем на микроядро.)
>

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

> > Интересно. А ссылочкой поделиться не можешь, где бы про K42 можно было бы прочитать поподробнее? Только сайт IBM?
>
> IBM-овская страничка текста содержит очень мало. Но всё от её середины и до самого конца - сплошь ссылки на разные длиннющие документы (PDF и PS). Одна из ссылок ведёт на сайт университета, где K42 родилась (www.eecg.toronto.edu). Там структура такая же - мало текста и куча ссылок на документы, но одна из ссылок (под названием "Старый обзор") ведёт на страничку tornado_oldoverview.html, где текста чуть больше.
>
> А самое интересное - именно в PDF-ах с PS-ами.
>

То же самое можно сказать про L4, основное про него -- в публикациях в PS/PDF: l4ka.org

> > Насчет режима V86 -- в современных ядрах Fiasco и Pistachio этого режима нет, но его поддержка была в оригинальном микроядре L4/x86, написанном на ассемблере, и его, теоретически, можно снова добавить и в новые ядра.
>
> Теоретически, можно. Но я сильно сомневаюсь, что кто-то станет это делать. В связи с абсолютной непортируемостью. По этой же причине, наверняка, и выбросили.
>

Если сильно будет надо, можно будет этим заняться ;) -- Посмотреть─. как это было сделано в L4/x86 и по аналогии. Или, как мне один товарищ из листа рассылки предложил -- сделать architecture-specific сисколл, который бы исполнял какой-то код в режиме V86, и возвращал бы после этого управление.

> >> Вот. А у нас все драйверы и все IFS - в DD/OS. Поэтому начальному загрузчику придётся грузить в память не некий минимальный набор файлов, а все файлы ОС, виртуализатора и изрядную часть DD/OS. И файлы DD/OS держать в памяти всё время - на случай её перезапуска.
> >
> > У нас _не_все_ драйверы в DD/OS. Этого никто не утверждал. Некоторые драйвера должны быть свои. Например, первый кандидат -- драйвер диска.
>
> Я тебя уже один раз спрашивал: как ты собираешься запустить на исполнение OS/2 в которой нет драйвера дисков? И что толку от вынесенного драйвера диска, если IFS - в DD/OS и стартует, соответственно, только после полного старта базовой ОС и виртуализатора?

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

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

Какому загрузчику? GRUB или os2ldr? Почему все? ничего не понимаю.

> > Грузить начальному загрузчику придется не все файлы, а только тот, минимум, что необходим для чтения файлов с диска, динамической линковки и т. п. Остальное можно загрузить через драйвер диска вместе с IFS для этого диска.
>
> Да-да-да. А IFS - в OS/2.
>

Драйвер диска, IFS для этого диска, менеджер томов и возможно, что-то еще, должно быть отдельно от DD/OS. -- Для возможности перезагрузки VM. При этом VM будет загружаться с той ФС, для которой IFS. Все файлы, в отличие от начальной загрузки, при перезагрузке грузятся не из памяти, а через IFS/драйвер диска/менеджер томов/что-то еще.

> > В памяти ничего держать не нужно. При начальной загрузке начальный набор файлов -- да, грузится в память, и оттуда отдается сервером файлов (в OS/2 PPC это делает задача bootstrap). При перезагрузке DD/OS эти же файлы грузятся уже не из памяти, а с диска через райвер этого диска и соответствующую IFS.
>
> А, я понял - ты собираешься загрузочный раздел под ext3 держать :-)
>

Почему обязательно ext2 -- будет любая ФС, поддерживаемая PN-сервисами. А DD/OS может грузиться с минимального образа ramdisk'а (а не обязательно с отдельного партишена), отформатированного, например, в HPFS, а лежать этот образ может на любой ФС, поддержка которой есть в PN-сервисах.

> Так ведь линуксные драйверы к L4 тоже пока толком не прикручены. Максимум - вместе с самим Линуксом. А две DD/OS, как я уже показывал, сосуществовать практически не могут.

Пока не совсем прикручены. Но можно при желании прикрутить. Или (предпочтительный вариант) написать свои. (Наличие линуксных их не отменяет).

> >> Не интересно. Потому что это загрузка просто новой ОС. А в случае, когда в ней имеется виртуализированная DD/OS/2 драйверы не могут перекочевать из config.sys в boot.cfg - потому что config.sys используется ядром OS/2 в процессе её загрузки. Убери из него упоминание об IBM1S506 - и что с того, что он где-то там в памяти есть? Ядро OS/2 же о нём не подозревает.
> >> Поэтому нужно либо дублировать файлы (и в config.sys, и boot.cfg), либо начальному загрузчику парсить config.sys. Дублирование, сам понимаешь, чревато...
> >
> > Драйверы DD/OS _могут_ перекочевать из config.sys в конфиг загрузчика. Вернее, не перекочевать, а они будут и там, и там.
>
> Ты видишь разницу между "дублироваться" и "и там, и там"?
>

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

> >> А OS2LDR и тот код в ядре, который config.sys разбирает и нужные драйверы подчитывает - это не загрузчик? Твой os2boot - часть виртуальной системы, а не хостовой (и не виртуализатора). Но при этом хостовая система знает о его наличии и взаимодействует с ним.
> >
> > Ну и что?
>
> Да так, мелочи всякие из всех щелей прут. Вот, например, те файлы, которые начальный загрузчик в память вычитал. В нормальной системе их после старта сбрасывают, и память используют для полезных целей.

Да, именно. Прочитали и больше они не нужны. Память используется для других целей.

> А в твоей модели некоторые файлы сбросить можно, а некоторые необходимо оставить.

Да все они сбрасываются, ничего оставлять не нужно.

> Ну и где должно быть указание "кого куда"?

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

> В памяти, возле файлов. А до того - в boot.cfg. Который пользователь редактирует. Со всеми выплывающими нюансами (вспомни, например, конфиг маппера, который пользователю тоже править надо) система постепенно получается "не для средних умов", не находишь?
>

Не нахожу. А OS/2 или DOS были для средних умов? Продвинутые пользователи сами редактируют. А за непродвинутых это сделает инсталлятор. Не вижу проблем.

> >> Так, опиши пожалуйста, одновременное существование двух копий виртуализорованной OS/2. (Задумайся о неизбежности наличия при этом двух копий всех ключевых драйверов.)
> >
> > Каждую VM с DD/OS можно урезать до минимума, так чтобы она занимала, например, 4 Мб в памяти. Лишние драйвера можно удалить. Драйвера типа screen01.sys можно заменить на версии, работающие с виртуальными (а не реальными) девайсами.
>
> Вот, и я об этом говорил. Драйверы менять надо на виртуальные. Объём работ растёт просто как снежный ком. Кто их выполнять будет? И как написать виртуальный драйвер, если у реального интерфейс не документирован?

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

>
> А теперь оценим альтернативный вариант: создать в базовой ОС набор функций, который предоставляет драйверам OS/2 (то самое DDE). Один раз и для всех. Проще ведь?

Не уверен, что проще.

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

И так можно. Я ж не зацикливаюсь на каком-то одном варианте -- надо подумать, как лучше...

> > В общем, особых проблем я не вижу. И это, между прочим, уже работает реально с L4Linux.
>
> У нас ситуация несколько отличается от линуксной.
>
> >> Кто сказал "не сбросив"? Если делать традиционными способами, то перезапуск драйвера по причине его падения почти ничем не отличается от последовательности "остановить драйвер; запустить драйвер". И приложения, от этого драйвера зависящие, пострадать могут. Но перезапускаться-то будет только один этот драйвер, а не все оптом. Поэтому те, кто с упавшим драйвером дела не имеют, вообще ничего не заметят. (К тому же у меня и кое-что нетрадиционное придумано, позволяющее избежать сброса состояния.)
> >
> > Секрет? ;-)
>
> Секрет. Но не большой. Но в архитектуре L4, похоже, не реализуемо.

Даже написанием аналогичного K42 набора серверов? Сам ведь сказал, что современные микроядра отличаются не слишком сильно...

Thu 28 Jun 2007 10:38 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.