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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : valerius
To : dixie
Subj : Организационная поддержка
> > Ифраструктура - это пол беды - беда это отсутствие комуникации между участниками проекта
> >(то что-то не живет, то разработчика потеряли, то до админа не достучаться). Вобщем я никого
> >не агитирую, если народ будет за - я буду все это поднимать и помогать в ведении проекта.
> >Если народ опять же решит доверять свои коды Нетлабсу - тоже хорошо, лишь бы дело шло.
> Нетлабс нафих :)
> Вопрос в другом - что именно писать-то будем? ;)
> Конечно, как будет выглядеть ядро - будет в конечной степени определять Паша - ему, ж, делать ;) Но, вот, valerius уже тянет какую-то линуксовую хрень ;),а Юра Пронякин щас за 64 бита рекламную компанию развернёт, ну и.т.п. ;)
>

Не линуксовую. А хрень по типу OS/2 PowerPC. Микроядро там, personalities.. ;)
А линукс и венда как дополнительные personalities. Причем про линух я говорил много потому что он уже есть практически готовый.

> Не знаю - у меня пока только два принципиальных момента:
> - ядро 16/32. Причины: старый софт, старые игры, DOS игры (таки, Master of Magic пока никто не превзошёл ;), 64 бита - очередной и очень кривой рекламный трюк ;).

Если смотреть в сторону L4Ka::Pistachio, то оно подерживает кучу как 32-бит так и 64-бит архитектур (Alpha (21164, 21264); AMD64 (Opteron 242, Simics); ARM (SA1100, XScale, ARM925T); IA32 (Pentium and higher); IA64 (Itanium1, Itanium2, Ski); MIPS 64bit (R4000, R5000); PowerPC 32bit (IBM 750); PowerPC 64bit (Power3, Power4)). То есть, поддержка всех этих архитектур уже есть и реализована (то есть, возможна работа на разных экзотических девайсах, типа сотовых телефонов). Прикладной софт при этом остается без изменения, его надо просто перекомпилировать под каждую архитектуру.

Насчет 16-бит -- самое сложное. Поддержки 16-битных процов нету как в L4, так и в микроядре Mach, на котором построена OS/2 PPC. Но если посмотреть на OS/2 PPC, то мы увидим, что там IBM вместо подсистемы MVDM (Multiple Virtual DOS Machines), как в обычной оси, реализовала подсистему MVM (Multiple Virtual Machines). Так как процессор был PowerPC, то IBM'у вместо режима V86 пришлось реализовать подсистему эмуляции команд процессора Intel, поверх нее работала поддержка эмуляции DOS. Причем эта эмуляция DOS даже была новее, чем в интелевой версии оси -- она была основана на исходниках PC DOS 7. Причем в этой виртуальной машине DOS даже работала WinOS/2, ничем не отличающаяся от обычной! Реализация такой "пробирки", конечно, является очень сложной задачей, и IBM ее решила. Так же можем поступить и мы, если будем пытаться все реализовать на L4Ka::Pistachio. То есть, 16-бит реализовать тоже в принципе, возможно. Надо только суметь это сделать...

