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

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> >> Вспомни, что я называл "индивидуальной поддержкой". - Про каждый используемый в DD/OS драйвер маппер должен знать, к какому классу этот драйвер относится. Если пользователь захочет использовать какой-то драйвер, имя которого мапперу неизвестно - его ждёт облом.
> > 
> > По моему, маппер не обязан знать каждый драйвер "в лицо". Он (маппер) может, например, посмотреть список всех девайсов компьютера (по алгоритму, аналогичному scanpci или SysInfo), спросить у ОС, какой драйвер на этот девайс "сел" и определить, таким образом, к какому классу этот драйвер относится (раз это IDE-устройство, а драйвер на него сел, то драйвер тоже соответствующего класса)
> 
> Хрен на званом обеде у редьки.
> В предлагаемом тобой случае маппер должен знать, к какому классу относится каждое устройство. А устройств - их гораздо больше, чем драйверов (один драйвер может поддерживать кучу устройств). И новые устройства появляются граздо чаще, чем новые драйверы. И как быть с устройствами, не обнаруживаемыми через scanpci?
> 
> К тому же у нас не только драйверы устройств. IFS, например, как опознавать будем?
> 
> >> Да, эту проблему можно решить при помощи конфигов маппера, но есть же и другие проблемы, более занятные.
> >> Например, как загрузить саму OS/2? Она сначала рассчитана на то, что стартует в реальном режиме процессора.
> >>
> > Как мне сказали про Линух, все то, что относится к реальному режиму, просто вырезается при портировании -- оно не нужно. Эту работу выполняет само микроядро (загрузка ОС или ACPI wakeup/suspend)
> 
> Это я помню. Но OS/2 в процессе старта прыгает туда-сюда, ты же это помнишь.
>  
> >> Потом она грузит свои драйверы, которые тут же лезут к портам управляемых ими устройств. Но ведь у хостовой ОС уже могут быть загружены собственные драйверы этих же устройств! 
> > 
> > Конфликтов быть не должно. То есть, если в DD/OS какой-то драйвер садится на конкретный девайс, то хостовая ОС должна просто работать с этим драйвером через маппер. Если же хостовая ОС сама садится на девайс, то этот девайс скрывается от DD/OS -- пересекаться разные ОС не должны. Это достигается спец. настройкой хостовой ОС и гостевой ОС.
> 
> Вот я и пытаюсь представить, как это можно так "спецнастроить" OS/2, чтобы она смогла загрузиться и корректно работать без какого-либо жизненно важного драйвера.
> 
> >> Догадываешься, чем это грозит? А без, скажем, screen01.sys OS/2 разве ж загрузится?
> > 
> > Да, screen01.sys в OS/2 вроде, не отключить... Хотя, можно что-нибудь и придумать, например, подменить screen01.sys на версию, которая управляет не реальным, а виртуальным экраном. (исходники screen01.sys есть в тулките -- можно модифицировать)
> 
> Вот-вот. Для каждого такого драйвера придётся писать виртуальный заменитель. И по мере реализации родных драйверов для новой ОС (хостовой), придётся писать заменители для всех драйверов OS/2. Представляешь, на сколько увеличивается общий обьём работы?
> И всё это вместо того, чтобы один раз сделать в хостовой ОС эмулятор драйверного API OS/2. Нет, не даром в K42 пошли именно по этому пути. А поддержку 16-разрядных сегментов в любом из этих вариантов делать придётся.
> Кстати, динамический запуск/перезапуск в варианте с эмулятором тоже невозможен - в отличие от обоих альтернативных.

_, __, _, __, /_\ \|_) /_\ \|_) \| \| \| \| \| \| \ ~ ~ ~ ~ ~ ~ ~