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

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

Тема:

> > > Что еще ценного мне подсказали в списке рассылки:
> > 
> > Я читал всё это - ты же сам ссылки давал.
> > 
> > > 5) Содержит ли приложение-mapper внутри DD/OS (Device Driver OS) специфическую поддержку для каждого драйвера в отдельности?
> > > Ответ был следующий: Маппер содержит поддержку не отдельных драйверов устройств, а _классов_ устройств. То есть, есть поддержка для класса SCSI-устройств, класса IDE-устройств, класса LAN-адаптеров и т. д. Для каждого класса содержится поддержка некоторых общих для всего класса функций -- "наименьший общий знаменатель" этих функций. То есть, если добавляем новое устройство, то поддержка дляы него содержится внутри поддержки соответствующего класса устройств.
> > 
> 
> > Вспомни, что я называл "индивидуальной поддержкой". - Про каждый используемый в DD/OS драйвер маппер должен знать, к какому классу этот драйвер относится. Если пользователь захочет использовать какой-то драйвер, имя которого мапперу неизвестно - его ждёт облом.
> 
> По моему, маппер не обязан знать каждый драйвер "в лицо". Он (маппер) может, например, посмотреть список всех девайсов компьютера (по алгоритму, аналогичному scanpci или SysInfo), спросить у ОС, какой драйвер на этот девайс "сел" и определить, таким образом, к какому классу этот драйвер относится (раз это IDE-устройство, а драйвер на него сел, то драйвер тоже соответствующего класса)
> 
> > Да, эту проблему можно решить при помощи конфигов маппера, но есть же и другие проблемы, более занятные.
> > Например, как загрузить саму OS/2? Она сначала рассчитана на то, что стартует в реальном режиме процессора.
> 
> Как мне сказали про Линух, все то, что относится к реальному режиму, просто вырезается при портировании -- оно не нужно. Эту работу выполняет само микроядро (загрузка ОС или ACPI wakeup/suspend)
> 
> > Потом она грузит свои драйверы, которые тут же лезут к портам управляемых ими устройств. Но ведь у хостовой ОС уже могут быть загружены собственные драйверы этих же устройств! 
> 
> Конфликтов быть не должно. То есть, если в DD/OS какой-то драйвер садится на конкретный девайс, то хостовая ОС должна просто работать с этим драйвером через маппер. Если же хостовая ОС сама садится на девайс, то этот девайс скрывается от DD/OS -- пересекаться разные ОС не должны. Это достигается спец. настройкой хостовой ОС и гостевой ОС.
> 
> > Догадываешься, чем это грозит? А без, скажем, screen01.sys OS/2 разве ж загрузится?
> 
> Да, screen01.sys в OS/2 вроде, не отключить... Хотя, можно что-нибудь и придумать, например, подменить screen01.sys на версию, которая управляет не реальным, а виртуальным экраном. (исходники screen01.sys есть в тулките -- можно модифицировать)
> 
> Как вырезать куски os2krnl, работающие в реальном режиме -- вопрос сложный. Например, при загрузке BASEDEV-драйверов ядро работает с диском через функции os2boot (они работают в защищенном режиме, но вызывают хелперы ядра, которые переключаются в реальный режим для вызова int 13h, и потом, прочитав с диска, обратно переключаются в защищенный режим. Вот это действительно проблемма. (Но, все же, возможно, решаемая, если отказаться от переключения в реальный режим, а все нужные файлы загрузить GRUB'ом заранее в память))

_, _, _, _, _ _ _,_ (_ \| / \ \|\ \| \| \|_/ , ) \| , \ / \| \\| \| \| \ ~ ~~~ ~ ~ ~ ~ ~ ~