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

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

Тема:

> > >> Вот. А конфиг - это не та самая табличка? И именно это, напоминаю, было мной названо индивидуальной поддержкой.
> > > 
> > > Маппер поддерживает _классы_ драйверов, то есть, то общее, что есть у драйверов одного типа, например, 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: http://demo.tudos.org/eng_features.html).
> 
> > Ну и, наконец, нынешние микроядра довольно похожи друг на друга, так что перенести уже сделанную систему с одного на другое - не так трудно. Микроядро K42 так вообще делали, используя L4 как образец. 
> 
> Про это я в курсе.
> 
> > (Зачем делали? Не устраивала производительность. В результате получили нечто, больше похожее на экзо-, чем на микроядро.)
> >  
> 
> Удивительно слышать. -- Так как, L4 чуть ли не самое высокопроизводительное микроядро. Хотя бы, по сравнению с QNX и Minix3. И уж, тем более, в сравнении с Mach/OS/2 PPC/MacOS X...
> 
> > > Интересно. А ссылочкой поделиться не можешь, где бы про K42 можно было бы прочитать поподробнее? Только сайт IBM?
> > 
> > IBM-овская страничка текста содержит очень мало. Но всё от её середины и до самого конца - сплошь ссылки на разные длиннющие документы (PDF и PS). Одна из ссылок ведёт на сайт университета, где K42 родилась (http://www.eecg.toronto.edu/~tornado/). Там структура такая же - мало текста и куча ссылок на документы, но одна из ссылок (под названием "Старый обзор") ведёт на страничку http://www.eecg.toronto.edu/~tornado/tornado_oldoverview.html, где текста чуть больше.
> > 
> > А самое интересное - именно в PDF-ах с PS-ами.
> > 
> 
> То же самое можно сказать про L4, основное про него -- в публикациях в PS/PDF: http://l4ka.org/publications/
> 
> > > Насчет режима 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 набора серверов? Сам ведь сказал, что современные микроядра отличаются не слишком сильно...

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