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

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

Тема:

> >> В предлагаемом тобой случае маппер должен знать, к какому классу относится каждое устройство. А устройств - их гораздо больше, чем драйверов (один драйвер может поддерживать кучу устройств). И новые устройства появляются граздо чаще, чем новые драйверы. И как быть с устройствами, не обнаруживаемыми через scanpci?
> > 
> > Это пока только моя гипотеза. Я уже задал этот вопрос в мейл-листе, жду пока ответят. Вполне возможно, что разработчики выкручиваются как-то по-другому. Может быть, это прописывается в конфиге или еще как...
> 
> Так ведь ты уж сколько дней как спросил. Всё ещё не ответили? Неужто сами об этом раньше не задумывались?
>  
> >> К тому же у нас не только драйверы устройств. IFS, например, как опознавать будем?
> > 
> > IFS-тоже своеобразный класс драйверов, который экспортирует и импортирует определенный набор функций. Пока насколько я понял, (в случае L4Linux) реализованы только классы устройств, такие как блочные устройства, сетевые карты, работа с шиной PCI. Про остальные пока не знаю.
> 
> Да не важно, к какому классу относится. Важно, что мапперу извне (из хостовой ОС) пришёл запрос некоему драйверу с именем ABCD, и этот драйвер - не к физическому устройству прицеплен, а абстрактный (NETBIOS, TCP/IP, IFS, да OS2DASD$ в конце-концов). Как маппер определит, к какому именно классу этот драйвер относится, если у него нет таблички с соответствием "имя - класс"?
> 
> > (А как насчет K42 -- неужели, там уже реализовали 100% поддержку всех драйверов Linux?) Во любом случае, ИМХО, самим дотачивать придется.
> 
> Написано, что реализована поддержка немодифицированных драйверов. 100%-ность не гарантируют, но клянутся, что все протестированные работали.
> Лично я ничего сверхестественного в этом не вижу.
>  
> > Насколько я помню, OS/2 ядро прыгает в реальный режим только при чтении с диска драйверов BASEDEV средствами int 13h. (или я неправ? где еще?)
> 
> А мне помнится, что были драйверы, которые при старте (а то и в процессе работы) к BIOS (материнки или управляемого устройства) обращались.
> 
> > Если это так, то можно заменить в ядре хелпер для чтения с диска на хелпер, читающий файлы из их образов в памяти (т.е., все нужные файлы грузить загрузчиком в память, а потом оттуда по мере надобности их извлекать.).
> 
> Ага, задумаемся над этим. DD/OS/2 с её драйверами ешё только грузится, следовательно хостовая ОС обращаться к этим драйверам ещё не может. Как тогда сама эта ОС смогла загрузить в память всё свои потроха, необходимые для запуска этой виртуализированной OS/2 (включая сам виртуализатор)?
> 
> > Могу предложить даже заменить os2boot на спец. версию, читающую файлы из памяти, а не с диска.
> 
> Вот. В памяти они как окажутся?
> 
> > Просто, этой версии хелпер для чтения с диска уже не нужен будет, а все нужные файлы она возьмет среди тех, что загрузчик загрузил в память. (Такой подход: грузим все, что надо, в память, а потом извлекаем файлы оттуда -- применяется в загрузчике OS/2 PowerPC, а также, аналогично поступает GRUB).
> 
> Подумай хорошенько:
> Список файлов, которые будут нужны в процессе старта OS/2 частично содержится в CONFIG.SYS, частично - зашит в загрузчик и ядро. А грузить их в память должен загрузчик хостовой ОС. Как ему узнать, какие именно файлы нужно грузить? Парсить CONFIG.SYS? дальше. Читать эти файлы из памяти будет загрузчик (хелпер) гостевой ОС. Как он их там найдёт? По специнформации, которую ему оставит первый загрузчик?
> В общем, получается, что вся эта самодельная ОС, начиная с её загрузчика, привязана к наличию в ней виртуализируемой ОС. Ох, не хотел бы я иметь дело с такой конструкцией.
> 
> >> Вот-вот. Для каждого такого драйвера придётся писать виртуальный заменитель. И по мере реализации родных драйверов для новой ОС (хостовой), придётся писать заменители для всех драйверов OS/2. Представляешь, на сколько увеличивается общий обьём работы?
> > 
> > Не для каждого, а всего для трех. Остальные, если надо, можно просто закомментировать в конфиге.
> 
> Ты можешь загрузить OS/2 без драйвера контроллера дисков? Или без драйвера видеоконтроллера? Я даже не уверен, что она сможет загрузиться без драйвера клавиатуры.
>  
> >> И всё это вместо того, чтобы один раз сделать в хостовой ОС эмулятор драйверного API OS/2. Нет, не даром в K42 пошли именно по этому пути. 
> > 
> > Эмулятор тоже можно сделать.  Только ИМХО, это труднее.
> 
> Чем больше мы с тобой переписываемся, тем больше проблем обнаруживается в идее использовать паравиртуализацию. А одно только дизассемблирование ядра OS/2 - уже более трудоёмкое, чем создание driver execution environment.
> 
> > Я же не говорю, что все должно работать через линуксовые драйвера. Например, абстрактные драйвера, типа resource,sys или pmdd.sys не имеют аналогов в других ОС, и их все равно, придется писать самим.
> 
> Так в том-то и дело, что драйверы не нужно переписывать, их можно будет использовать имеющиеся (даже не модифицированные).
> Вспомни, я писал, что достоинством варианта с виртуальной OS/2 является то, что при этом ещё и автоматически получается среда для запуска программ OS/2 (не нужно ни OS/2 API эмулировать, ни свои загрузчики NE/LX файлов писать).
> 
> > > Кстати, динамический запуск/перезапуск в варианте с эмулятором тоже невозможен - в отличие от обоих альтернативных.
> > 
> > Не понял? Перезапуск виртуальной машины -- почему невозможен -- как раз возможен.
> 
> Да. А в этой машине - _все_ драйверы. Поэтому они все будут перезапущены. Кроме того, как я уже показывал, нельзя продолжать и выполнение запущенных в этот момент программ - их придётся закрывать (точнее - прибивать) и запускать по новой. Чем это принципиально отличается от полной перезагрузки ОС?
> О, кстати - оказывается, те файлы, что начальный загрузчик в память вычитал, нужно всё время в этой памяти и держать - чтобы виртуальную ОС перезапустить можно было.
> 
> > Но если драйвер упал, то его состояние все равно испорчено, так что передавать все это состояние новой копии при перезапуске не имеет смысла -- новая копия опять попадет в аварийную ситуацию, так что все равно нужно перезапускать с нуля.
> 
> Для моей ОС на этот случай кое-что придумано.
> 
> > А альтернвативные (2 штуки) -- это какие? DDE и случай K42?
> 
> DDE - как расшифровывается? Device driver environment (execution)? Если да, то это один из вариантов. А второй - преобразование дизассемблированных драйверов в родные драйверы ОС.
> 
> > И почему в этом случае перезапуск возможен? -- непонятно.
> 
> Потому что в этом случае драйверы грузятся не гостевой ОС, а хостовой, и, следовательно, живут по её правилам. В том числе они и изолированы друг от друга, что делает возможным их независимый перезапуск.

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