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


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

Именно этот вопрос я задал только позавчера. К сожалению, вопрос, видимо, попал на субботу-воскресенье, поэтому и задержка. А вообще, мейллист на L4Ka немного более медленно реагирующий. На TU Dresden побыстрее, там и ответы более оперативно появляются.

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

Да хотя бы, через конфиг, в котором задается это соответствие. Сейчас не могу ответить, так как мне самому еще пока не ответили.

> > (А как насчет K42 -- неужели, там уже реализовали 100% поддержку всех драйверов Linux?) Во любом случае, ИМХО, самим дотачивать придется.
>
> Написано, что реализована поддержка немодифицированных драйверов. 100%-ность не гарантируют, но клянутся, что все протестированные работали.
> Лично я ничего сверхестественного в этом не вижу.

Удивительно. А оба проекта для L4 пока только "в процессе".

>
> > Насколько я помню, OS/2 ядро прыгает в реальный режим только при чтении с диска драйверов BASEDEV средствами int 13h. (или я неправ? где еще?)
>
> А мне помнится, что были драйверы, которые при старте (а то и в процессе работы) к BIOS (материнки или управляемого устройства) обращались.
>

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

> > Если это так, то можно заменить в ядре хелпер для чтения с диска на хелпер, читающий файлы из их образов в памяти (т.е., все нужные файлы грузить загрузчиком в память, а потом оттуда по мере надобности их извлекать.).
>
> Ага, задумаемся над этим. DD/OS/2 с её драйверами ешё только грузится, следовательно хостовая ОС обращаться к этим драйверам ещё не может. Как тогда сама эта ОС смогла загрузить в память всё свои потроха, необходимые для запуска этой виртуализированной OS/2 (включая сам виртуализатор)?
>

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

> > Могу предложить даже заменить os2boot на спец. версию, читающую файлы из памяти, а не с диска.
>
> Вот. В памяти они как окажутся?
>

Их загрузит загрузчик, наподобие GRUB или нашего FreeLdr.

> > Просто, этой версии хелпер для чтения с диска уже не нужен будет, а все нужные файлы она возьмет среди тех, что загрузчик загрузил в память. (Такой подход: грузим все, что надо, в память, а потом извлекаем файлы оттуда -- применяется в загрузчике OS/2 PowerPC, а также, аналогично поступает GRUB).
>
> Подумай хорошенько:
> Список файлов, которые будут нужны в процессе старта OS/2 частично содержится в CONFIG.SYS, частично - зашит в загрузчик и ядро.

Просто, побольше файлов перекочуют из config.sys в конфиг загрузчика и все. Конфиг загрузчика OS/2 PPC boot.cfg видел? А ее config.sys? Просто в этом случае несколько другая логика загрузки. Могу даже прислать boot.cfg и config.sys, если интересно.

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

Да загрузчик ОДИН -- GRUB или FreeLdr. Нет двух разных загрузчиков двух разных ОС. GRUB сразу загрузит в память все что нужно для старта обеим ОС. Далее, я предложил сделать os2boot (minifsd), который будет читать файлы не с диска, а из памяти (из числа файлов, загруженных GRUB'ом). Тогда не понадобится вызывать хелпер, читающий сектора с диска, который для этого переключается в реальный режим. Ну, и надо подумать, как можно было бы исключить другие случаи переключения в реальный режим...

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

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

> Чем больше мы с тобой переписываемся, тем больше проблем обнаруживается в идее использовать паравиртуализацию. А одно только дизассемблирование ядра OS/2 - уже более трудоёмкое, чем создание driver execution environment.
>

Проблем в ИДЕЕ? -- Каких это? Непонятности -- Да, обнаруживаются, не более того.

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

В виртуальной машине -- не _все_ драйверы. неустойчивые драйверы можно изолировать в отдельной VM. Перезапускать все процессы тоже не потребуется, а только некоторые.

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

Виртуальную ОС вполне можно запускать с образа ramdisk'а. Например, минимальный Linux -- это ядро и начальный ramdisk. То есть, по крайней мере, надо загрузить эти 2 файла. Конечно, для этого нужна хотя бы файловая система и драйвер блочного устройства. Вероятно, их придется иметь непосредственно в хостовой ОС. Никто же и не говорит, что хостовая ОС должна во всем зависеть от гостевой, и не иметь своих драйверов. Свои драйверы должны быть. Другое дело -- если есть какое-то экзотическое устройство, для которого нету родного драйвера -- тогда придется заимствовать у того же линукса.

>
> > Но если драйвер упал, то его состояние все равно испорчено, так что передавать все это состояние новой копии при перезапуске не имеет смысла -- новая копия опять попадет в аварийную ситуацию, так что все равно нужно перезапускать с нуля.
>
> Для моей ОС на этот случай кое-что придумано.
>
> > А альтернвативные (2 штуки) -- это какие? DDE и случай K42?
>
> DDE - как расшифровывается? Device driver environment (execution)? Если да, то это один из вариантов. А второй - преобразование дизассемблированных драйверов в родные драйверы ОС.
>

Device Driver Environment

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

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

Tue 26 Jun 2007 08:25 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.