От модератора: Речь в этом посте идет о
проекте микроядра, но поскольку обсуждение отошло от темы, то некоторые посты перемещены в эту тему.
----------------------------------------------------------------------------------------
Почитал. На самом деле сколько-нибудь полноценным проектом это не является даже близко, и работать по такому документу нельзя (впрочем, автор и не утверждает обратного).
Как должно вестись проектирование системы? Попробую кратко изложить своё видение этого вопроса.
1. Очерчивается круг задач, для которых будет предназначена система -- как ближайший, так и в достаточно отдалённой перспективе.
2. Очерчивается аппаратная база, для которой она предназначается.
Эти два пункта служат "ограничителями" для всего остального проектирования, а в дальнейшем -- и для реализации. Например, если система предназначается только для использования в простых встраиваемых системах, можно не заморачиваться с поддержкой многопроцессорности (там это не нужно и, что самое важное, никогда не будет нужно -- специфика применения), не нужен Юникод (взаимодействие с пользователем очень ограничено опять-таки в связи со спецификой задачи) и т.д. Однако если система должна иметь возможность использоваться как десктопная, то, хошь-не хошь, а изволь ориентироваться не только на сегодняшний день, но в первую очередь на завтрашний, и именно для таких систем. В частности, неизбежной становится поддержка многопроцессорности (иных десктопов через 5 лет, пожалуй, уже и не будет -- некрофилов не рассматриваем), совершенно необходим Юникод (изобретать своё решение для проблемы представления всех мыслимых и немыслимых алфавитов никакого резона нет -- стандартизация в большинстве случаев важней, чем идеальность реализации), ну и т.д.
3. Определяется, какие системные сервисы предоставляются прикладному программисту. Например, могут ли две задачи совместно пользоваться одной и той же областью памяти? Частный случай предыдущего: могут ли они совместно использовать одну и ту же копию динамически загружаемой библиотеки? Как выдаются права на доступ и как (с точки зрения прикладника, подчёркиваю это) они контролируются? Каким образом между задачами поддерживаются отношения "родитель-потомок"? Каким образом задачи выполняют операции ввода-вывода? Ну и т.д. и т.п.
На выходе этой стадии получается некое "концептуальное руководство программиста" для создаваемой ОС. В частности, уже имеется описание функций API. Если же этого не сделать, то получаем принцип "сделай то -- не знаю что" (в частности, именно этим и является упомянутый мной в начале документ: автор, несомненно, имеет определённые представления о том, что он собирается сделать, но читателям-то это невдомёк, да и сам автор запутается, если всё не изложит по-человечески, ведь объём информации очень велик).
4. Выбирается архитектура системы (микроядро или монолитно-модульная конструкция, причём ещё надо определиться с терминологией, а то некоторые к микроядерным и Винду относят).
5. Вырабатываются принципы связи между различными компонентами системы, механизмы низкоуровневой синхронизации, разруливания прерываний и т.п.
6. Проектируются крупные "строительные блоки" системы -- менеджер памяти, менеджер ввода-вывода и т.д.
На выходе этого этапа получаем достаточно подробное описание функций каждого крупного "строительного блока" и спецификации их интерфейсов. В частности, имеем драйверную модель (именно ввод-вывод является самой сложной и запутанной частью любой более-менее развитой ОС).
7. И только теперь можно начать реализацию проекта.
Конечно, на каждом этапе возможно (а на п. 7 и неизбежно) возникновение ситуаций, когда что-то оказывается неясным или неподходящим. Тогда надо возвращаться назад и выполнять дополнительное проектирование (если что-то пропустили) или даже перепроектирование (если что-то оказалось в итоге спроектированным неправильно).