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 - микроядро, а не операционная система, поэтому своих драйверов у него нет, и  даже стандартизированных интерфейсов к драйверам нет. Когда personality запущена одна, она может работать через свои драйверы. Но когда их одновременно несколько - они все должны работать через один общий набор драйверов. Но готового сейчас нет ни одного, а есть несколько конкурирующих проектов "в процессе разработки". Правда, встраивают все они исключительно линуксные драйверы, но нет же никакой гарантии, что при этом API сохраняется. Хотя скорее всего, что так оно и есть, но вот Дарвину, расчитанному на несколько другие драйверы, от этого не поплохеет?
> 
> Дальше. Не совсем представляю, как в такой ситуации смогут безболезненно сосуществовать несколько разных оконных менеджеров (например, PM и X11). А ты представляешь?
> 
> Ну и, наконец, нынешние микроядра довольно похожи друг на друга, так что перенести уже сделанную систему с одного на другое - не так трудно. Микроядро K42 так вообще делали, используя L4 как образец. (Зачем делали? Не устраивала производительность. В результате получили нечто, больше похожее на экзо-, чем на микроядро.)
>  
> > Интересно. А ссылочкой поделиться не можешь, где бы про K42 можно было бы прочитать поподробнее? Только сайт IBM?
> 
> IBM-овская страничка текста содержит очень мало. Но всё от её середины и до самого конца - сплошь ссылки на разные длиннющие документы (PDF и PS). Одна из ссылок ведёт на сайт университета, где K42 родилась (http://www.eecg.toronto.edu/~tornado/). Там структура такая же - мало текста и куча ссылок на документы, но одна из ссылок (под названием "Старый обзор") ведёт на страничку http://www.eecg.toronto.edu/~tornado/tornado_oldoverview.html, где текста чуть больше.
> 
> А самое интересное - именно в PDF-ах с PS-ами.
> 
> > Насчет режима V86 -- в современных ядрах Fiasco и Pistachio этого режима нет, но его поддержка была в оригинальном микроядре L4/x86, написанном на ассемблере, и его, теоретически, можно снова добавить и в новые ядра.
> 
> Теоретически, можно. Но я сильно сомневаюсь, что кто-то станет это делать. В связи с абсолютной непортируемостью. По этой же причине, наверняка, и выбросили.
>     
> >> Вот. А у нас все драйверы и все IFS - в DD/OS. Поэтому начальному загрузчику придётся грузить в память не некий минимальный набор файлов, а все файлы ОС, виртуализатора и изрядную часть DD/OS. И файлы DD/OS держать в памяти всё время - на случай её перезапуска.
> > 
> > У нас _не_все_ драйверы в DD/OS. Этого никто не утверждал. Некоторые драйвера должны быть свои. Например, первый кандидат -- драйвер диска.
> 
> Я тебя уже один раз спрашивал: как ты собираешься запустить на исполнение OS/2 в которой нет драйвера дисков? И что толку от вынесенного драйвера диска, если IFS - в DD/OS и стартует, соответственно, только после полного старта базовой ОС и виртуализатора? Поэтому загрузчику придётся самому читать _всё_, несмотря на наличие драйвера.
> 
> > Грузить начальному загрузчику придется не все файлы, а только тот, минимум, что необходим для чтения файлов с диска, динамической линковки и т. п. Остальное можно загрузить через драйвер диска вместе с IFS для этого диска.
> 
> Да-да-да. А IFS - в OS/2.
> 
> > В памяти ничего держать не нужно. При начальной загрузке начальный набор файлов -- да, грузится в память, и оттуда отдается сервером файлов (в OS/2 PPC это делает задача bootstrap). При перезагрузке DD/OS эти же файлы грузятся уже не из памяти, а с диска через райвер этого диска и соответствующую IFS.
> 
> А, я понял - ты собираешься загрузочный раздел под ext3 держать :-)  Так ведь линуксные драйверы к 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 в конфиг загрузчика. Вернее, не перекочевать, а они будут и там, и там.
> 
> Ты видишь разницу между "дублироваться" и "и там, и там"?
> 
> >> А OS2LDR и тот код в ядре, который config.sys разбирает и нужные драйверы подчитывает - это не загрузчик? Твой os2boot - часть виртуальной системы, а не хостовой (и не виртуализатора). Но при этом хостовая система знает о его наличии и взаимодействует с ним.
> > 
> > Ну и что?
> 
> Да так, мелочи всякие из всех щелей прут. Вот, например, те файлы, которые начальный загрузчик в память вычитал. В нормальной системе их после старта сбрасывают, и память используют для полезных целей. А в твоей модели некоторые файлы сбросить можно, а некоторые необходимо оставить. Ну и где должно быть указание "кого куда"? В памяти, возле файлов. А до того - в boot.cfg. Который пользователь редактирует. Со всеми выплывающими нюансами (вспомни, например, конфиг маппера, который пользователю тоже править надо) система постепенно получается "не для средних умов", не находишь?
>  
> >> Так, опиши пожалуйста, одновременное существование двух копий виртуализорованной OS/2. (Задумайся о неизбежности наличия при этом двух копий всех ключевых драйверов.)
> > 
> > Каждую VM с DD/OS можно урезать до минимума, так чтобы она занимала, например, 4 Мб в памяти. Лишние драйвера можно удалить. Драйвера типа screen01.sys можно заменить на версии, работающие с виртуальными (а не реальными) девайсами.
> 
> Вот, и я об этом говорил. Драйверы менять надо на виртуальные. Объём работ растёт просто как снежный ком. Кто их выполнять будет? И как написать виртуальный драйвер, если у реального интерфейс не документирован?
> 
> А теперь оценим альтернативный вариант: создать в базовой ОС набор функций, который предоставляет драйверам OS/2 (то самое DDE). Один раз и для всех. Проще ведь?
> Дальше: для твоего варианта всё равно нужен ассемблерный текст ядра и драйверов устройств. Но если предположить, что мы это раздобыли, то что мешает просто выбросить из ядра всё, что касается загрузки драйверов, и вместо этого вставить туда интерфейс (маппер) к драйверам базовой ОС?
> 
> > В общем, особых проблем я не вижу. И это, между прочим, уже работает реально с L4Linux.
> 
> У нас ситуация несколько отличается от линуксной.
> 
> >> Кто сказал "не сбросив"? Если делать традиционными способами, то перезапуск драйвера по причине его падения почти ничем не отличается от последовательности "остановить драйвер; запустить драйвер". И приложения, от этого драйвера зависящие, пострадать могут. Но перезапускаться-то будет только один этот драйвер, а не все оптом. Поэтому те, кто с упавшим драйвером дела не имеют, вообще ничего не заметят. (К тому же у меня и кое-что нетрадиционное придумано, позволяющее избежать сброса состояния.)
> > 
> > Секрет? ;-)
> 
> Секрет. Но не большой. Но в архитектуре L4, похоже, не реализуемо.

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