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

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

Тема:

> > >> Я вот ещё чего боюсь. Из описания технологии 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 ответа на мои вопросы (можно прочитать на http://os.inf.tu-dresden.de/pipermail/l4-hackers/2007/thread.html и на http://news.gmane.org/gmane.comp.micro-kernel.l4.l4ka.general). Пока насчет 16-битгного кода не все ясно, но, как уже подсказали, микроядро L4/Fiasco позволяет отдавать usermode-программам некоторые селекторы в GDT. Причем, можно использовать регистры FS и GS для своих целей, загрузив туда эти селекторы. Но, с друкгой стороны, в Fiasco вроде бы GS испоользуется для адресации Thread Local Storage, а в OS/2 FS используется для адресации структуры Thread Info Block. В общем, на вопросы еще не полностью ответили....
>

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