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

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

Тема:

> > > Ну так, DDE в l4env также использует линуксовые драйвера напрямую. Но это, как я понимаю, требует для каждого драйвера создания индивидуального враппера. А подход с виртуальными машинами более универсален.
> > 
> > А как я понимаю, вся разница только в том, что этот "враппер" перемещают внутрь виртуализированой системы и переобзывают "маппером". Необходимость индивидуального подхода к каждому драйверу при этом сохраняется.
> > 
> 
> Может быть. Но пока уверенно утверждать не буду
> 
> > >> Требования трудящихся, как мне кажется - чтобы их программы работали на их железе. А как это достигнуто - интересует только очень отдельных персон.
> > > 
> > > Вот, может быть, действительно следовало бы провести опрос на эту тему? А то многие товарищи уже утверждают почему-то, что мы ядро "опускаем ниже пояса", "это уже будет не OS/2", "не нативно", "идеологически чуждо" и прочее. :-/
> > 
> > А вот этим товарищам можно просто не говорить, как оно там внутри устроено ;-)
> > 
> 
> ;-)
> 
> > > по крайней мере, заманчиво -- если текущее ядро заработает на гипервизорах, то разве это плохо?
> > 
> > Это не плохо, это замечательно. Потому что в этом случае мы не только получаем 100%-е сохранение работоспособности всех нынешних драйверов и программ (включая 16-битные), но можем вообще не заботиться о поддержке нынешних программ (включая LX) в новом ядре, а реализовывать в нём только новую архитектуру.
> 
> > Вся проблема только в том, что из-за принципов работы паравиртуализатора прогнозируемый объём работы - неподъёмный.
> 
> если дизассемблировать, то похоже, да
> 
> > Существенно уменьшить его можно только одним способом - раздобыть каким-то образом .obj-файлы, из которых ядро собирается. OBJ-и дизассемблировать - одно удовольствие.
> 
> это тоже идея. Только кто нам даст .obj-и? IBM? Вот если бы была такая тулза "делинкер" -- на входе .exe, а на выходе .obj и .def :) Только как я понимаю, при линковке информация из .obj-ей теряется, и ее обратно не восстановить
> 
> > Или другой вариант: взять то, что было наработано в рамках osFree TPE, тяжело вздохнуть и начать добавлять туда KEE и прочие новинки. (Для справки: владелец лицензии на OS/2, в принципе, имеет право пользоваться таким ядром.)
> > 
> 
> Но тогда новым пользователям неоткуда получить лицензии, тем боллее, что IBM скоро может прекратить их продавать. osFree TPE -- крайний вариант, к сожалению.
> 
> > > Модификация нынешнего позволит хотя бы 1) уже сейчас перенести ядро в userlevel
> > 
> > Ядро - возможно. А драйверы? Кто их в непатченном виде к портам пустит?
> > 
> 
> Насчет драйверов пока 100% неясно. С одной стороны, в линухе драйвера компилируются (и патчатся, наверно) вместе с ядром. С другой стороны, смущает утверждение разработчиков насчет "_unmodified_ driver reuse". Может быть, всеже, патчатся именно хелперы в ядре, а драйверы эти хелперы только вызывают? Вообще, драйверы могут работать напрямую с портами и памятью, отображенной на устройства, это все рассматривается микроядром как разновидность памяти, которая может быть получена у менеджера памяти. То есть, как я понимаю, тут ничего не виртуализуется, драйвер работает напрямую с портом или memory-mapped i/o. То есть, здесь не требуется заменять доступ к устройствам на вызовы виртуализатора.
> 
> > > 2) изолировать неустойчивые драйверы в отдельную VM
> > 
> > У нынешних драйверов не предусмотрена процедура перезапуска. Они рассчитаны на то, что в момент их старта управляемый ими объект находится во вполне определённом состоянии. А после падения драйвера это состояние может оказаться каким угодно. И это так не только для драйверов устройств, а для любых. Как ты себе представляешь, например, перезапуск IFS, если при её падении на диске были открытые файлы?
> > 
> 
> Да, состояние при этом конечно, не сохраняется. То есть, если например, проигрывается звук и драйвер звуковой карты падает, то после перезапуска VM состояние будет "дефолтным", например, уровень звука сбросится. С IFS, конечно, сложнее -- возможна потеря данных. Но по крайней мере, при этом в любом случае система трапается и возможна потеря данных. А в случае запуска внутри VM хотя бы нарушится состояние только одной VM, на остальную часть системы это не влияет -- она может продолжать работать.
> 
> > > 3) использовать OS/2 одновременно с другими ОС
> > 
> > Пока что это "сказки для детей младшего школьного возраста". Потому что пока что ещё даже две независимые копии Линукса параллельно запустить не сподобились, насколько я знаю.
> > 
> 
> На самом деле, это не так. Если добиться, чтобы разные виртуальные машины не конфликтовали по ресурсам, то вполне можно запустить несколько экземпляров VM. Простейший метод -- запуск системы с образа ramdisk'а. Например, в TUD OS demo CD таким образом запускается куча копий L4Linux на одном десктопе в окошках :) Если интересно, можно скачать демо-диск с сайта http://demo.tudos.org/ или, если жалко трафика (весит CD больше 100 Мб), то можно посмотреть скриншоты на том же сайте.
> 
> > > > Так не будет же никакого тестирования нового ядра. Потому что работать в такой схеме будут только IBM-овское ядро и виртуализатор. Никакие функции старого ядра перенаправляться в новое не будут. 
> > > 
> > > будут, через маппер
> > 
> > Ну что ты... Маппер выполняет строго обратную функцию - перенаправляет запросы из основной ОС в виртуализированную. Но не наоборот. Поэтому, если программа в виртуализированной OS/2 попросит, например, выделить ей память, то выделением памяти будет заниматься ядро OS/2, а не новое. И никаким маппером ты этот запрос не перехватишь.
> >  
> 
> Нет. Программы (кроме самого маппера) запускаются в основной VM. А от VM с драйверами требуется только выполнение ioctl-запросов на драйверы и возврат результатов в основную VM. То есть, выделение памяти, разумеется, будет выполняться новым ядром в основной VM. А выполнять эти запросы старому ядру и не требуется -- его задача просто обслуживать драйвера, и все.
> 
> > 
> > > Пока непонятно, возможно ли это (например, я смотрел -- отдельные функции DevHlp требуют аргументов в регистрах типа es:di, а по-идее, сегментные регистры может задавать только микроядро -- как здесь быть?
> > 
> > Не совсем понятно, что значит "задавать". Загрузка любого значения в сегментный регистр - команда непривилегированная.
> >
> 
> Вообще-то да. Сегментные регистры можно загружать (хотя я не был в этом уверен). А вот в GDT добавить селектор может только ядро.
>  
> > >> В итоге складывается впечатление, что на дизассемблирование и перекомпилирование драйверов уйдёт меньше времени, чем на "впарвление мозгов" нынешнему ядру.
> > > 
> > > вполне возможно. Вот я и предложил еще один вариант -- паравиртуализовать только драйверы, а вместо ядра сделать эмулятор интерфейсов ядра, минимально необходимых для работы драйверов
> > 
> > Стопорит это дело только одно: необходимость иметь ассемблерный текст драйверов. Исходники, то есть. Но если они есть, то драйвер и в 32 разряда переделать можно.
> > 
> > > > > А стек TCPIP? Его вроде, в тулките нема.
> > > > 
> > > > LX-файлы.
> > > 
> > > Ну и что. Поможет ли в случае LX-драйверов конвертер LX-файлов в чистые 32 бит для приложений или нет -- пока неясно. Возможно конечно, и поможет.
> > 
> > LX-файл, в принципе, можно разобрать на независимые части, дизассемблировать только те из них, которые 16-битные, переделать их в 32-битные, после чего собрать всё снова. Объём 16-разрядного кода в них - незначительная часть от общего размера файла. Набор файлов тоже заранее известен.
>

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