Board.KolibriOS.org

Official KolibriOS board
It is currently Fri Jul 23, 2021 8:23 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 296 posts ]  Go to page Previous 16 7 8 9 1020 Next
Author Message
PostPosted: Wed Feb 10, 2010 4:26 pm 
Offline

Joined: Sun Nov 04, 2007 2:46 am
Posts: 390
Serge, залей на SVN (в branches), пожалуйста.
Мог бы описать предполагаемую архитектуру на Wiki? А то получится, как сейчас - некому не охота разбираться с тонной сорцов ядра без документации.


Top
   
PostPosted: Wed Feb 10, 2010 5:19 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
maximYCH

Смысла заливать на svn пока нет. Архитектуры тоже нет. То что есть - кусок глины. Пока не затвердело можно лепить. Исходное ядро было рассчитано на SASOS и PE64 в качестве формата исполняемых файлов. Поэтому ядро расположено в начале адресного пространства (Весь код позиционно независим. Между программами и dll нет разницы, любой модуль может быть расшаренной dll). Если кому-то нравится начинать с программы с org 0, то не вопрос. OS_BASE и правка таблиц страниц (точнее _os_pml4 в start.S решит эту проблему). Возможная архитектура сильно зависит от формата исполняемых файлов (как не странно) а тот напрямую от инструментов разработки. Если определиться с выбором "чем делать ?" будет проще с "как делать ?". Вопрос "зачем ?" уже обсудили.


Top
   
PostPosted: Wed Feb 10, 2010 5:53 pm 
Serge wrote:
Архитектуры тоже нет. То что есть - кусок глины. Пока не затвердело можно лепить.

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


Top
   
PostPosted: Wed Feb 10, 2010 6:22 pm 
Offline

Joined: Wed Dec 26, 2007 5:09 am
Posts: 214
Любой достаточно квалифицированный программист сумеет за довольно короткое время и без особой подготовки выдать на-гора "прототип ОС", в котором будет присутствовать кой-какой базовый функционал. Однако даже самый гениальный программист, не имея детально проработанного проекта, при попытке развивать этот прототип до уровня пригодной для реального использования системы в конце концов неизбежно увязнет в куче всяких мелочей (так сказать, переход количества в качество): миллионы строк кода в голове не удержишь, даже десятки тысяч уже становятся проблемой. Ну а коллективная работа без проекта и вовсе невозможна (точней, возможна, но результат будет, как всегда) -- думаю, по всем понятным причинам.

"Микроядерность" отнюдь не является панацеей. Главная проблема при создании ОС -- это определение взаимосвязей отдельных компонентов, из которых складывается система . Например, какой путь в системе проходит запрос ввода-вывода, выданный некоей программой? Какие компоненты в его обработку вовлечены? Какие сервисы друг другу они должны для этого предоставлять?. Ответ на подобные вопросы для микроядерной архитектуры дать ничуть не проще, чем для монолитной; единственное, что даёт микроядерная архитектура для проектирования -- это стандартизирует "технический" интерфейс между различными модулями (в разумной системе не может быть полсотни механизмов передачи сообщений -- наверняка он будет один, а значит, все модули будут пользоваться этим единым механизмом). Но того же самого можно добиться и в монолитной системе: чётко оговорить соглашения о связях и неукоснительно их придерживаться. Больше пользы от микроядерной архитектуры во время отладки: поскольку разные компоненты системы выполняются в индивидуальных адресных пространствах, отладка оказывается проще (например, если компонент выполняет запись по ошибочному адресу, он либо сразу "упадёт", либо повредит сам себя, но не другой компонент, и при возникновении ошибки будет куда проще определить, кто же именно виноват; в подобной ситуации в монолитной системе ошибка может проявляться где угодно, но только не там, где она реально возникла). В то же время при одинаково грамотном проектировании и реализации монолит будет быстрее работать и занимать меньше памяти. В общем, можно успешно делать и микроядерную ОС, и монолитную -- но "технический" (в смысле -- не коммерческиий) успех процентов на 90, если не больше, определяется качеством её проектирования, а не архитектурой, использованным языком программирования, красивой графикой или ещё чем подобным.


Top
   
PostPosted: Wed Feb 10, 2010 6:23 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Ещё раз. У этого ядра никакой архитектуры нет. Есть набор программерских решений который можно сохранить, изменить или полностью выкинуть. Архитектура есть у системы. Но обсуждать сферическую шестидесятичетырёхбитную симметрично многопроцессорную операционную систему в вакууме пока не известно чем её делать, IMHO нет смысла


Top
   
PostPosted: Wed Feb 10, 2010 6:30 pm 
Offline

Joined: Wed Dec 26, 2007 5:09 am
Posts: 214
Serge

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


Top
   
PostPosted: Wed Feb 10, 2010 6:59 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
SII

На первый взгляд нет. Но если присмотреться все использующие ELF операционные системы похожи как две капли воды. Код позиционно-независим. Для управления памятью достаточно sbrk(). Отсюда непрерывные, перекрывающиеся адресные пространства на всю доступную память. Возьмём PE. GOT и PLT нет. Собрать все секции в непрерывный кусок нельзя. Для расшареных dll уже нужна глобальная куча адресов. Но если у нас 48 бит адресного пространства почему не сделать все адреса глобальными ? Черт, это уже совсем другая архитектура !
Так от второстепенного, на первый взгляд, вопроса зависит управление виртуальной памятью в системе.


