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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : valerius
To : Юрий Пронякин
Subj : А вот вопрос, однако...
> >> Да не важно, к какому классу относится. Важно, что мапперу извне (из хостовой ОС) пришёл запрос некоему драйверу с именем ABCD, и этот драйвер - не к физическому устройству прицеплен, а абстрактный (NETBIOS, TCP/IP, IFS, да OS2DASD$ в конце-концов). Как маппер определит, к какому именно классу этот драйвер относится, если у него нет таблички с соответствием "имя - класс"?
> >
> > Да хотя бы, через конфиг, в котором задается это соответствие.
>
> Вот. А конфиг - это не та самая табличка? И именно это, напоминаю, было мной названо индивидуальной поддержкой.

Маппер поддерживает _классы_ драйверов, то есть, то общее, что есть у драйверов одного типа, например, NDIS-драйвера. Он не завязывается на особенности каждого драйвера, а абстрагируется от них. Упомянутый предполагаемый конфиг лишь подсказывает, поддержку какого класса устройств применить к данному драйверу. Сам маппер менять не надо. Просто при установке нового драйвера надо прописать его описание в конфиг.

>
> >> Написано, что реализована поддержка немодифицированных драйверов. 100%-ность не гарантируют, но клянутся, что все протестированные работали.
> >> Лично я ничего сверхестественного в этом не вижу.
> >
> > Удивительно. А оба проекта для L4 пока только "в процессе".
>
> L4 - это микроядро. Ему заниматься драйверами вообще по штату не положено - это дело операционной системы. Поэтому один из упомянутых тобой двух проектов - виртуализация ОС вместе с её драйверами. (Второй, кстати, какой? DDE?)

L4 -- микроядро, но никто не отменяет существующих наборов серверов для нее, в том числе, драйвера, подсистема которых, да, называется DDE (Device Driver Environment). Драйвера можно использовать от Linux и FreeBSD. (пока только некоторые).

> K42, наоборот, операционная система. Но минималистская, ибо предназначена не для реального использования, а для моделирования и всяческих экспериментов. Поэтому в ней только микроядро и некий достаточный набор серверов. Ни своих драйверов, ни своих приложений нет.
> Драйверы (все поголовно) используются линуксные. Для их запуска в системе имеется специальная "прослойка", предоставляющая драйверам все те же функции, которые даёт им настоящий Линукс. "We also support a Linux-kernel "internal personality". We are developing a set of libraries, that will allow Linux-kernel components such as device drivers, file systems, and network protocols to run inside the kernel or in user mode." Время будущее, потому что документ довольно старый. В следующем документе написано уже в настоящем: "Allowing K42 to use hardware drivers from Linux requires that the interface layer provides mechanisms to allow drivers to register handlers for interrupts and for interrupts to be correctly routed to those handlers. Currently this involves a simple translation between K42 and Linux interfaces. This is sufficient because Linux-kernel drivers are run within the K42 kernel. A long-term goal is to allow for the possibility of running drivers as applications outside the K42 kernel." И, наконец, есть ещё более поздний документ (не могу почему-то его сейчас найти), где о драйверах в user-mode говорится уже в настоящем. Причём упомянутое отсутствие гарантий касалось работоспособности 100% драйверов в user-mode. Работа их в kernel-mode считалась сама собой разумеющейся.
> С приложениями обстоит примерно также - своих нет, используются только линуксные, а для их запуска имеется отдельная "прослойка" (совершенно независимая от драйверной). Эта прослойка получена совершенно другим способом: как и в L4Linux, взяли исходники ядра Линукса, создали в них ещё одну архитектуру, и откомпилировали ядро для этой "архитектуры".
>

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

Интересно. А ссылочкой поделиться не можешь, где бы про K42 можно было бы прочитать поподробнее? Только сайт IBM?

> > Да, я вчера посмотрел -- в десятке мест в ядре используется функция перехода в реальный режим. Насчет драйверов -- очень старые драйвера (для OS/2 1.xx), помнится, были двухрежимными и скакали туда-сюда из защищенного в реальный и обратно. Но насколько я смотрел, в современной OS/2 соответствующий Device Helper (для переключения Real<-->Prot) уже помечен как Obsoleted и сохранен только для совместимости.
>
> А я вот вспомнил о драйверах S3 и IBM1S506, которым для работы нужна была VDM (чтобы в BIOS лазить). V86, конечно, не реальный режим, но всё равно отдельный и в микроядре не реализованный. Кто знает, каким ещё драйверам оно нужно...
>

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

> >> Ага, задумаемся над этим. DD/OS/2 с её драйверами ешё только грузится, следовательно хостовая ОС обращаться к этим драйверам ещё не может. Как тогда сама эта ОС смогла загрузить в память всё свои потроха, необходимые для запуска этой виртуализированной OS/2 (включая сам виртуализатор)?
> >
> > К DD/OS это никакого отношения не имеет. Не сама ОС смогла загрузить свои "потроха". А загрузчик, наподобие GRUB или загрузчика OS/2 PowerPC. Загрузчик грузит набор файлов ("ядро", которое на самом деле обычно не ядро, а, в случае L4 -- дополнительный загрузчик kickstart, и набор "можулей") в память и передает программе kickstart структуру с описанием загруженных модулей и прочей информации. Дальше из этих модулей kickstart грузит микроядро, sigma0 и rootserver. Rootserver потом инициализирует остальную часть системы (из состава тех же модулей, загруженных GRUB'ом, пока не загрузится драйвер диска, бутовая IFS и прочие необходимые файлы. После этого можно грузить уже с помощью IFS непосредственно с диска (а не из числа модулей, загруженных GRUB'ом))
>
> Вот. А у нас все драйверы и все IFS - в DD/OS. Поэтому начальному загрузчику придётся грузить в память не некий минимальный набор файлов, а все файлы ОС, виртуализатора и изрядную часть DD/OS. И файлы DD/OS держать в памяти всё время - на случай её перезапуска.
>

