Board.KolibriOS.org

Official KolibriOS board
It is currently Tue Nov 25, 2014 3:06 am

All times are UTC + 2 hours [ DST ]




Post new topic Reply to topic  [ 44 posts ]  Go to page 1 2 3  Next
Author Message
PostPosted: Thu Oct 04, 2007 3:06 pm 
Здравствуйте,

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

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

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

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

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

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

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

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


Top
  
 
PostPosted: Thu Oct 04, 2007 3:30 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Location: Россия(город Казань и село Полянки)
Вопрос о 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!


Top
 Profile  
 
PostPosted: Thu Oct 04, 2007 3:40 pm 
Я с Вами не спорю - у Колибри есть своя ниша.

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


Top
  
 
PostPosted: Thu Oct 04, 2007 3:42 pm 
Offline
Designer
User avatar

Joined: Thu Jan 25, 2007 3:33 pm
Posts: 3316
Location: Ukraine, Zhitomyr
Колибри идёт на друхядерниках.
У меня Intel Core 2 Duo 6420. Не идёт - летает, родная :)

_________________
Сижу в углу и тихо ем радугу.


Top
 Profile  
 
PostPosted: Thu Oct 04, 2007 3:47 pm 
Leency wrote:
Колибри идёт на друхядерниках.
У меня Intel Core 2 Duo 6420. Не идёт - летает, родная :)


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


Top
  
 
PostPosted: Thu Oct 04, 2007 3:49 pm 
alman
Многоядерные процессоры и сами неплохо распределяют, кому что считать, делается это конечно не совсем эффективно и для повышения эффективности необходимы драйвера, но это не повод резать барашка который еще может накопить мясца.


Top
  
 
PostPosted: Thu Oct 04, 2007 4:01 pm 
Offline
User avatar

Joined: Thu Mar 01, 2007 4:16 pm
Posts: 426
Location: Усть-Илимск
alman, в свое время, в качестве хобби, я выбирал платформу для системного программирования, буквально для разработки ОС. В свое время, это даже в этом году. Рассматривал L4 Pistachio, твой проект, Minix3 и некоторые другие. Остановился на KolibriOS по причине наибольшей его завершенности в вопросе GUI и из-за наличия у проекта активного сообщества. Я и, думаю, многие другие разработчики KOS понимают что ядро требует реорганизации или даже полной замены на другое, но взяться за такой объем работы никто не готов. Можно попробовать на базе твоей разработки выращивать систему до уровня KOS, реализовать функциональность KOS и безболезненно перенести текущие программы и драйвера. Мне кажется такой сценарий наиболее правдоподобен.

..bw


Top
 Profile  
 
PostPosted: Thu Oct 04, 2007 4:01 pm 
Offline
Designer
User avatar

Joined: Thu Jan 25, 2007 3:33 pm
Posts: 3316
Location: Ukraine, Zhitomyr
alman wrote:
Я имею в виду, при этом используются оба ядра или одно?
А какая разница если ОСь написана на асме и работает так что аж фуфайка заворачиваеццо.

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

_________________
Сижу в углу и тихо ем радугу.


Top
 Profile  
 
PostPosted: Thu Oct 04, 2007 4:08 pm 
Господа, спасибо за ответы в этой теме. В любом случае я надеюсь на взаимовыгодное сотрудничество и дружбу между проектами.


Top
  
 
PostPosted: Thu Oct 04, 2007 6:09 pm 
Offline

Joined: Mon May 01, 2006 10:12 pm
Posts: 349
Location: Санкт-Петербург
alman
Ссылку бы оставил хотябы, а то в гугл лезть...
Ладно, раз уж слазил http://www.l4os.ru/ .. :)

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

_________________
Image


Top
 Profile  
 
PostPosted: Thu Oct 04, 2007 8:20 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Location: Москва
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% ресурсов системы. Разбиваем расчетный код на два потока (допустим, алгоритм позволяет распараллеливание). Теперь программа занимает оба процессора и исполняется примерно вдвое быстрее (примерно - потому что распараллеливание даром не проходит никогда). Так что сейчас огромное количество усилий при разработке алгоритмов уходит на возможности распараллеливания. То же самое под Колибри ничего не даст.

_________________
Ушёл к умным, знающим и культурным людям.


Top
 Profile  
 
PostPosted: Thu Oct 04, 2007 9:00 pm 
diamond
Quote:
По моим сведениям (которые, впрочем, могут быть неточны или неверны), в многоядерных процессорах, как и в многопроцессорных системах, дополнительные ядра сами по себе не делают ничего, пока им ничего специально не говорят.

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


Top
  
 
PostPosted: Fri Oct 05, 2007 8:03 pm 
Offline
User avatar

Joined: Sat Mar 04, 2006 12:53 am
Posts: 221
Location: Кропоткин, Новочеркасск
А как быть с играми... В ноябре ожидается прилив новых игрушек, и у каждой в рекомендуемых требованиях будут 2-х ядерники... По моему игры, это единственное на сегодняшний день для чего эти процы нужны вообще...


Top
 Profile  
 
PostPosted: Sat Oct 06, 2007 3:36 pm 
Коллеги, вчера реализовал поддержку исполняемых файлов формата MENUET/KOLIBRI в Xameleon.
В результате мне удалось запустить распакованую программу TEST (прогу взял с диска Koilbri). Это значит, что программы, собранные FASM, могут запускаться на Xameleon.

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

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

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

Code:
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:
   mov   ebx,[gs:0]   ; Get UTCB


Дальше тривиально, анализируются поля _ExceptionCode_ (номер прерывания) и регистры, затем делается то, что должно делаться.

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

Code:
       lock nop


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

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

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

Code:
Входные регистры:
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.

Top
  
 
PostPosted: Sat Oct 06, 2007 3:52 pm 
alman
Ты хочешь доказать, что эмуляция приложений Колибри для твоего ядра будет быстрей, чем работа приложения в самой Колибри с использованием программного прерывания?
Тогда что ты возразишь насчет использования FAST CALL, которое уже реализовано для Колибри?
Чего-то я не верю, что микроядро обеспечит более быструю работу приложений...


Top
  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 44 posts ]  Go to page 1 2 3  Next

All times are UTC + 2 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Mobile version