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

Kernel architecture questions
  • От модератора: Речь в этом посте идет о проекте микроядра, но поскольку обсуждение отошло от темы, то некоторые посты перемещены в эту тему.

    ----------------------------------------------------------------------------------------

    Почитал. На самом деле сколько-нибудь полноценным проектом это не является даже близко, и работать по такому документу нельзя (впрочем, автор и не утверждает обратного).

    Как должно вестись проектирование системы? Попробую кратко изложить своё видение этого вопроса.

    1. Очерчивается круг задач, для которых будет предназначена система -- как ближайший, так и в достаточно отдалённой перспективе.

    2. Очерчивается аппаратная база, для которой она предназначается.

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

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

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

    4. Выбирается архитектура системы (микроядро или монолитно-модульная конструкция, причём ещё надо определиться с терминологией, а то некоторые к микроядерным и Винду относят).

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

    6. Проектируются крупные "строительные блоки" системы -- менеджер памяти, менеджер ввода-вывода и т.д.

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

    7. И только теперь можно начать реализацию проекта.

    Конечно, на каждом этапе возможно (а на п. 7 и неизбежно) возникновение ситуаций, когда что-то оказывается неясным или неподходящим. Тогда надо возвращаться назад и выполнять дополнительное проектирование (если что-то пропустили) или даже перепроектирование (если что-то оказалось в итоге спроектированным неправильно).
  • Serge

    Увы, таких примеров очень много.
    Но есть и другие примеры:
    viewtopic.php?f=1&t=662
    (можно спорить насколько важен оказался результат в данном частном случае, но все-таки это был настоящий коллективный мозговой штурм)

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

    Поверь, в твоих чрезмерно лаконичных и отрывочных тезисах очень сложно разобраться, надо лезть в код.
    А на это не у всех есть время и желание. К тому же у многих - ярко выраженная идиоСИнкразия.
  • Вот по такому плану пишутся GNU Hurd или Duke Nukem Forever.
    Собрались мужики, посовещались, составили подробный проект и сели писать код. И пока писали ВНЕЗАПНО появились PCI, SMP, ACPI, USB, HotPlug, виртуализация. И прект встал. А остальным приходится работать методом последовательных приближений. Когда Торвальдс выложил первые исходники там и обработчиков исключений нормальных не было. И ничего, постепенно появилось всё. Проблема Колибри не в том что она криво спланирована и написана как Бог на душу положит, а в ассемблере. Затраты времени на исправление и улучшение слишком велики.
  • SII
    Поправочка к примеру из п.2

    Простая встраиваемая система (мы здесь говорим об операционной системе, так?) часто требуется чтобы выжать "из железа" максимум производительности (пример - управление крылатой ракетой автономное идентификационное устройство с корреляционным распознаванием образов). Поддержка многопроцессорности здесь очень даже не помешает.
    Так что фразами типа
    там это не нужно и, что самое важное, никогда не будет нужно --
    я бы не бросался.
  • art_zh

    О каких модулях идёт речь?

    Насчёт документации согласен, расписывать всё долго и подробно ненавижу.
  • Serge
    Не соглашусь. Если разработчики упомянутых проектов не в состоянии довести их до ума -- так это их проблемы. Если появление перечисленных Вами аппаратных прибамбасов развалило их проект -- значит, он был недостаточно гибким (ну или они просто поленились переработать в достаточной степени).

    art_zh
    Я не даром написал "простая". Распознавание образов -- вряд ли простая система (во всяком случае, я её к таковым не отношу: это не опрос 20 термодатчиков и 30 манометров с последующей отправкой обработанной инфы по сети на дисплюй главного технолога). Кроме того, Вы прекрасно понимаете, что таких систем -- мизер по сравнению с общим количеством, а поэтому целью может быть создание ОС, подходящей для основной массы применений, но не годящейся для какой-то ограниченной части (из серии "овчинка не стоит выделки" -- трудозатраты велики и не окупятся возможной прибылью, например). Ну и, наконец, этот пример -- не более, чем просто иллстрация мысли о том, что надо сначала определиться в целью, а потом уж проектировать и тем более реализовывать, а не сначала что-то слепить, а потом пытаться его к чему-нибудь приспособить.
  • Serge

    devman, ddk, atikms и др. - каким компилятором пользоваться и какие библиотеки подключать, чтоб не сильно париться?

    На http://kolibrios.org/load.cgi?f/release ... 7.0_sdk.7z всякой всячины полно, а как и с чем работать - до сих пор не въехал :oops:
  • SII wrote:Я не даром написал "простая". Распознавание образов -- вряд ли простая система...
    А я не даром подчеркнул "операционная".
    Даже совершенно примитивная ОС вполне может обеспечивать решение чудовищно сложных практических задач. Опрос 20 датчиков или полноценное техническое зрение - это уже заботы конкретного приложения.
    SII wrote: Кроме того, Вы прекрасно понимаете, что таких систем -- мизер по сравнению с общим количеством, а поэтому целью может быть создание ОС, подходящей для основной массы применений, но не годящейся для какой-то ограниченной части (из серии "овчинка не стоит выделки" -- трудозатраты велики и не окупятся возможной прибылью, например).
    Идущее после слова "поэтому" утверждение никак не следует из первой части Вашей фразы.
    В ряде случаев целью создания (вариант: глубокой переделки существующей) ОС может быть не просто "ограниченная часть" применений, а одно-единственное применение.
    И это заказчику решать, окупятся ли его затраты возможной прибылью или нет.
    Ну и, наконец, этот пример -- не более, чем просто иллстрация мысли о том, что надо сначала определиться в целью, а потом уж проектировать и тем более реализовывать, а не сначала что-то слепить, а потом пытаться его к чему-нибудь приспособить.
    Да, надо определиться с целью. Хорошенько обдумать многие принципиальные вопросы, включая 6 перечисленных Вами.

    И прежде чем браться за нечто совершенно новое - прикинуть, не разумнее ли будет попытаться довести до ума то, что кто-то уже худо-бедно слепил?
  • (с) бред - удалено автором
    Last edited by VaStaNi on Fri Jan 02, 2015 5:04 pm, edited 1 time in total.
  • (с) бред - удалено автором
    Last edited by VaStaNi on Fri Jan 02, 2015 5:04 pm, edited 1 time in total.
  • (с) бред - удалено автором
    Last edited by VaStaNi on Fri Jan 02, 2015 5:04 pm, edited 1 time in total.
  • (с) бред - удалено автором
    Last edited by VaStaNi on Fri Jan 02, 2015 5:04 pm, edited 1 time in total.
  • Чувствую опять все закончится тем, что большинство уйдет на полгода в астрал... до следующей "течки".
  • Ну, я в разработке КОС никаким боком-раком не участвую, но в случае чего (т.е. нормального проектирования с нуля без попыток сохранения совместимости на уровне ядра и т.п.) сие возможно, а поэтому на всякий случай опишу свою кочку зрения.

    Архитектура: монолитно-модульное ядро, но драйверы могут реализовываться как в виде модулей ядра, так и в виде задач прикладного уровня (выбирается исходя из целесообразности: высокоуровневый драйвер файловой системы, скорее всего, будет выполнен в виде задачи, а вот низкоуровневый драйвер, непосредственно обслуживающий устройство, -- в виде модуля ядра).

    Средства реализации: ассемблер для модулей ядра, ассемблер или надёжный язык (на практике -- Паскаль и/или Ада, поскольку сколько-нибудь вменяемую реализацию Модулы или Оберона найти проблематично, да и известны народу они куда хуже Паскаля) для кода пользовательского режима и, возможно, части кода ядра (во всяком случае, пока идёт написание и отладка логики; впоследствии можно и переписать вручную на ассемблер, если это будет сочтено полезным). Категорически не приемлю Си/Си++: это лишь источник трудноуловимых глюков, а читабельности по сравнению с асмом почти не добавляет (а при неумеренном использовании возможностей сваливать всю в одну кучу -- даже уменьшает).

    Требования к системе: обязательная поддержка 64-разрядных процессоров, многопроцессорности, PnP, ACPI, в близкой перспективе -- UEFI... В общем, всего того, что необходимо для полноценной десктопной системы. В то же время считаю, что система должна строиться так, чтобы она могла работать и в качестве ОСРВ (в первом приближении это сводится к тому, что время её реакции на прерывания должно быть предсказуемым: для любого заранее известного набора оборудования должна иметься возможность точно посчитать наихудшее возможное время от поступления запроса на прерывание от конкретного устройства до начала выполнения первой команды обработчика этого прерывания).

    Замечу также, что в моём "плане" (который озвучил где-то в другом месте) даже выбор архитектуры, не говоря уже о средствах реализации, выполняется весьма и весьма поздно: для одного и того же АПИ можно написать и монолитную систему, и микроядерную -- приложениям это абсолютно пофиг.
  • Who is online

    Users browsing this forum: Yandex [Bot] and 5 guests