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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : valerius
To : Юрий Пронякин
Subj : А вот вопрос, однако...
> > Ну так, 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 на одном десктопе в окошках :) Если интересно, можно скачать демо-диск с сайта 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-разрядного кода в них - незначительная часть от общего размера файла. Набор файлов тоже заранее известен.


Tue 19 Jun 2007 19:44 Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.10) 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.