Обращение к разработчикам KolibriOS

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

    alman

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

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

    P.S.
    Я понимаю,что некоторые люди со мной не согласяться - это естественно. Каждый человек имеет право на своё мнение.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Я с Вами не спорю - у Колибри есть своя ниша.

    А как насчёт многопроцессорности? Технологии 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 генерирует программное исключение, которое приходит как событие в некий программный поток. Регистры процессора, инициирующего прерывание, приходит в следующей структуре:

    Code: Select all

    struc L4_EXCEPTION
    {
    	_MR0_ 		dd	?
    	_EIP_		dd	?
    	_EFLAGS_	dd	?
    	_ExceptionNo_	dd	?
    	_ErrorCode_	dd	?
    	_EDI_  		dd	?
    	_ESI_  		dd 	?
    	_EBP_  		dd 	?
    	_ESP_  		dd 	?
    	_EBX_  		dd 	?
    	_EDX_  		dd 	?
    	_ECX_  		dd 	?
    	_EAX_  		dd 	?
    }
    
    Чтобы взять указатель на эту структуру, достаточно выполнить одну команду:

    Code: Select all

    	mov	ebx,[gs:0]	; Get UTCB
    
    Дальше тривиально, анализируются поля _ExceptionCode_ (номер прерывания) и регистры, затем делается то, что должно делаться.

    Что касается нативных вызовов, то это тоже не сложно. Каждый процесс имеет так называемую область Kernel Interface Area (KIP), чтобы получить указатель на эту структуру данных, достаточно выполнить следующую команду:

    Code: Select all

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

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

    Теперь позвольте описать формат регистров, которые использует системный вызов IPC.

    Code: Select all

    Входные регистры:
    EAX - идентификатор потока, кому адресовано сообщение
    ECX - таймаут на приём/передачу сообщения.
    EDX - идентификатор потока, от которого ждать сообщения. 
    EDI  - указатель на UTCB (контрольный блок потока)
    
    Выходные регистры (после завершения IPC):
    EAX - идентификатор потока, приславшего сообщение
    ESI - виртуальный регистр 0
    EBX - виртуальный регистр 1
    EBP - виртуальный регистр 2
    
    IPC может включать две фазы - фазу передачи и фазу посылки сообщения.
    Например, если IPC только передаёт, но не принимает сообщение, то во входном регистре EDX должен быть указан 0.
    Если подразумевается ответ от потока, которому передавалось сообщение, то EDX должен быть равен регистру EAX.
    В случае, когда поток желает принять сообщение от любого потока, в EDX должно быть значение 0xFFFF.

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

    Кстати, несмотря на видимую сложность IPC, их использование может дать прирост в скорости. Я исхожу из того, что команда int - всегда исполняется медленно. В случае же использования IPC, если потоки находятся в одном адресном пространстве, может не происходить переключение контекста процессора и не сбрасываться TLB кэши. Что очень благоприятно влияет на быстродействие.
    Last edited by alman on Sat Oct 06, 2007 3:54 pm, edited 1 time in total.
  • alman
    Ты хочешь доказать, что эмуляция приложений Колибри для твоего ядра будет быстрей, чем работа приложения в самой Колибри с использованием программного прерывания?
    Тогда что ты возразишь насчет использования FAST CALL, которое уже реализовано для Колибри?
    Чего-то я не верю, что микроядро обеспечит более быструю работу приложений...
  • Who is online

    Users browsing this forum: No registered users and 3 guests