Никто из нас не может претендовать на место подобное Торвальдсу. Такое случается очень редко. Однако, конечно можно ерничать сколько угодно и строить фантастические планы подобно мышонку Брейну.

maximYCH wrote: Относительно встроенного ядра. Собственно, я не вижу в этом проблемы. Текущее ядро человека, который этим занимается, устраивает. Что мешает ему самому над ним дальше работать, учитывая, что только ему это и интересно и все остальные (!!) думают в противоположном направлении (микроядро)? В branches и все. Тем более, что до окончания проектировки я чувствую, ой как много ...
... путь Linux нам не повторить. Путь Windows тем более. Во встроенных и без нас есть, ну а среди нас и так есть, кто занимается этими вопросами. Я больше не вижу коммерческих путей развития.

Я не говорил, что "мне нравится текущее ядро", не надо ничего за других додумывать. Достаточно просто их выслушать.
То что все люди думают по-разному - не плохо.
Плохо, когда не думают.

Мне нравится сама идея монолитной Колибри и те уникальные фишки, которых ни в одной "нормальной" оси, связаной по рукам и ногам стандартами POSIX и RTOS, невозможно себе представить. Где еще можно организовать DMA без IRQ? А как в WinЦЕ или в Lynx без драйвера серверная карта может прочитать системную переменную или семафор? А как насчет прямой трансляции картинки из TV-карты в видеопамять? Только ДОС позволял подобные выгибоны, но - в Real Mode, и для одной-единственной задачи.

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

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

Но в сегодняшней Колибри это пока еще возможно, вот я и гребу против течения. Пока я один, до 'branches' дело не дойдет. Я ведь не программист, для меня разработать новую видеокарту легче, чем написать под нее приличный драйвер. Я лишь один из множества инженеров, которым позарез нужна Embedded-KOS как платформа для разработки, тестирования и внедрения новой электроники.

Уже много раз говорил, и еще раз повторю: самый быстрый путь к коммерциализации Колибри лежит через embedded-сектор.
Там - целый сектор вообще никем не занят:

Exotic custom operating systems

A small fraction of embedded systems require safe, timely, reliable or efficient behavior unobtainable with the one of the above architectures. In this case an organization builds a system to suit. In some cases, the system may be partitioned into a "mechanism controller" using special techniques, and a "display controller" with a conventional operating system. A communication system passes data between the two.