Last edited by Serge on Wed Feb 10, 2010 8:10 pm, edited 1 time in total.

Top
   
PostPosted: Wed Feb 10, 2010 7:11 pm 
Offline

Joined: Wed Dec 26, 2007 5:09 am
Posts: 214
Ну, насчёт похожести "как две капли воды" Вы всё ж загнули. Много ли реально похожего между Linux и QNX? Они ж различаются практически всем, начиная с того, что Linux -- монолит, QNX -- микроядерная система. Общего у них, по сути, лишь то, что восходит к Юниксу -- причём обе системы Юниксом не являются.

Насчёт позиционной независимости. Собственно машинный код не может быть позиционно независимым, если процессор этого не обеспечивает -- а ИА-32 в целом не удовлетворяет этому требованию, хотя написать позиционно-независимую программу всё же можно -- ценой довольно значительных усилий со стороны программиста (грубо говоря, первым делом пихнуть в стек значение EIP, затем загрузить его в какой-либо РОН и в дальнейшем адресоваться только относительно этого РОНа). Если же говорить о возможности настройки программы на размещение в памяти по конкретным адресам во время загрузки, то РЕ это обеспечивает -- другое дело, что в реальных программах для Винды часто словарь перемещений выброшен, и тогда программа оказывается жёстко привязанной к базовому адресу, установленному компоновщиком (т.е. 400000). Но это не недостаток самого формата -- возможность перемещения, как я уже сказал, он даёт. Или Вы не об этом говорили?


Top
   
PostPosted: Wed Feb 10, 2010 7:35 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
SII

Я писал о самодельный осях, точнее об устройстве адресного пространства в таких системах. pe.exe и elf.exe привязаны к адресам и перемещать их нельзя, но elf.so и pe.dll каждый по-своему позиционно-независимы. Впрочем, если в системе не планируется расшареных dll это ещё одна архитектура.


Last edited by Serge on Wed Feb 10, 2010 7:45 pm, edited 1 time in total.

Top
   
PostPosted: Wed Feb 10, 2010 7:43 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Раз система пишется на C, то тут кроме gcc вариантов нет. В репозиториях Ubuntu есть кросс компилятор mingw.

_________________
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!


Top
   
PostPosted: Wed Feb 10, 2010 8:51 pm 
А кто сказал, что система пишется на Си? Я допускаю использование Си в отдельных случаях, когда это оправдано, но не поголовно. Если курс такой, то сдается мне, что мне будет не совсем по пути.


Top
   
PostPosted: Wed Feb 10, 2010 8:57 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1600
Mario79 wrote:
А кто сказал, что система пишется на Си? Я допускаю использование Си в отдельных случаях, когда это оправдано, но не поголовно. Если курс такой, то сдается мне, что мне будет не совсем по пути.

Аналогично.

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


Top
   
PostPosted: Wed Feb 10, 2010 9:04 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Ничего и не пишется. Но я считаю что вести разработку на асме - нступать на те же грабли, даже хуже. В конечном итоге получится очередная "hello_world_OS".


Top
   
PostPosted: Wed Feb 10, 2010 9:12 pm 
Да, а в случае использования чистого Си - мы безусловно получим рассово-верную ОС с проТукс'овыми корнями. :lol:
К тому же начало положено (как известно хорошее начало - половина дела) - очередное клепание без документирования...


Top
   
PostPosted: Wed Feb 10, 2010 9:16 pm 
Offline

Joined: Wed Dec 26, 2007 5:09 am
Posts: 214
Да здравствует холивар? :) Лично я ненавижу Си, Си++ и все си-подобные языки (хотя во время оно приходилось довольно много на них писать -- нольчайству, как известно, всегда видней); вообще, ИМХО, язык должен мешать совершать дурацкие ошибки, а не потворствовать им, ну а Си и иже с ним делают ровно наоборот: в них имеется масса способов случайно допустить ошибку, абсолютно невозможную на Паскале и паскалеподобных языках. По этой причине для себя я пишу почти исключительно на Дельфях (ну или на смеси Дельфей и асма, но это редко), ну а по работе сейчас буду писать на Аде -- потому что для АРМа найти вменяемый и бесплатный компилятор "строгого" языка проблематично (ФриПаскаль развивается не пойми как, плюс мне далеко не всё в нём нравится; иных для АРМа я вообще не знаю, ну а Ада входит в состав ГЦЦ со всеми вытекающими). Для ПК я бы ось тоже сначала писал бы на Аде, а затем, когда всё отлажено и работает, по мере возможности и необходимости переводил бы на асм. Ну а писать сразу на асме... Можно, но достаточно тяжело, да и, сдаётся мне, неоправданно на ранних этапах, когда основной упор идёт на расширение функционала и отладку, а не на оптимизацию.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 296 posts ]  Go to page Previous 16 7 8 9 1020 Next

All times are UTC+03:00


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 Limited