Новая ветка ядра

Kernel architecture questions
  • maximYCH

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

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

    Инструментарий -- вещь, конечно, важная, но он никоим образом архитектуру системы не определяет. Он сказывается лишь на совершенно "технических" моментах, в первую очередь на соглашениях о связях (если используемый компилятор передаёт параметры таким-то образом, то придётся использовать именно этот способ, даже если он не является оптимальным). Ну а как формат загрузочных файлов влияет на архитектуру -- хоть убейте, не пойму. Нет, я понимаю, что выбор определённого формата может накладывать некоторые ограничения на некоторые архитектурные решения, но в целом существенного влияния я не вижу Ну и, кроме того, ничто не мешает при необходимости создать свой формат -- в конце концов, написать свой компоновщик многократно проще, чем ОС.
  • 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.
  • Ну, насчёт похожести "как две капли воды" Вы всё ж загнули. Много ли реально похожего между Linux и QNX? Они ж различаются практически всем, начиная с того, что Linux -- монолит, QNX -- микроядерная система. Общего у них, по сути, лишь то, что восходит к Юниксу -- причём обе системы Юниксом не являются.

    Насчёт позиционной независимости. Собственно машинный код не может быть позиционно независимым, если процессор этого не обеспечивает -- а ИА-32 в целом не удовлетворяет этому требованию, хотя написать позиционно-независимую программу всё же можно -- ценой довольно значительных усилий со стороны программиста (грубо говоря, первым делом пихнуть в стек значение EIP, затем загрузить его в какой-либо РОН и в дальнейшем адресоваться только относительно этого РОНа). Если же говорить о возможности настройки программы на размещение в памяти по конкретным адресам во время загрузки, то РЕ это обеспечивает -- другое дело, что в реальных программах для Винды часто словарь перемещений выброшен, и тогда программа оказывается жёстко привязанной к базовому адресу, установленному компоновщиком (т.е. 400000). Но это не недостаток самого формата -- возможность перемещения, как я уже сказал, он даёт. Или Вы не об этом говорили?
  • 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.
  • Раз система пишется на C, то тут кроме gcc вариантов нет. В репозиториях Ubuntu есть кросс компилятор mingw.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • А кто сказал, что система пишется на Си? Я допускаю использование Си в отдельных случаях, когда это оправдано, но не поголовно. Если курс такой, то сдается мне, что мне будет не совсем по пути.
  • Mario79 wrote:А кто сказал, что система пишется на Си? Я допускаю использование Си в отдельных случаях, когда это оправдано, но не поголовно. Если курс такой, то сдается мне, что мне будет не совсем по пути.
    Аналогично.
    Ушёл к умным, знающим и культурным людям.
  • Ничего и не пишется. Но я считаю что вести разработку на асме - нступать на те же грабли, даже хуже. В конечном итоге получится очередная "hello_world_OS".
  • Да, а в случае использования чистого Си - мы безусловно получим рассово-верную ОС с проТукс'овыми корнями. :lol:
    К тому же начало положено (как известно хорошее начало - половина дела) - очередное клепание без документирования...
  • Да здравствует холивар? :) Лично я ненавижу Си, Си++ и все си-подобные языки (хотя во время оно приходилось довольно много на них писать -- нольчайству, как известно, всегда видней); вообще, ИМХО, язык должен мешать совершать дурацкие ошибки, а не потворствовать им, ну а Си и иже с ним делают ровно наоборот: в них имеется масса способов случайно допустить ошибку, абсолютно невозможную на Паскале и паскалеподобных языках. По этой причине для себя я пишу почти исключительно на Дельфях (ну или на смеси Дельфей и асма, но это редко), ну а по работе сейчас буду писать на Аде -- потому что для АРМа найти вменяемый и бесплатный компилятор "строгого" языка проблематично (ФриПаскаль развивается не пойми как, плюс мне далеко не всё в нём нравится; иных для АРМа я вообще не знаю, ну а Ада входит в состав ГЦЦ со всеми вытекающими). Для ПК я бы ось тоже сначала писал бы на Аде, а затем, когда всё отлажено и работает, по мере возможности и необходимости переводил бы на асм. Ну а писать сразу на асме... Можно, но достаточно тяжело, да и, сдаётся мне, неоправданно на ранних этапах, когда основной упор идёт на расширение функционала и отладку, а не на оптимизацию.
  • Who is online

    Users browsing this forum: No registered users and 7 guests