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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : valerius
To : Юрий Пронякин
Subj : А вот вопрос, однако...
> >> Я вот ещё чего боюсь. Из описания технологии Afterburning складывается впечатление, что она ориентирована на линуксную архитектуру, в которой драйверы вкомпилированы в ядро и, следовательно, патчатся вместе с ним
> >
> > Вкомпилированы в ядро, а также могут быть загружаемыми модулями. Да, по идее они, наверное, патчатся вместе с ядром. Но смущает именно утверждение, что драйвера немодифицированные. А может быть правда? Драйвер же не напрямую работает с ресурсами, а в основном через хелперы ядра? То есть, Хелперы в ядре, и они патчатся, а драйвер их только вызывает?
>
> Я как раз намеревался об этом написать. Ты же сам говорил, что драйверы в Линуксе платформо-нейтральные. К реальным железячным ресурсам они, действительно, доступаются, вызывая соответствующие функции платформо-зависимой части ядра.
>

Щас поспрашивал в списках рассылки, уже есть кое-какие результаты. Оказывается, все-таки патчения архитектурно-зависимой части ядра линукса недостаточно. -- Хотя линуксовые драйвера большей частью, не зависят от архитектуры процессора, но в то же время, к сожалению, они содержат за'inline'нные architecture-specific куски кода, которые "virtualization-specific", поэтому их все же, требуется патчить и перекомпилировать :-/ То есть, драйвера в форме сырцов остаются немодифицированными, но требуется перекомпиляция. То есть, надежда использовать виндовые драйвера похоже, отпадает :( -- ввиду отсутствия их исходников. Хотя сама технология не является Linux- или UNIX-специфичной. Можно применить и к windows (ReactOS), но препятствием является отсутствие исходников драйверов :(

> >>(потому что я не представляю, как запущенный в r3 немодифицированный драйвер сможет достучаться до портов). Если это так, то против OS/2 оно бессильно, и вся затея рушится.
> >
> > до портов он как раз достучаться может, то есть, может выполнять команды типа in и out. Для этого есть адресное пространство портов, которое в виде специальных i/o flexpages (виртуальные страницы памяти) отображается в адресное пространство портов ring3-драйвера.
>
> Не забывай, что драйверы в твоём проекте грузит OS/2, а привилегии сегментам раздаёт микроядро, ничего про OS/2 не знающее. Оно же понятия не имеет, что вот в этот вот кусочек памяти находится драйвер, которому к портам лазить нужно.
>

Не самО микроядро, а некий сервер (уже получивший эти ресурсы ранее у микроядра и сервера sigma0). Надо придумать, как за саму OS/2 сделать запрос этих портов и прочих ресурсов у сервера-менеджера ресурсов. (OS/2 не знает, что надо запросить эти ресурсы, но (в случае L4Linux) linux-то как-то знает, что ему надо запросить ресурсы, и запрашивает. Я думаю, аналогично линуксу можно сделать и с OS/2)

> > То есть, драйвер получает порты в виде flexpages от своего пейджера.
>
> А нет у драйвера прейджера. Этот пейджер один на всю виртуализированную OS/2.
>

Да, по идее, один -- некий менеджер ресурсов, владеющий всеми портами (l4io?)

> > Пейджер может решить отобразить i/o flexpages в адресное пространство приложения, и тогда доступ к порту появится, и операция in/out будет успешной.
>
> Но пейджер - он вне OS/2, И он не знает, осевой драйвер это к порту лезет или кто другой. Что делать? Разрешать этот доступ всем без исключения?
>

Нет, OS/2 сама модифицируется (наверное, Afterburner'ом) так, что она запрашивает ресурсы у этого пейджера. Как я понимаю, для каждого ресурса (область памяти или кусок пространства портов) сервер-менеджер ресурсов следует политике "серверу, первому запрашивающему ресурс, отдать этот ресурс, а остальным отказать в доступе". Ресурсы в проекте L4Ka Virtualization раздает сервер marzipan resource monitor. В случае Линукса, мы явно указываем, кроме того, сколько памяти отдать линуксу, и ограничиваем прочие ресурсы -- через команднуб строку marzipan. Аналогично можно сделать и с OS/2.

> > вот поэтому возможен вариант создания эмулятора интерфейсов ядра (раз они намного более скромные) для драйверов
>
> Эту тему стоит отложить до прояснения вопроса с исполнением 16-битного кода (непосредственно или через паравиртуализацию). До того мы вынуждены рассматривать только систему, в которой 16-разрядный код не поддерживается.

Этот вопрос я уже задал. Пока было 3 ответа на мои вопросы (можно прочитать на thread.html и на news.gmane.org). Пока насчет 16-битгного кода не все ясно, но, как уже подсказали, микроядро L4/Fiasco позволяет отдавать usermode-программам некоторые селекторы в GDT. Причем, можно использовать регистры FS и GS для своих целей, загрузив туда эти селекторы. Но, с друкгой стороны, в Fiasco вроде бы GS испоользуется для адресации Thread Local Storage, а в OS/2 FS используется для адресации структуры Thread Info Block. В общем, на вопросы еще не полностью ответили....


Fri 22 Jun 2007 10:26 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.