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

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

Тема:

> > >> Вспомни, что я называл "индивидуальной поддержкой". - Про каждый используемый в 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? И почему в этом случае перезапуск возможен? -- непонятно.

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