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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : valerius
To : Юрий Пронякин
Subj : А вот вопрос, однако...
> > Что еще ценного мне подсказали в списке рассылки:
>
> Я читал всё это - ты же сам ссылки давал.
>
> > 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'ом заранее в память))

Mon 25 Jun 2007 05:48 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.