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

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

Тема:

> > Хорошо, посмотрим на эту затею так: система паравиртуализации в еёё нынешнем виде предлагает возможность выполнения 16-разрядного кода?
> > 
> 
> Пока 100% неизвестно -- предстоит выяснить. По идее, ядро Linux все же содержит 16-битные фрагменты, например, setup-код (работа с функциями BIOS, тестирование устройств), а также wakeup/suspend код. Как это сочетаестся с микроядром, пока неясно.
>  
> > > Но большинство почему-то считает, что раз драйвера линуксовые и исполняются ядром линуха, а не непосредственно ядром OS/2, то это "ненативно", "идеологически чуждо" и прочее.
> > 
> > Стоп, стоп. Вот, K42 пользуется линуксными драйверами непосредственно, не привлекая для этого ядро Линукса. (Обещается даже выполнение этих драйверов в user-level.)
> > Я в данном случае не K42 рекламирую, а просто обращаю внимание на принципиальную возможность такого фокуса. (Хотя, как говорил когда-то Райкин: "Возьмите, ребятки, воспользуйтесь." :-)
> 
> Ну так, DDE в l4env также использует линуксовые драйвера напрямую. Но это, как я понимаю, требует для каждого драйвера создания индивидуального враппера. А подход с виртуальными машинами более универсален. Да и эффектов не-100% соответствия этого враппера с интерфейсами ядра Linux в случае виртуализации нет. Все-таки, все 100% сэмулировать очень тяжело. А тут -- эмулировать ничего не надо.
> 
> > 
> > > Это конечно, просто религиозный предрассудок, но... Если мы пишем ядро, то хочется, чтобы этим ядром пользовались. А не говорили -- "фу, линуксовая хрень". Поэтому следует подумать, как учесть требования трудящихся, если это конечно, возможно. 
> > 
> > Требования трудящихся, как мне кажется - чтобы их программы работали на их железе. А как это достигнуто - интересует только очень отдельных персон.
> >  
> 
> Вот, может быть, действительно следовало бы провести опрос на эту тему? А то многие товарищи уже утверждают почему-то, что мы ядро "опускаем ниже пояса", "это уже будет не OS/2", "не нативно", "идеологически чуждо" и прочее. :-/
> 
> > > Да, похоже так -- для использования ядра OS/2 надо иметь лицензию на копию OS/2 и распространять бесплатно его будет нельзя. Но... Использовать ядро, полученное модификацией исходного IBM'овского ядра OS/2, предполагается именно в _переходный_ период, пока opensource-аналогов большинства подсистем нету. То есть, у нас будет новое ядро OS/2, а подсистемы будут продолжаться использоваться IBM'овские. То есть, копия OS/2 будет в данных условиях у каждого. Просто пользователь будет брать OS/2 или eCS и заменять ядро на наше. А ядро OS/2 (в том числе, паравиртуализованное) можно будет распространять вместе с копией eCS,
> > 
> 
> > Но тогда вопрос: заче вообще нужно паравиртуализировать нынешнее ядро?
> 
> по крайней мере, заманчиво -- если текущее ядро заработает на гипервизорах, то разве это плохо?
> 
> > На самом деле "переходный период" - он практически вечный, потому что для его завершения нужно, чтобы в системе не осталось вообще ничего IBM-овского (т.е., и PM с WPS тоже нужно самим реализовать).
> 
> Это все нужно, но это будет все потом. И osFree тоже предполагает постепенную замену всех подсистем opensource-аналогами. Но пока выдвинута идея -- сделать возможность простой замены старого ядра на новое с созранением работоспособности всех (насколько это возможно) подсистем. Это ранее не предполагалось делать, но подумать о возможности реализации такого следует.
> 
> > Первый шаг к этому - создание своего ядра. А модификация ядра нынешнего - она зачем? Что она даёт? Драйверы нынешние продолжать гонять можно будет? Так это и под непеределанным ядром продолжать делать можно.
> > 
> 
> Модификация нынешнего позволит хотя бы 1) уже сейчас перенести ядро в userlevel 2) изолировать неустойчивые драйверы в отдельную VM 3) использовать OS/2 одновременно с другими ОС
> 
> > > оно будет позволять запускать eCS на гипервизорах или для поддержки 16 битных драйверов в виртуальной машине одновременно с нашим новым ядром -- то есть, пока новое ядро имеет мало своих собственных драйверов и находится в разработке, можно запускать старое ядро в другой вирт. машине и гонять на нем старые 16-бит драйверы.
> > 
> 
> > И остаётся главный вопрос (тобой же озвученный): если микроядро умеет создавать только 32-разрядные сегменты, то откуда возьмутся 16-разрядные? Ведь "паравиртуализатор", он, насколько я понимаю, тоже не в микроядре сидит, и он не может сказать ему: "А поправь-ка вот эти байтики в дескрипторе сегмента".
> 
> Вот это пока неясно -- предстоит выяснить. (про это я уже писал выше)
> 
> > 
> > >> ЭТОТ вариант заведомо можно не рассматривать.
> > > 
> > > Подумать все же, имхо, стОит. Все-таки, важно чтобы в переходный период наше ядро использовалось как можно большим числом осевиков, тестировалось, исправлялись ошибки...
> > 
> > Так не будет же никакого тестирования нового ядра. Потому что работать в такой схеме будут только IBM-овское ядро и виртуализатор. Никакие функции старого ядра перенаправляться в новое не будут. 
> 
> будут, через маппер
> 
> > Разве что это перенаправление будет сделано в дизассемблированном исходнике - вместе с огромными шансами что-то в ядре при этом развалить.
> >  
> 
> это должно быть сделано в маппере, а не модификацией ядра
> 
> > >> Какими драйверами? "Назовите поимённо!"
> > > 
> ...
> > Хорошо, давай явно разделим драйверы устройств и абстрактные драйверы. Драйверов устройств, исходники которых недоступны, полезных уже практически не осталось. То, чем мы пользуемся - либо самописное, либо в DDK.
> > Драйверов абстрактных - их куда больше, и многие в DDK не встречаются. Но: они в основном мелкие и, по-моему, их совокупный размер меньше, чем размер ядра. Так что если уж что и дизассемблировать, то это их.
> > Оценим также и твой список:
> > - TCPIP. Драйверы в основном 32-битные.
> > - MMOS/2. 16-разрядных драйверов всего 3, и те "поддаются перевоспитанию".
> > - DANIS506. Самописный, я предполагаю ;-)
> > - Драйверы NDIS. Под современные карточки, за редким исключением - самописные.
> > - Peer (LS) и протоколы. Самая тяжёлая часть. Но TCP/IP, как отмечено выше - 32-разрядный,
> 
> но поддержку 32-разрядных тоже пока непонятно как реализовать. Насколько я слышал, 32-разрядный API (KEE) не 100% охватывает все надобности (он был разработан прежде всего для портирования в OS/2 JFS, поэтому в нем в основном минимум фкнкций, нужных именно для этой задачи), проэтому 16-битные функции DevHlp все-таки приходится вызывать. То есть, поддержку DevHlp тоже придется реализовывать. Пока непонятно, возможно ли это (например, я смотрел -- отдельные функции DevHlp требуют аргументов в регистрах типа es:di, а по-идее, сегментные регистры может задавать только микроядро -- как здесь быть? (пока неясно насчет сочетания 16-разрядного кода с микроядром и манипулирования сегментными регистрами -- надо этот вопрос выяснить))
> 
> > а актуальность LS и частого NETBIOS давно утрачена (заставить Windows XP работать по NETBIOS я так и не смог), а для NETBEUI лучше Самбу применять.
> >
> 
> согласен
>  
> > В итоге складывается впечатление, что на дизассемблирование и перекомпилирование драйверов уйдёт меньше времени, чем на "впарвление мозгов" нынешнему ядру.
> 
> вполне возможно. Вот я и предложил еще один вариант -- паравиртуализовать только драйверы, а вместо ядра сделать эмулятор интерфейсов ядра, минимально необходимых для работы драйверов
> 
> > И вообще, если уж так биться за старые драйверы, проще реализовать своё ядро, сразу умеющее исполнять 16-разрядный код. Один хрен виртуализатор должен будет это уметь как-то это делать.
> 
> но пока неизвестно, может быть все же, маппер реализовать проще. Хотя да, если это можно сделать паравиртуализацией ядра, то можно поддержку 16-бит драйверов реализовать и напрямую.
> 
> > 
> > > А стек TCPIP? Его вроде, в тулките нема.
> > 
> > LX-файлы.
> > 
> 
> Ну и что. Поможет ли в случае LX-драйверов конвертер LX-файлов в чистые 32 бит для приложений или нет -- пока неясно. Возможно конечно, и поможет.
> 
> > > А USB-стек, PCMCIA-стек? -- возможно, в DDK они есть -- не проверял, но вот USB стек там очень старый
> > 
> > Да, старый. Только вот и нынешний, судя по том обсуждениям, которые я вижу в Интернете и Фидо, работает куда хуже, чем Линуксный. (Насчёт флешек ты и сам знаешь; мышку мою нынешнюю (совершенно стандартную) удалось запустить только с самописным драйвером, потому что IBM-офский подерживает только подмножество стандарта.)
> > 
> 
> > > Потом, как быть с самописными -- многие аффторы уже мигрировали с OS/2 и им уже не до переписи драйверов под новую модель, и не факт что они отдадут исходники :(
> > 
> > Те, которые пишут под актуальное ныне железо - все на месте и доступны.
> 
> Может быть и да...
> 
> а те, которые под неактуальное? все-таки, имеющиеся драйверы терять не хочется -- кому-то они могут и понадобиться...
>

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