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


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

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

>> Написано, что реализована поддержка немодифицированных драйверов. 100%-ность не гарантируют, но клянутся, что все протестированные работали.
>> Лично я ничего сверхестественного в этом не вижу.
>
> Удивительно. А оба проекта для L4 пока только "в процессе".

L4 - это микроядро. Ему заниматься драйверами вообще по штату не положено - это дело операционной системы. Поэтому один из упомянутых тобой двух проектов - виртуализация ОС вместе с её драйверами. (Второй, кстати, какой? DDE?)
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, взяли исходники ядра Линукса, создали в них ещё одну архитектуру, и откомпилировали ядро для этой "архитектуры".

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

А я вот вспомнил о драйверах S3 и IBM1S506, которым для работы нужна была VDM (чтобы в BIOS лазить). V86, конечно, не реальный режим, но всё равно отдельный и в микроядре не реализованный. Кто знает, каким ещё драйверам оно нужно...

>> Ага, задумаемся над этим. 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 держать в памяти всё время - на случай её перезапуска.

>>> Просто, этой версии хелпер для чтения с диска уже не нужен будет, а все нужные файлы она возьмет среди тех, что загрузчик загрузил в память. (Такой подход: грузим все, что надо, в память, а потом извлекаем файлы оттуда -- применяется в загрузчике 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. Дублирование, сам понимаешь, чревато...

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

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

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

И после этого ты говоришь "не привязано"? Вдумайся: загрузчик основной ОС грузит в память файлы виртуализируемой! В то время как она должна быть "вещью в себе".

> Дальше они грузят файлы из их образов в памяти. Параллельно, независимо друг от друга, пока полностью не инициализируются.

Параллельно? По-моему, сначала должна полностью загрузиться и инициализироваться основная ОС - ведь виртуализатор является всего лишь её прикладной программой. Как программа ОС может работать до её (ОС) полной загрузки?

>> Чем больше мы с тобой переписываемся, тем больше проблем обнаруживается в идее использовать паравиртуализацию. А одно только дизассемблирование ядра OS/2 - уже более трудоёмкое, чем создание driver execution environment.
>
> Проблем в ИДЕЕ? -- Каких это? Непонятности -- Да, обнаруживаются, не более того.

То, что обнаруживается - как его не назови - имеет следствием увеличение обьёма работы. Хотя он уже изначально был неподъёмный (дизассемблирование и перекомпилирование ядра).

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

Так, опиши пожалуйста, одновременное существование двух копий виртуализорованной OS/2. (Задумайся о неизбежности наличия при этом двух копий всех ключевых драйверов.)

> Перезапускать все процессы тоже не потребуется, а только некоторые.

Значит, нужно делать ещё и автомат, который сможет определить, какие именно можно, а какие нет. Попробуй расписать критерии, по которым он будет это делать. А потом оцени, какой процент запущенных программ попадут в отстреливаемые.

>> О, кстати - оказывается, те файлы, что начальный загрузчик в память вычитал, нужно всё время в этой памяти и держать - чтобы виртуальную ОС перезапустить можно было.
>
> Виртуальную ОС вполне можно запускать с образа ramdisk'а.

Да откуда ни запускай - файлы в памяти держать придётся.

> Никто же и не говорит, что хостовая ОС должна во всем зависеть от гостевой, и не иметь своих драйверов. Свои драйверы должны быть.

Эту тему мы с тобой совсем недавно рассматривали: если драйвер появляется в хостовой ОС, то для гостевой нужно делать виртуальный (обращающийся через маппер к основному).

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

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

Tue 26 Jun 2007 15:15 Mozilla/5.0 (OS/2; U; Warp 4.5; ru-RU; rv:1.7.12) 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.