OSDev

Ну вот, опять... ACPI -- это не поддержка разных режимов электропитания, это стандарт на то, как программно определять конфигурацию устройств материнской платы и управлять всеми этими устройствами (в первую очередь в плане электропитания и производительности). Ну а то, что у ARM имеются разные возможности питания -- это понятно, но к ACPI это отношения не имеет. Точно так же у процессоров архитектуры IA-32 есть такие возможности -- но это не ACPI, хотя ACPI этими возможностями пользуется, чтобы управлять питанием процессоров. Т.е. Вы смешиваете возможности аппаратуры и наличие стандарта на программное использование этих возможностей. Для ARM такого стандарта по существу нет: не существует способа программно определить набор внешних устройств, входящих в состав микроконтроллера, не существует стандартов на то, как именно производится управление питанием этих устройств, не существует стандарта на способ переключения частоты работы процессора и т.д.

Ты видимо имеешь ввиду программу, состоящую из одной функции? Я бы не стал называть это программой. Программа - это синоним алгоритму, производящему несколько вычислений. Например, ХеллоВорлд без использования стандартной библиотеки - как раз ядерный случай. И тут уже возникают различные подводные камни с видеопамятью и видеорежимами. В общем, некий вырожденный случай ни о чём не говорит. И ещё есть проблема в сильном дроблении программы на процедуры, потому что возникает множество взаимовлияний, особенно если процедуры с побочными эффектами (с внутренними или внешними состояниями). Ещё придётся обеспечивать устойчивость к гонкам у каждой процедуры по отдельности, что превращает программу в "матрицу".

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

Так в случае микроядра её и не будет. В микроядре даже нет API работы с ФС. Причём в версии для любой архитектуры. Нужен GUI - запускаем нужный сервис, а прикладные программы находят его и с помощью IPC просят его создать окно, перерисовать и т. п. При этом ядро понятия не имеет ни про видео-режим, ни про файловую систему. Под универсальным API я имел ввиду API, который содержит:
- Менеджер памяти (выделение, освобождение)
- Менеджер обработки исключений (установка обработчиков деления на ноль и т. п.)
- Менеджер процессов (создание, завершение, приостановка, отправка и приём сообщений)
- Менеджер прерываний (возможность заставить ядро посылать сообщения через IPC при приходе определённого прерывания)
Максимум, что сюда можно добавить - механизм разграничения прав доступа. Такой набор API можно реализовать на любой архитектуре и лишних функций в нём не найдётся. А реализовать всё прочее (драйвер ФС, менеджер окон) вполне возможно на основе этого API

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

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

Кстати, в дискуссии не затронут такой вопрос, как хранение данных, т.е. то, что сейчас называется Файловой Системой. Некоторые товарсчи хотят отменить файлы вовсе (http://www.dz.ru/solutions/phantom/).
На мой взгляд, нужно обобщить понятие ФС и перейти от файлов к объектам. Хотя бы к объектам со статическими свойствами.

Зависит от задачи. В простом микроконтроллерном приложении ФС зачастую не нужна вообще никак, ну а если и нужна, то вполне классическая, без наворотов -- нефиг ресурсы на это тратить. В общем, гибкость, гибкость и ещё раз гибкость :)

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

А все части ОС взаимосвязаны. Во всяком случае, некоторые проблемы нужно хотя бы обозначить. Для меня понятие идеальной ОС чётко связано с организацией хранения данных.

Это понятно, но без ядра ос и системы хранения данных не будет, она крутится на ядре, а не ядро на ней. До системы хранения данных мы дойдем. Система хранения данных не особо то и зависит от ядра

ОС phantom только компрометирует мой ник, не более того. Если я не прав, убедите меня в обратном. Про ФС говорить можно много. Я убежден лишь в одном, новая ОС должна стать результатом реализации множества новых идей, иначе от нее не будет никакого толка. Лично меня устраивает концепция файла. Основные мои исследования сосредоточены в области VFS и файловых операций.