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

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

Тема:

> > > MemoryControl() -- это немного из другой оперы. Вообще, микроядро не оперирует сегментами -- оно оперирует страницами памяти -- flexpages. MemoryControl() позволяет задавать атрибуты страниц памяти. Для IA32 это: Default, Uncacheable, Write Combining, Write Through, Write Protected, Write Back. -- как я понял, это относится к кешируемости. К атрибутам сегментов это не имеет отношения.
> > 
> > Тогда я ещё меньше понимаю. Те сегменты, в которых само микроядро находится - они откуда взялись? 
> 
> Микроядро загрузил загрузчик kickstart и все эти сегменты он (kickstart) добавил в GDT и потом запустил само микроядро. Внутри себя микроядро как-то управляет всеми этими сегментами, но наружу показывает только несколько дескрипторов GDT и LDT, которыми можно манипулировать через некий API.
> 
> > А если GDT и таблицами трансляции логических адресов на физические ведает не микроядро, то выходит, что в них может ковыряться любой желающий?
> >  
> 
> Управляет всем этим _микроядро_. Но по отдельному запросу оно может добавить GDT/LDT дескриптор (если он проходит проверки на правильность, конечно). Причем для userland зарезервированы всего несколько (3 штуки в Fiasco, если мне память не изменяет) GDT-слотов. То есть, управляет этим всем микроядро, в userland может только в ограниченных пределах влиять.
> 
> > 
> > Напоминаю: мы обсуждали нашу ситуацию - когда исходников драйверов нет, поэтому они все непатченные. И сидят они в r3 - потому что в r0 только микроядро (так ведь?).
> 
> Я вообще-то предполагал, что патченные -- например, если добыть .obj-и и их дизассемблировать. Тогда можно к дизассемблированному коду применить "патчилку" -- т.е., afterburner.
> 
> > Ты сказал, что в таком случае проблем нет - право доступа к портам даём тому драйверу, который к этому порту обратится первым, а всех следующих - обламываем. Но ведь виртуализатор, под которым OS/2 запущена, ничего не знает о её внутренностях; в том числе он не знает, где в памяти заканчивается один драйвер и начинается другой. Точно так же он не знает, драйвер ли это вообще или вовсе даже прикладная программа. Поэтому получается, что право доступа к портам нужно давать всему коду, исполняемому в OS/2.
> >  
> 
> "Право доступа даем первому обратившемуся, а остальных обламываем..." -- речь здесь шла не о драйверах внутри VM, а о серверах и драйверах в _Хостовой_ системе, которая знает про микроядро и микроядро как раз знает, как отличить адресное пространство одного сервера (драйвера) от адресного пространства другого. То есть, к драйверам внутри VM это наверное, неприменимо.
> 
> Вообще, я как раз считал, что драйверы _патченные_ afterburner'ом. Если не патчить, а использовать драйверы в неизменном виде, то мне уже подсказали, что для этого уже существуют некие технологии Intel и Microsoft для запуска windows-драйверов внутри VM -- может быть, их можно адаптировать для нашего случая? По крайней мере, как-то они выкручиваются. То есть, здесь надо использовать несколько другую технологию виртуализации, чем оригинальный afterburner. -- Если мы не сможем ничего патчить, то технология виртуализации имхо, должна быть совершенно другая, чем afterburner.
>

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