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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Юрий Пронякин
To : valerius
Subj : А вот вопрос, однако...
> Ну так, DDE в l4env также использует линуксовые драйвера напрямую. Но это, как я понимаю, требует для каждого драйвера создания индивидуального враппера. А подход с виртуальными машинами более универсален.

А как я понимаю, вся разница только в том, что этот "враппер" перемещают внутрь виртуализированой системы и переобзывают "маппером". Необходимость индивидуального подхода к каждому драйверу при этом сохраняется.

>> Требования трудящихся, как мне кажется - чтобы их программы работали на их железе. А как это достигнуто - интересует только очень отдельных персон.
>
> Вот, может быть, действительно следовало бы провести опрос на эту тему? А то многие товарищи уже утверждают почему-то, что мы ядро "опускаем ниже пояса", "это уже будет не OS/2", "не нативно", "идеологически чуждо" и прочее. :-/

А вот этим товарищам можно просто не говорить, как оно там внутри устроено ;-)

> по крайней мере, заманчиво -- если текущее ядро заработает на гипервизорах, то разве это плохо?

Это не плохо, это замечательно. Потому что в этом случае мы не только получаем 100%-е сохранение работоспособности всех нынешних драйверов и программ (включая 16-битные), но можем вообще не заботиться о поддержке нынешних программ (включая LX) в новом ядре, а реализовывать в нём только новую архитектуру.
Вся проблема только в том, что из-за принципов работы паравиртуализатора прогнозируемый объём работы - неподъёмный.
Существенно уменьшить его можно только одним способом - раздобыть каким-то образом .obj-файлы, из которых ядро собирается. OBJ-и дизассемблировать - одно удовольствие.
Или другой вариант: взять то, что было наработано в рамках osFree TPE, тяжело вздохнуть и начать добавлять туда KEE и прочие новинки. (Для справки: владелец лицензии на OS/2, в принципе, имеет право пользоваться таким ядром.)

> Модификация нынешнего позволит хотя бы 1) уже сейчас перенести ядро в userlevel

Ядро - возможно. А драйверы? Кто их в непатченном виде к портам пустит?

> 2) изолировать неустойчивые драйверы в отдельную VM

У нынешних драйверов не предусмотрена процедура перезапуска. Они рассчитаны на то, что в момент их старта управляемый ими объект находится во вполне определённом состоянии. А после падения драйвера это состояние может оказаться каким угодно. И это так не только для драйверов устройств, а для любых. Как ты себе представляешь, например, перезапуск IFS, если при её падении на диске были открытые файлы?

> 3) использовать OS/2 одновременно с другими ОС

Пока что это "сказки для детей младшего школьного возраста". Потому что пока что ещё даже две независимые копии Линукса параллельно запустить не сподобились, насколько я знаю.

> > Так не будет же никакого тестирования нового ядра. Потому что работать в такой схеме будут только IBM-овское ядро и виртуализатор. Никакие функции старого ядра перенаправляться в новое не будут.
>
> будут, через маппер

Ну что ты... Маппер выполняет строго обратную функцию - перенаправляет запросы из основной ОС в виртуализированную. Но не наоборот. Поэтому, если программа в виртуализированной OS/2 попросит, например, выделить ей память, то выделением памяти будет заниматься ядро OS/2, а не новое. И никаким маппером ты этот запрос не перехватишь.

>> - Peer (LS) и протоколы. Самая тяжёлая часть. Но TCP/IP, как отмечено выше - 32-разрядный,
>
> но поддержку 32-разрядных тоже пока непонятно как реализовать. Насколько я слышал, 32-разрядный API (KEE) не 100% охватывает все надобности (он был разработан прежде всего для портирования в OS/2 JFS, поэтому в нем в основном минимум фкнкций, нужных именно для этой задачи), проэтому 16-битные функции DevHlp все-таки приходится вызывать. То есть, поддержку DevHlp тоже придется реализовывать.

Да. По одной из тех технологий, которые предлагались для LX-файлов. Ведь драйвер такой - он тоже LX-файл.

> Пока непонятно, возможно ли это (например, я смотрел -- отдельные функции DevHlp требуют аргументов в регистрах типа es:di, а по-идее, сегментные регистры может задавать только микроядро -- как здесь быть?

Не совсем понятно, что значит "задавать". Загрузка любого значения в сегментный регистр - команда непривилегированная.

>> В итоге складывается впечатление, что на дизассемблирование и перекомпилирование драйверов уйдёт меньше времени, чем на "впарвление мозгов" нынешнему ядру.
>
> вполне возможно. Вот я и предложил еще один вариант -- паравиртуализовать только драйверы, а вместо ядра сделать эмулятор интерфейсов ядра, минимально необходимых для работы драйверов

Стопорит это дело только одно: необходимость иметь ассемблерный текст драйверов. Исходники, то есть. Но если они есть, то драйвер и в 32 разряда переделать можно.

> > > А стек TCPIP? Его вроде, в тулките нема.
> >
> > LX-файлы.
>
> Ну и что. Поможет ли в случае LX-драйверов конвертер LX-файлов в чистые 32 бит для приложений или нет -- пока неясно. Возможно конечно, и поможет.

LX-файл, в принципе, можно разобрать на независимые части, дизассемблировать только те из них, которые 16-битные, переделать их в 32-битные, после чего собрать всё снова. Объём 16-разрядного кода в них - незначительная часть от общего размера файла. Набор файлов тоже заранее известен.
Это относится не только к драйверам, а ко всем файлам, входящим в дистрибутив OS/2.

>>> Потом, как быть с самописными -- многие аффторы уже мигрировали с OS/2 и им уже не до переписи драйверов под новую модель, и не факт что они отдадут исходники :(
>>
>> Те, которые пишут под актуальное ныне железо - все на месте и доступны.
>
> Может быть и да...
>
> а те, которые под неактуальное? все-таки, имеющиеся драйверы терять не хочется -- кому-то они могут и понадобиться...

Вероятность успешного дизассемблирования и пересборки драйвера гораздо выше вероятности успеха этой затеи с ядром.
(Более общее утверждение: вероятность успешного дизассемблирования и пересборки 10 программ размером 10 КБ каждая гораздо выше вероятности успешного дизассемблирования и пересборки 1 программы размером 100 КБ.)

Tue 19 Jun 2007 14:10 Mozilla/5.0 (OS/2; U; Warp 4.5; ru-RU; rv:1.7.12) 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.