Board.KolibriOS.org

Здравствуйте,

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

Коллеги, вы проделали титанический труд, делая KolibriOS и достигли значительных результатов. Однако, посмотрите на будущее вашей системы - что будет через пять лет? Будете переписывать код под 64-битные платформы? А как ваша система будет работать на 4-х ядерных процессорах?

Я знаю, эти вопросы неприятны, но иногда их необходимо задавать. В юности я тоже писал ОС на ассемблере, но Интернет в то время не был так распространён как сейчас и соратников не нашлось. Поэтому я чётко представляю что Вы создаёте и сколько труда это требует. В любом случае затраченные усилия не пропадут - у вас появится великолепный опыт и возможность в будущем получить высокооплачиваемую работу.

Я пришёл с деловым предложением. У меня есть прототип операционной системы, написанный поверх микроядра L4 Pistachio. Возможно, Вы уже слышали об этом проекте. Я чётко осознаю, что одному написать систему не под силу, но не вижу людей, которые могли бы подключиться к проекту.

Итак, я предлагаю портировать некоторые драйвера KolibriOS для Xameleon. Понимаю, что это дерзкое предложение, но прежде чем гнать меня отсюда, пожалуйста, дайте договорить.

Если кто нибудь желает портировать какой-либо драйвер или приложение в систему Xameleon, окажу посильную помощь. Таким образом Вы дадите новую жизнь Вашему коду. Даже в случае забвения одной из систем, вероятность того что Ваш код продолжит жить - увеличивается. Язык программирования значение не имеет, это может быть как любой из ассемблеров для платформы x86, так и любой компилятор С/С++ и даже ObjectPascal. Если кто-нить всерьёз заинтересуется, то первое, что предоставлю - исходный код C/C++ Run Time library написанный на GNU asm.

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

С уважением,
Алексей Мандрыкин

Вопрос о 64 битной Колибри уже обсуждался. И пришли к выводу, что Kolibri32 и Kolibri64 будут совершенно разными системами(Если Kolibri64 появиться вообще). А здесь разрабатывается Kolibri32. Но это не значит, что она не будет работать на 64 битных процессорах.

alman

В общем случае, по мере развития компьютеров в них постоянно будет что-то меняться и постоянно придётся подстраивать систему под разработчиков железа. Может со временем и 64 битным системам придётся испытать то, то сейчас испытывают 32-х битные.
Если появяться квантовые оптические компьютеры, где информацию передают кванты света, а не электроны(как в современной электронике), то скорее всего их архитектура будет уже не x86. Хотя если народ воспротивиться этому, то сделают типа x86.

Я это всё к чему говорю. Если хочеться сделать платформенно независимую операционную систему, то надо не на ассемблере писать. А то, что написано на ассемблере зависит от железа и гнаться за всякими 64 битностями и многоядерностямии - бесполезно. Всёравно производители что-нибудь новое сделают и всёравно придётся всё переделывать. А покачто есть 32-х битные процессоры и компьютеры(и лет 20 точно будут, а возможно и больше) и для них текущая Колибри и пишеться.

P.S.
Я понимаю,что некоторые люди со мной не согласяться - это естественно. Каждый человек имеет право на своё мнение.

Я с Вами не спорю - у Колибри есть своя ниша.

А как насчёт многопроцессорности? Технологии Intel Hyper Threading уже несколько лет, а двухядерные процессоры уже обычное дело.

Колибри идёт на друхядерниках.
У меня Intel Core 2 Duo 6420. Не идёт - летает, родная

Leency wrote:Колибри идёт на друхядерниках.
У меня Intel Core 2 Duo 6420. Не идёт - летает, родная

Я имею в виду, при этом используются оба ядра или одно?

alman
Многоядерные процессоры и сами неплохо распределяют, кому что считать, делается это конечно не совсем эффективно и для повышения эффективности необходимы драйвера, но это не повод резать барашка который еще может накопить мясца.

alman, в свое время, в качестве хобби, я выбирал платформу для системного программирования, буквально для разработки ОС. В свое время, это даже в этом году. Рассматривал L4 Pistachio, твой проект, Minix3 и некоторые другие. Остановился на KolibriOS по причине наибольшей его завершенности в вопросе GUI и из-за наличия у проекта активного сообщества. Я и, думаю, многие другие разработчики KOS понимают что ядро требует реорганизации или даже полной замены на другое, но взяться за такой объем работы никто не готов. Можно попробовать на базе твоей разработки выращивать систему до уровня KOS, реализовать функциональность KOS и безболезненно перенести текущие программы и драйвера. Мне кажется такой сценарий наиболее правдоподобен.

..bw

alman wrote:Я имею в виду, при этом используются оба ядра или одно?

А какая разница если ОСь написана на асме и работает так что аж фуфайка заворачиваеццо.

Да и сколько реально ОСей\прог сейчас используют возможности друх ядер? Единици. Так что все остальные проги мёрнвые? Да даже таже самая ХР.

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

alman
Ссылку бы оставил хотябы, а то в гугл лезть...
Ладно, раз уж слазил http://www.l4os.ru/ ..

Нет доступных сырцов, имхо обречена...
Как пример тот же Миракуликс.
По мнению многих - ось лучше спроектирована, но комьюнити у неё 1-2 человека (насколько я знаю)...

alman wrote:Если кто-нить всерьёз заинтересуется, то первое, что предоставлю - исходный код C/C++ Run Time library написанный на GNU asm.

