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

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

Тема:

> > Ну так, 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 КБ.)

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