У нас _не_все_ драйверы в DD/OS. Этого никто не утверждал. Некоторые драйвера должны быть свои. Например, первый кандидат -- драйвер диска. Грузить начальному загрузчику придется не все файлы, а только тот, минимум, что необходим для чтения файлов с диска, динамической линковки и т. п. Остальное можно загрузить через драйвер диска вместе с IFS для этого диска. В памяти ничего держать не нужно. При начальной загрузке начальный набор файлов -- да, грузится в память, и оттуда отдается сервером файлов (в OS/2 PPC это делает задача bootstrap). При перезагрузке DD/OS эти же файлы грузятся уже не из памяти, а с диска через райвер этого диска и соответствующую IFS.

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

Драйверы DD/OS _могут_ перекочевать из config.sys в конфиг загрузчика. Вернее, не перекочевать, а они будут и там, и там. Загрузчик наподобие GRUB или загрузчика OS/2 PPC грузит все нужные файлы в память. Они потом передаются некоему файл-серверу, который может отдавать эти файлы по запросу другим серверам. os2boot, как я отмечал, предлагается сделать специальным, т.е., работающим с файл-сервером, отдающим файлы, уже загруженные в память. Ядро OS/2 при загрузке BASEDEV-драйверов будет работать с этой самой версией os2boot и получать таким образом файлы, которые уже заранее были загружены в память. Дальше в DD/OS запустятсясвои IFS, и она уже сможет читать непосредственно с диска, а не из памяти.

> >> А грузить их в память должен загрузчик хостовой ОС. Как ему узнать, какие именно файлы нужно грузить? Парсить CONFIG.SYS? дальше. Читать эти файлы из памяти будет загрузчик (хелпер) гостевой ОС. Как он их там найдёт? По специнформации, которую ему оставит первый загрузчик?
> >
> > Да загрузчик ОДИН -- GRUB или FreeLdr. Нет двух разных загрузчиков двух разных ОС. GRUB сразу загрузит в память все что нужно для старта обеим ОС. Далее, я предложил сделать os2boot (minifsd), который будет читать файлы не с диска, а из памяти (из числа файлов, загруженных GRUB'ом).
>
> А OS2LDR и тот код в ядре, который config.sys разбирает и нужные драйверы подчитывает - это не загрузчик? Твой os2boot - часть виртуальной системы, а не хостовой (и не виртуализатора). Но при этом хостовая система знает о его наличии и взаимодействует с ним.
>

Ну и что?

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

Загрузчик _один_. Естественно, os2ldr у DD/OS свой и делает свои внутренние дела. Хостовая ОС об этом не заботится. Но _загрузчик_ (типа GRUB) один, он грузит _в_память_ файлы обеих ОС.А остальное уже работа os2ldr и спец. версии os2boot.

> >>>> Кстати, динамический запуск/перезапуск в варианте с эмулятором тоже невозможен - в отличие от обоих альтернативных.
> >>>
> >>> Не понял? Перезапуск виртуальной машины -- почему невозможен -- как раз возможен.
> >>
> >> Да. А в этой машине - _все_ драйверы. Поэтому они все будут перезапущены. Кроме того, как я уже показывал, нельзя продолжать и выполнение запущенных в этот момент программ - их придётся закрывать (точнее - прибивать) и запускать по новой. Чем это принципиально отличается от полной перезагрузки ОС?
> >
> > В виртуальной машине -- не _все_ драйверы. неустойчивые драйверы можно изолировать в отдельной VM.
>
> Так, опиши пожалуйста, одновременное существование двух копий виртуализорованной OS/2. (Задумайся о неизбежности наличия при этом двух копий всех ключевых драйверов.)
>

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

> > Перезапускать все процессы тоже не потребуется, а только некоторые.
>
> Значит, нужно делать ещё и автомат, который сможет определить, какие именно можно, а какие нет. Попробуй расписать критерии, по которым он будет это делать. А потом оцени, какой процент запущенных программ попадут в отстреливаемые.
>
> >> О, кстати - оказывается, те файлы, что начальный загрузчик в память вычитал, нужно всё время в этой памяти и держать - чтобы виртуальную ОС перезапустить можно было.
> >
> > Виртуальную ОС вполне можно запускать с образа ramdisk'а.
>
> Да откуда ни запускай - файлы в памяти держать придётся.
>
> > Никто же и не говорит, что хостовая ОС должна во всем зависеть от гостевой, и не иметь своих драйверов. Свои драйверы должны быть.
>
> Эту тему мы с тобой совсем недавно рассматривали: если драйвер появляется в хостовой ОС, то для гостевой нужно делать виртуальный (обращающийся через маппер к основному). Ну и в чем же проблемма. Мапперы можно сделать в обеих ОС -- они будут юзать драйвера друг друга.

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

Секрет? ;-)


Wed 27 Jun 2007 08:37 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.