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

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

Тема:

> > > Новое ядро работает в основной 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???
> >  
> 
> Если "маппер" будет реализовать проще, чем непосредственную поддержку в новом ядре, то оправданно.
> 
> > > http://l4ka.org/projects/virtualization/drivers.php -- Проект "Device Drivers" L4Ka. Там целый раздел про виртуализацию, можно почитать почти весь, если заинтересовало.
> > 
> > Как следует относиться к следующему их утверждению: "Our prototype's network performance is within 3--8% of a native Linux system"? "Типа шутка юмора"?
> 
> Да, прототип -- изолированные друг от друга драйверы диска и сетевой карты, согласно бенчмарку, дает производительность сети, на 3-8% ниже, чем в родной Linux-cсистеме, за счет виртуализации и изоляции виртуальных машин. А что смущает?
>

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