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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : valerius
To : Юрий Пронякин
Subj : А вот вопрос, однако...
> > Новое ядро работает в основной VM, в которой работаю все приложения; старое -- во вспомогательной. На старом ядре запускаются старые драйвера; новое ядро их использует, делая запросы к приложению-мапперу, запущенному в VM со старым ядром.
>
> А вот это не совсем понятно. Что это за приложение такое, способное передавать запросы абсолютно любому драйверу OS/2?

Вообще, у меня самого тоже есть много вопросов. По крайней мере, я в ближайщее время собираюсь их задать в соответствующем списке рассылки.

> Унифицированного интерфейса драйверов в OS/2 нет

Разве?

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

А по-моемому, достаточно реализовать запросы некоторого "абстрактного" интерфейса к драйверам через стандартные функции DosOpen(), DosClose(), DosWrite(), DosRead() и DosDevIOCtl(). Конечно, разных функций DosDevIOCtl() много, и как их все "отобразить" на "абстрактный" интерфейс драйверов -- мне пока тоже непонятно. Но как-то это все же делается, нашли же способ все-таки. Но из собственно веб-страницы я согласен, что это неясно. Поэтому я собираюсь этот вопрос задать конкретно "аффторам".

> Но тогда размер этого маппера гросит стать сопоставимым с размером самого ядра. Мило, ничего не скажешь.
>

ну, если даже так, то можно это сделать более гибко. В конкретные детали реализации этого с L4Linux я пока не сильно вдавался, но можно например, сделать так (как я это себе представляю): ioctl-интерфейсы каждого драйвера не "хардкодятся" в маппере, а описываются в отдельном конфиге: Какие ioctl-функции поддерживает данный драйвер и их соответствие "абстрактным" функциям. То есть, для каждого драйвера пишется такой конфиг, а по нему маппер знает, как вести себя с конкретным драйвером. Плюс: если появился новый драйвер, то к нему можно написать такой конфиг, а не обновлять маппер.

Но 100% ответ на этот вопрос я пока дать не могу -- надо будет уточнить в списке рассылки. Вообще, возможно да, придется этому мапперу работать индивидуально с каждым драйвером... А возможно и нет -- пока не буду утверждать, а задам этот вопрос конкретно (в листе рассылки).

> > Созданию нового ядра это помогает в том смысле, что пока есть недостаток новых родных драйверов для нового ядра, можно старые драйвера запускать в VM со старым ядром. То есть -- пока нет новых драйверов, это позволяет новому ядру быть не в вакууме, а использоваться, пока пишутся новые драйвера. Это позволяет тестировать новое ядро и отлавливать в нем ошибки, даже если для него пока не хватает драйверов. То есть, переход к новому ядру будет плавным.
>
> Стоп. Если я правильно понимаю, новое ядро предполагается полностью 32-разрядным, с чисто 32-разрядными приложениями. А виртуализированная OS/2 нужна для использования 16-разрядных драйверов и запуска нынешних программ. Но откуда для этих драйверов и этих приложений возьмутся 16-разрядные кодовые сегменты?

Пока тоже не совсем понятно. В ядре Linux тоже, по идее есть 16-разрядные сегменты -- setup-код например. Потом, Паша говорит -- suspend/wakeup код тоже 16-битный. Как-то это все же сочетается с микроядром, но как -- пока непонятно.
То есть, возможно, все-таки какой-то 16-битный код все-таки работает. Пока 100% утверждать не берусь -- спрошу там же.

> Ведь микроядро, монопольно ведающее раздачей памяти, их создавать не умеет. А если такую возможность туда добавить, то это: а) противоречит идее использовать микроядро в оригинальном виде,

ну, это конечно, необходимо выяснить; сейчас же я ответ 100% не знаю. возможно, даже и умеет -- все возможно.

и б) поднимает вопрос: зачем тогда виртуальная OS/2 - ведь драйверы уже можно использовать и напрямую?
>

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

> > ОС-клиент общается с приложением-маппером, запущенном внутри DD OS, при помощи IPC-сообщений микроядра. (По сути, это удаленный вызов процедуры)
>
> Как я уже сказал, такой маппер, судя по всему, будет чрезвычайно раздутым, а на его создание уйдёт уйма времени.

пока об этом судить преждевременно, надо узнать об этом "из первоисточника"

> Делать это для драйверов Linux или Windows - понятно и оправданно. Но для идущих на выброс драйверов OS/2???
>

Если "маппер" будет реализовать проще, чем непосредственную поддержку в новом ядре, то оправданно.

> > drivers.php -- Проект "Device Drivers" L4Ka. Там целый раздел про виртуализацию, можно почитать почти весь, если заинтересовало.
>
> Как следует относиться к следующему их утверждению: "Our prototype's network performance is within 3--8% of a native Linux system"? "Типа шутка юмора"?

Да, прототип -- изолированные друг от друга драйверы диска и сетевой карты, согласно бенчмарку, дает производительность сети, на 3-8% ниже, чем в родной Linux-cсистеме, за счет виртуализации и изоляции виртуальных машин. А что смущает?


Tue 19 Jun 2007 08:16 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.