(взято отсюда: http://en.wikipedia.org/wiki/Embedded_system)

art_zh

А я вот пишу драйвер для видеокарты.
Для микроядра вообще фиолетово как общаются между собой драйвер и диспетчер устройств. А простота доступа к железу в Колибри с лихвой компенсируется отсутствием многих необходимых функций. Чтобы запустить звук пришлось переписать половину ядра. Для драйвера ATI тянуть из Линукс код работы с PCI. Нормально работать с IRQ можно только в ядре и так далее.

Serge wrote: Для микроядра вообще фиолетово как общаются между собой драйвер и диспетчер устройств.

Зато для железа не фиолетово, по какому адресу сейчас находится системный семафор. Даже при наличии драйвера ничто не может быть зафиксировано.

Serge wrote:А простота доступа к железу в Колибри с лихвой компенсируется отсутствием многих необходимых функций. Чтобы запустить звук пришлось переписать половину ядра. Для драйвера ATI тянуть из Линукс код работы с PCI. Нормально работать с IRQ можно только в ядре и так далее.

Чтобы претендовать на звание Embedded, надо будет переписать больше чем половину кода. (не вдруг и сразу, - шаг за шагом).
И разумеется добавить множество необходимых функций.
И все же это более реальная цель, чем микрокернел и даже netbook-OS.

art_zh

Какой семафор и где не может быть зафиксировано ?

Так проблема в том что проще написать заново чем переписать то что есть. Это всё равно что полностью заменить в многоэтажке пару этажей в середине и половину фундамента да ещё и подвал сделать. Да так чтобы жильцы и не заметели что что-то поменялось. Реально ?

Serge wrote: Какой семафор и где не может быть зафиксировано ?

Полная аналогия с системным семафором, только переключается не программным потоком/задачей, а реальным железом.
Для бесконфликтной работы 2 или нескольких равноправных задатчиков, сидящих на одной шине и разделяющих общий ресурс (например, общий блок системной памяти, или видеобуфер, или другое подчиненное устройство), им требуется опрос/установка некоего системного семафора.

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

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

Так что несовершенство Колибри кое-где вполне может быть компенсировано ее офигенно либеральной архитектурой.

Serge wrote: Так проблема в том что проще написать заново чем переписать то что есть. Это всё равно что полностью заменить в многоэтажке пару этажей в середине и половину фундамента да ещё и подвал сделать. Да так чтобы жильцы и не заметели что что-то поменялось. Реально ?

Сравнение с многоэтажкой - пусть и яркая, но всего лишь метафора. К тому же неубедительная. Горбачев тоже когда-то использовал ту же ложную метафору, и даже свой катастрофический эксперимент назвал "перестройкой". А китайцы просто работали, последовательно приводя в порядок тот бардак, который им достался от Кормчего. Причем многие "жильцы" там до сих пор думают, что все идет как и было им предначертано. (пардон за метафору

art_zh, разница лишь в том, что для Вашего ядра потребуется переписать половину и последовательно, а для ядра, к которому стремятся некоторые другие разработчики - все и с нуля. Кроме того, все что Вы описываете (по моему скромному мнению и определенным знаниям по архитектуре) порядком сложнее даже задачи переписки ядра.

art_zh
Наверное это неправильные оси.

art_zh wrote:Все что для этого требуется от системы - зафиксировать семафор в статическом блоке и передать устройству его физический адрес

Такой сервис есть в любом приличном ядре. В Линукс с этим точно нет проблем. Выделяется ДМА память, запрашивается физический адрес.

art_zh wrote:Горбачев тоже когда-то использовал ту же ложную метафору, и даже свой катастрофический эксперимент назвал "перестройкой"

Вот и я предлагаю не перестраивать а как китайцы построить новое. Рядом. На специально огороженной территории.

Меня например интересует быстрое микроядро с удобным доступом к железу. Для такого ядра проще сделать порт драйверов с Линукс. И систему проще сконфигурировать под любое применение. Некоторые разработкии в этом направлении у меня есть, правда под 32 бита.

Давайте соберем все за и против микроядра. Вещь звучит заманчиво, но правильная ли она в рамках KOS? Я не уверен.
Аргументы про безопасность и про возможность безболезненного восстановления серверов я считаю мифом.
Представьте себе падение драйвера (одного из, ведь для доступа к файлам получится цепочка из кучи серверов). Допустим его можно перезагрузить. Допустим мы сохраняем состояние драйвера перед его падением (когда оно еще работает нормально). Допустим это состояние корректно и актуально, т.е. при его восстановлении драйвер не упадет тут-же. Допустим ближайшие сервера готовы к падению близнеца и в состоянии подождать, когда он очухается. Уже понимаете к чему я клоню :-). А что будет с приложениями, которые в этот момент хотели читать/писать файл? Многие из вас обрабатывают ошибки ФС? Какая должно быть ошибка в такой ситуации? Или кто-то будет кешировать все запросы на запись в надежде что драйвер очухается и обработает их позже, что бы приложение продолжило функционировать. Или запрос будет отложен без возврата управления приложению, или всё-же специфическая ошибка.
Т.е., что бы этот аргумент состоялся, нужно выполнить прорву условий, к падению драйвера должны быть готовы все. Если я записываю только что напечатанных 1000 строк кода, а тут такой сюрприз, к которому приложение не было готово, то мне абсолютно пополам, что интернет-радио всё еще звучит и система проявляет признаки жизни :-).

А что можно сказать в пользу микроядра в данном проекте? Мне ничего не приходит на ум, что будет гарантированно лучше монолита.

POSIX. Зачем нам POSIX? Рассказать миф про стандарты и API в Linux :-) ? Простота переноса софта, например, с Linux. Ерунда. Многим из вас приходилось повышать версию glibc и при этом всё гарантированно продолжало работать? А что если вы вздумаете взять альтернативную libc, вешайтесь ребята :-). Софт сейчас пишется под совершенно определенные версии библиотек, а обратная совместимость в этих библиотеках организована крайне отвратительно. Так что при портировании чего-либо куда-либо всё равно понадобится активнейшее участие программиста с писанием как своего кода, так и исправлением чужого. Тогда зачем прогибаться под POSIX (что бы было приятно только сишникам)? Понадобится промежуточный код для портирования, но не стоит всю систему ломать под это мировоззрение.

Я понимаю Mario, но не могу полностью с ним согласиться. У KOS может быть реальное применение, возможно к этому стоит стремиться. Но я к данному проекту испытываю исключительно академический интерес (это хобби) и лично меня это полностью устраивает, т.е. дополнительно меня мотивировать ненужно. Возможно у остальных - иначе. Что касается применения KOS: Тонкие клиенты X, VNC, RPC и т.д., а почему нет, хотя с этим справится и Linux. Медийная коробка (Boxee), а почему нет, справится, без сомнения, так же как и Linux. Узкозаточенный сервер из коробки, например, СУБД на базе PostgreSQL, с минимальным обслуживанием для организаций без возможности держать админа с мозгом, можно и Linux присобачить :-). Лично меня все эти три варианта заинтересовали бы, как конечного потребителя.

p.s. Извините за многа букав. Хотел еще написать, что меня интересует в ОС, как прикладника, ну это потом.

p.p.s. Возвращаясь к борьбе с падающими приложениями, этот вопрос решается очень легко -- интерпретирующая ВМ, можно и с JIT компилятором. Тогда и адресное пространство изолировать нет большой необходимости. Мне так кажется.

..bw<