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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : valerius
To : Юрий Пронякин
Subj : А вот вопрос, однако...
> >> Вспомни, что я называл "индивидуальной поддержкой". - Про каждый используемый в DD/OS драйвер маппер должен знать, к какому классу этот драйвер относится. Если пользователь захочет использовать какой-то драйвер, имя которого мапперу неизвестно - его ждёт облом.
> >
> > По моему, маппер не обязан знать каждый драйвер "в лицо". Он (маппер) может, например, посмотреть список всех девайсов компьютера (по алгоритму, аналогичному scanpci или SysInfo), спросить у ОС, какой драйвер на этот девайс "сел" и определить, таким образом, к какому классу этот драйвер относится (раз это IDE-устройство, а драйвер на него сел, то драйвер тоже соответствующего класса)
>
> Хрен на званом обеде у редьки.
> В предлагаемом тобой случае маппер должен знать, к какому классу относится каждое устройство. А устройств - их гораздо больше, чем драйверов (один драйвер может поддерживать кучу устройств). И новые устройства появляются граздо чаще, чем новые драйверы. И как быть с устройствами, не обнаруживаемыми через scanpci?
>

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

> К тому же у нас не только драйверы устройств. IFS, например, как опознавать будем?
>

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

> >> Да, эту проблему можно решить при помощи конфигов маппера, но есть же и другие проблемы, более занятные.
> >> Например, как загрузить саму OS/2? Она сначала рассчитана на то, что стартует в реальном режиме процессора.
> >>
> > Как мне сказали про Линух, все то, что относится к реальному режиму, просто вырезается при портировании -- оно не нужно. Эту работу выполняет само микроядро (загрузка ОС или ACPI wakeup/suspend)
>
> Это я помню. Но OS/2 в процессе старта прыгает туда-сюда, ты же это помнишь.
>

Насколько я помню, OS/2 ядро прыгает в реальный режим только при чтении с диска драйверов BASEDEV средствами int 13h. (или я неправ? где еще?) Если это так, то можно заменить в ядре хелпер для чтения с диска на хелпер, читающий файлы из их образов в памяти (т.е., все нужные файлы грузить загрузчиком в память, а потом оттуда по мере надобности их извлекать.). Могу предложить даже заменить os2boot на спец. версию, читающую файлы из памяти, а не с диска. Просто, этой версии хелпер для чтения с диска уже не нужен будет, а все нужные файлы она возьмет среди тех, что загрузчик загрузил в память. (Такой подход: грузим все, что надо, в память, а потом извлекаем файлы оттуда -- применяется в загрузчике OS/2 PowerPC, а также, аналогично поступает GRUB).

> >> Потом она грузит свои драйверы, которые тут же лезут к портам управляемых ими устройств. Но ведь у хостовой ОС уже могут быть загружены собственные драйверы этих же устройств!
> >
> > Конфликтов быть не должно. То есть, если в DD/OS какой-то драйвер садится на конкретный девайс, то хостовая ОС должна просто работать с этим драйвером через маппер. Если же хостовая ОС сама садится на девайс, то этот девайс скрывается от DD/OS -- пересекаться разные ОС не должны. Это достигается спец. настройкой хостовой ОС и гостевой ОС.
>
> Вот я и пытаюсь представить, как это можно так "спецнастроить" OS/2, чтобы она смогла загрузиться и корректно работать без какого-либо жизненно важного драйвера.
>

Ну, неотключаемых драйверов в OS/2 всего 4: screen01.sys, clock01.sys, resource.sys и ibmkbd.sys. так, что нужно заменить только 3 из них (кроме resource.sys).

> >> Догадываешься, чем это грозит? А без, скажем, screen01.sys OS/2 разве ж загрузится?
> >
> > Да, screen01.sys в OS/2 вроде, не отключить... Хотя, можно что-нибудь и придумать, например, подменить screen01.sys на версию, которая управляет не реальным, а виртуальным экраном. (исходники screen01.sys есть в тулките -- можно модифицировать)
>
> Вот-вот. Для каждого такого драйвера придётся писать виртуальный заменитель. И по мере реализации родных драйверов для новой ОС (хостовой), придётся писать заменители для всех драйверов OS/2. Представляешь, на сколько увеличивается общий обьём работы?

Не для каждого, а всего для трех. Остальные, если надо, можно просто закомментировать в конфиге.

> И всё это вместо того, чтобы один раз сделать в хостовой ОС эмулятор драйверного API OS/2. Нет, не даром в K42 пошли именно по этому пути.

Эмулятор тоже можно сделать. Только ИМХО, это труднее. Я же не говорю, что все должно работать через линуксовые драйвера. Например, абстрактные драйвера, типа resource,sys или pmdd.sys не имеют аналогов в других ОС, и их все равно, придется писать самим.

> А поддержку 16-разрядных сегментов в любом из этих вариантов делать придётся.

Никто ничего против и не говорит.

> Кстати, динамический запуск/перезапуск в варианте с эмулятором тоже невозможен - в отличие от обоих альтернативных.

Не понял? Перезапуск виртуальной машины -- почему невозможен -- как раз возможен. Но если драйвер упал, то его состояние все равно испорчено, так что передавать все это состояние новой копии при перезапуске не имеет смысла -- новая копия опять попадет в аварийную ситуацию, так что все равно нужно перезапускать с нуля. А альтернвативные (2 штуки) -- это какие? DDE и случай K42? И почему в этом случае перезапуск возможен? -- непонятно.

Mon 25 Jun 2007 19:26 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.