Board.KolibriOS.org

И кстати умный Торвальдс занимается только ядром и не лезет ни в какие ниши.

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

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

Мне нравится сама идея монолитной Колибри и те уникальные фишки, которых ни в одной "нормальной" оси, связаной по рукам и ногам стандартами 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)

_________________
Евангелие от Иоанна: стих 1

Code:

; В начале было Слово:
B32:        mov     ax, os_stack       ; Selector for os

art_zh

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

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

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

_________________
Евангелие от Иоанна: стих 1

Code:

; В начале было Слово:
B32:        mov     ax, os_stack       ; Selector for os

art_zh

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

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

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

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

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

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

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

_________________
Евангелие от Иоанна: стих 1

Code:

; В начале было Слово:
B32:        mov     ax, os_stack       ; Selector for os

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

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

Меня например интересует быстрое микроядро с удобным доступом к железу. Для такого ядра проще сделать порт драйверов с Линукс. И систему проще сконфигурировать под любое применение. Некоторые разработкии в этом направлении у меня есть, правда под 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

bw

POSIX это на 90% процентов libc. Не нравится libc не используй её, но во многих проектах без неё никуда. Ffmpeg без неё не скомпилируешь а значит никаких плееров. Маленький проект ещё можно переписать на родной api, а большой ? Кто будет возиться ?

Нормально у меня завелся и XviD (что я продемонстрировал в своё время) и FFmpeg. Без POSIX :-). Реализовал лишь (на самом деле просто мосты навел) необходимые минимальные зависимости. Я надеюсь моё мнение по вопросу поддержки какого-то API, только лишь для упрощения портирования приложений под KOS глупостью. Не глупостью считаю анализ существующего API или разработка своего, соответствующего нашим потребностям сегодня, а не тем что были 20 лет назад, и принятие взвешенного решения об использовании этого API. Возвращаясь к простоте портирования, что-то не наблюдаю я тонный перенесенного софта с Linux под Minix3, хотя, вроде бы, оба POSIX придерживаются, к чему бы это. Это благодатная почва для споров, но врядли я что-то смогу добавить, так что воздержусь от комментариев в дальнейшем :-).

p.s.
> а большой
Ээээ. Не думаю, что из KOS когда-либо получится система, способная полноценно заменить существующие десктопы, о каких таких больших проектах речь? Перенос отдельных библиотек неизбежен, это да, но их нельзя назвать большими проектами. Кто будет переносить DBus? А зачем? Уточни про большие проекты.

..bw

bw

Например gcc с утилитами .
Эти минимальные зависимости тоже POSIX. Маленькая часть. Я же не говорю что надо делать 100% совместимую систему. Просто не надо усложнять жизнь тем кому эти возможности необходимы.

В моём представлении у микроядра должен быть свой минимальный API и приложения не должны обращаться к нему напрямую. Потому что там очень специализированный набор вызовов. Привычная для всех функциональность должна реализовываться в системных dll. native.api posix.api gui.api и т.п. Системная dll превратит open() или create_window() в запрос к нужному сервису, конвертирует результат и обработает ошибки в случае необходимости.

Я в принципе за микроядро, но без жесткой привязки к POSIX - распухание кода можно избежать даже используя ЯВУ, но зачем наследовать мусор? Миф про перенос видимо очень болезненный для некоторых программистов. Ожидание чуда, но никакого чуда не наблюдается. Сколько не наблюдаю на каждой ОС свои приложения написанные по сути с нуля. При этом гордо стучат пяткой в грудь и кричат POSIX. Количество перенесенных проектов из одной ОС в другую единицы. Возможно в некоторых случаях это было бы удобно, но ведь не панацея же!

Аргументы (железные) за микроядро я так и не услышал, видимо нужно перечитать соотв. темы на форуме.
Почему именно вы смотрите в сторону микроядра? Лично мне эта часть системы не особенно интересна. Если между серверами/сервисами/процессами будет установлена достаточно быстрая и надежная связь, то как это сделано, пожалуй для меня не интересно. А простоту разработки и горячего включения/выключения/замены "дров" можно организовать и с монолитом. Я вообще считаю, что весь код может безопасно работать в ring0 (по ВМ каждому серверу :-).
И другой вопрос. Если речь идет о приземленных вещах, таких как о возможности практического использования системы в той или иной области, то почему ядро нужно разрабатывать (речь, например, о микроядре) с 0, а не взять то же L4? Как я помню для L4 есть механизмы паравиртуализации, что позволит в некоторых случаях (теоретически) использовать Linux (его дрова) в отсутствии собственных.

..bw