>ЕСЛИ возможно (очень маловероятно) - что-то вроде PROTECTONLY=YES, переключающего 16/32 в 32/64. О переключении "нажатием кнопки" с прибитием 16/64bit задач соотвественно - даже и не заикаюсь :)) Beep, конечно - такие 64 bit :(
>

Если версия микроядра для 64-битного процессора, то 32-бит, если я правильно понимаю, будет работать? То есть, 64 и 32-разрядные программы можно запускать одновременно? Или нет -- я слышал, что на 64-битной винде для запуска 32-бит программ требуется спец. эмулятор Wow64 (вроде так называется). То есть, скорее, подход должен быть следующий: на 64-битной машине берется 64-бит версия ядра, а 16- и 32-бит работает через виртуализацию. То есть, видимо, потребуется эмулятор процессора IA32... Возможно, для этого можно использовать исходники QEMU (не уверен насчет производительности).

> - поддержка регистри в ядре. Замена config.sys на регистри. Почему? config.sys - это удобно. Но start/stop driver это _удобней_. Понятно, что, от силы 5% драйверов в NT/2k/XP держат stop - но даже просто start - уже удобно.

Регистри -- вещь нужная. Но имхо, не в том виде, как это сделано в виндовс. Возможно, следует вспомнить корни -- реализацию регистри в OS/2 PPC. Там было нечто большее, чем просто регисти в понимании windows. Было понятие Namespace. Оно основывается на службе разрешения имен -- очень важной части любой микроядерной системы. Если вкратце, то микроядерная система -- набор программ-серверов, каждый из которых выполняет какую-то узкую задачу и предоставляет сервисы другим программам -- клиентам. Взаимодействие осуществляется путем механизма передачи сообщений -- микроядро передает сообщение от одной программы к другой. Каждая программа (тред, если точнее), идентифицируется Thread ID'ом. И вот, чтобы программы могли найти нужные серверы, служит служба разрешения имен. Есть Name Server, который по запросу по символьному имени сервиса возвращает TID соответствующего сервера. Имя-->число. В чем-то это аналогично DNS. Имена составляют Namespace. Namespace может быть плоским или иерархическим -- по типу доменных имен или имен файлов. Серверов имен может быть много, каждый отвечает за какую-то ветку Namespace. За корень дерева отвечает Root Name Server. В Namespace могут входить службы, файлы, конфигурационные параметры. Есть ветка Namespace, состоящая из имен файлов, есть из параметров конфигурации. Последние образуют Configuration Namespace -- аналог регистри. В отличие от виндового регистри, Configuration Namespace OS/2 PPC для каждого ключа содержало ACL (Access Control List) для защиты от несанкционированного доступа (кто попало не может писать в реестр). Также, существовали как постоянные (сохраняющиеся между перезагрузками) ключи реестра, так и transient ключи, которые содержат постоянно меняющуюся и не сохраняющуюся информацию. Также, в реестре была поддержка линков и Anonymous Namespaces, не прилинкованные к основному Name space -- они были доступны не глобально всей системы из корня, а определенному приложению или набору процессов (кажется так). Потом, совершенно необязательно делать как в windows, чтобы весь реестр состоял из нескольких файлов (Если один из этих файлов похерится, то кирдык всему). -- Можно сделать, например, чтобы реестр собирался из частей, генерируемых по текстовым исходникам (типа как .rc-->.ini в современной OS/2). Каждому приложению можно отвести отдельный файл реестра. В Namespace он будет выглядеть как ветка, а на диске это будет отдельный файл. Причем надо не разрешать прогам писать вне своего файла реестра, запретить это через ACL. В общем, это надо хорошо обдумать, но надо сделать так, чтобы получилась легко восстанавливаемая по частям система -- чтобы основной каркас реестра можно было легко восстановить.

Что касается config.sys, то для драйверов можно сделать возможность делать start и stop, но в сам config.sys сделать возможность только start'а командой device=. Просто config.sys считать legacy-фичей и оставить его только для совместимости. Из него делать только start, а для динамического start/stop можно сделать спец. менеджер драйверов, который стартует/останавливает драйвера при возникновении событий, например, при появлении/исчезновении ключа в registry. Для обработки таких событий сделать специальные скрипты (можно на рексе ;)).

> VIO regedit в этом случае - с меня - уже писал ;)
> Если есть идеи - как скрестить config.sys и start/stop driver - пожалуйста ;) Или можно сделать какой-то структурированный (менее бардачный) конфиг - тоже хорошо. И не надо, при этом, "стесняться" брать лучшее из других систем ;)


Уфф, длинно получилось, прошу прощения...
WBR,
Валерий


Tue 05 Jun 2007 15:56 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.