Есть встречное предложение - использовать CRT на асме для программ Колибри (dosbox, скажем) (конечно, если оно в итоге заметно меньше, чем CRT на Си). Переработку menuetlibc при условии наличия большей части Си-библиотеки я могу обеспечить сам. Как было справедливо замечено, шансы на долгую память у кода и разработчика повышаются при использовании в двух ОСях.

alman wrote:А как насчёт многопроцессорности? Технологии Intel Hyper Threading уже несколько лет, а двухядерные процессоры уже обычное дело.

Справедливое замечание. Но добавление многоядерности вряд ли затронет больше, скажем, 10% кода ядра, хотя, безусловно, потребует значительных изменений.

Mario79 wrote:Многоядерные процессоры и сами неплохо распределяют, кому что считать, делается это конечно не совсем эффективно и для повышения эффективности необходимы драйвера, но это не повод резать барашка который еще может накопить мясца.

По моим сведениям (которые, впрочем, могут быть неточны или неверны), в многоядерных процессорах, как и в многопроцессорных системах, дополнительные ядра сами по себе не делают ничего, пока им ничего специально не говорят.

Leency wrote:Да и сколько реально ОСей\прог сейчас используют возможности друх ядер? Единици. Так что все остальные проги мёрнвые? Да даже таже самая ХР.

Берём ту же XP на двухядерном процессоре. Пишем любую расчетную программу. Она занимает только один процессор и соответственно только 50% ресурсов системы. Разбиваем расчетный код на два потока (допустим, алгоритм позволяет распараллеливание). Теперь программа занимает оба процессора и исполняется примерно вдвое быстрее (примерно - потому что распараллеливание даром не проходит никогда). Так что сейчас огромное количество усилий при разработке алгоритмов уходит на возможности распараллеливания. То же самое под Колибри ничего не даст.

diamond

По моим сведениям (которые, впрочем, могут быть неточны или неверны), в многоядерных процессорах, как и в многопроцессорных системах, дополнительные ядра сами по себе не делают ничего, пока им ничего специально не говорят.

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

А как быть с играми... В ноябре ожидается прилив новых игрушек, и у каждой в рекомендуемых требованиях будут 2-х ядерники... По моему игры, это единственное на сегодняшний день для чего эти процы нужны вообще...

Коллеги, вчера реализовал поддержку исполняемых файлов формата MENUET/KOLIBRI в Xameleon.
В результате мне удалось запустить распакованую программу TEST (прогу взял с диска Koilbri). Это значит, что программы, собранные FASM, могут запускаться на Xameleon.

В результате, получил #General Protection fault на первом вызове Int 0x40. Впрочем, это совершенно нормальное поведение.
В принципе, можно пойти двумя путями:
1. Реализовать поддержку системных вызовов Kolibri в Xameleon.
2. Написать DevKit на FASM, с поддержкой системных вызовов Xameleon.

Можно использовать и оба пути.

В первом случае, для эмулирования Kolibri достаточно одного развязывающего программного потока. В соответствии со спецификацией L4, любой вызов Int генерирует программное исключение, которое приходит как событие в некий программный поток. Регистры процессора, инициирующего прерывание, приходит в следующей структуре:
Чтобы взять указатель на эту структуру, достаточно выполнить одну команду:
Дальше тривиально, анализируются поля _ExceptionCode_ (номер прерывания) и регистры, затем делается то, что должно делаться.

Что касается нативных вызовов, то это тоже не сложно. Каждый процесс имеет так называемую область Kernel Interface Area (KIP), чтобы получить указатель на эту структуру данных, достаточно выполнить следующую команду:
После выполнения этой команды, в регистре EAX будет указатель на KIP. KIP имеет много различных полей, но в данном случае нам интересны поля, начинающиеся со смещения от 0xD0 до 0xFF. Этих ячейках находятся адреса системных вызовов микроядра. В подавляющем большинстве случаев, нам интересен вызов IPC (смещение от начала KIP - 0xE0), который служит для обмена синхронными сообщениями между потоками.

В простейшем случае, его можно использовать вместо Int. Т.е. для того чтобы выполнить какую либо системную функцию, достаточно установить соответствующие регистры и передать управление по адресу со смещением 0xE0 относительно KIP. Как я уже говорил, адрес KIP всегда можно найти при помощи команды lock nop.

Теперь позвольте описать формат регистров, которые использует системный вызов IPC.
IPC может включать две фазы - фазу передачи и фазу посылки сообщения.
Например, если IPC только передаёт, но не принимает сообщение, то во входном регистре EDX должен быть указан 0.
Если подразумевается ответ от потока, которому передавалось сообщение, то EDX должен быть равен регистру EAX.
В случае, когда поток желает принять сообщение от любого потока, в EDX должно быть значение 0xFFFF.

Пожалуй, для начала немало информации. Перечитал этот пост, написано где-то на троечку. Впрочем, я готов ответить на вопросы, если они появятся.

Кстати, несмотря на видимую сложность IPC, их использование может дать прирост в скорости. Я исхожу из того, что команда int - всегда исполняется медленно. В случае же использования IPC, если потоки находятся в одном адресном пространстве, может не происходить переключение контекста процессора и не сбрасываться TLB кэши. Что очень благоприятно влияет на быстродействие.

alman
Ты хочешь доказать, что эмуляция приложений Колибри для твоего ядра будет быстрей, чем работа приложения в самой Колибри с использованием программного прерывания?
Тогда что ты возразишь насчет использования FAST CALL, которое уже реализовано для Колибри?
Чего-то я не верю, что микроядро обеспечит более быструю работу приложений...