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

Kernel architecture questions
  • Serge Kernel Developer
    Posts 3952
    Joined: Wed Mar 08, 2006 6:25 pm

    art_zh

    А я вот пишу драйвер для видеокарты.
    Для микроядра вообще фиолетово как общаются между собой драйвер и диспетчер устройств. А простота доступа к железу в Колибри с лихвой компенсируется отсутствием многих необходимых функций. Чтобы запустить звук пришлось переписать половину ядра. Для драйвера ATI тянуть из Линукс код работы с PCI. Нормально работать с IRQ можно только в ядре и так далее.
  • User avatar
    art_zh Kernel Developer
    Posts 1465
    Joined: Fri Aug 14, 2009 1:46 am

    Serge wrote: Для микроядра вообще фиолетово как общаются между собой драйвер и диспетчер устройств.
    Зато для железа не фиолетово, по какому адресу сейчас находится системный семафор. Даже при наличии драйвера ничто не может быть зафиксировано.
    Serge wrote:А простота доступа к железу в Колибри с лихвой компенсируется отсутствием многих необходимых функций. Чтобы запустить звук пришлось переписать половину ядра. Для драйвера ATI тянуть из Линукс код работы с PCI. Нормально работать с IRQ можно только в ядре и так далее.
    Чтобы претендовать на звание Embedded, надо будет переписать больше чем половину кода. (не вдруг и сразу, - шаг за шагом).
    И разумеется добавить множество необходимых функций.
    И все же это более реальная цель, чем микрокернел и даже netbook-OS.
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • Serge Kernel Developer
    Posts 3952
    Joined: Wed Mar 08, 2006 6:25 pm

    art_zh

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

    Так проблема в том что проще написать заново чем переписать то что есть. Это всё равно что полностью заменить в многоэтажке пару этажей в середине и половину фундамента да ещё и подвал сделать. Да так чтобы жильцы и не заметели что что-то поменялось. Реально ?
  • User avatar
    art_zh Kernel Developer
    Posts 1465
    Joined: Fri Aug 14, 2009 1:46 am

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

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

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

    Так что несовершенство Колибри кое-где вполне может быть компенсировано ее офигенно либеральной архитектурой.
    Serge wrote: Так проблема в том что проще написать заново чем переписать то что есть. Это всё равно что полностью заменить в многоэтажке пару этажей в середине и половину фундамента да ещё и подвал сделать. Да так чтобы жильцы и не заметели что что-то поменялось. Реально ?
    Сравнение с многоэтажкой - пусть и яркая, но всего лишь метафора. К тому же неубедительная. Горбачев тоже когда-то использовал ту же ложную метафору, и даже свой катастрофический эксперимент назвал "перестройкой". А китайцы просто работали, последовательно приводя в порядок тот бардак, который им достался от Кормчего. Причем многие "жильцы" там до сих пор думают, что все идет как и было им предначертано. (пардон за метафору :)
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • maximYCH
    Posts 390
    Joined: Sun Nov 04, 2007 2:46 am

    art_zh, разница лишь в том, что для Вашего ядра потребуется переписать половину и последовательно, а для ядра, к которому стремятся некоторые другие разработчики - все и с нуля. Кроме того, все что Вы описываете (по моему скромному мнению и определенным знаниям по архитектуре) порядком сложнее даже задачи переписки ядра.
  • Serge Kernel Developer
    Posts 3952
    Joined: Wed Mar 08, 2006 6:25 pm

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

    Меня например интересует быстрое микроядро с удобным доступом к железу. Для такого ядра проще сделать порт драйверов с Линукс. И систему проще сконфигурировать под любое применение. Некоторые разработкии в этом направлении у меня есть, правда под 32 бита.
  • User avatar
    bw
    Posts 443
    Joined: Thu Mar 01, 2007 4:16 pm

    Давайте соберем все за и против микроядра. Вещь звучит заманчиво, но правильная ли она в рамках 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
  • Serge Kernel Developer
    Posts 3952
    Joined: Wed Mar 08, 2006 6:25 pm

    bw

    POSIX это на 90% процентов libc. Не нравится libc не используй её, но во многих проектах без неё никуда. Ffmpeg без неё не скомпилируешь а значит никаких плееров. Маленький проект ещё можно переписать на родной api, а большой ? Кто будет возиться ?
  • User avatar
    bw
    Posts 443
    Joined: Thu Mar 01, 2007 4:16 pm

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

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

    ..bw
  • Serge Kernel Developer
    Posts 3952
    Joined: Wed Mar 08, 2006 6:25 pm

    bw

    Например gcc с утилитами :) .
    Нормально у меня завелся и XviD (что я продемонстрировал в своё время) и FFmpeg. Без POSIX :-) Реализовал лишь (на самом деле просто мосты навел) необходимые минимальные зависимости.
    Эти минимальные зависимости тоже POSIX. Маленькая часть. Я же не говорю что надо делать 100% совместимую систему. Просто не надо усложнять жизнь тем кому эти возможности необходимы.

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

    Я в принципе за микроядро, но без жесткой привязки к POSIX - распухание кода можно избежать даже используя ЯВУ, но зачем наследовать мусор? Миф про перенос видимо очень болезненный для некоторых программистов. Ожидание чуда, но никакого чуда не наблюдается. Сколько не наблюдаю на каждой ОС свои приложения написанные по сути с нуля. При этом гордо стучат пяткой в грудь и кричат POSIX. Количество перенесенных проектов из одной ОС в другую единицы. Возможно в некоторых случаях это было бы удобно, но ведь не панацея же!
  • User avatar
    bw
    Posts 443
    Joined: Thu Mar 01, 2007 4:16 pm

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

    ..bw
  • Mario

    В пользу микроядра - широкая возможность по масштабированию системы. Конечно можно добиться подобного эффекта за счет модульного монолита, но микроядро под это изначально предназначено.
    А насчет L4 - опять же тащить чужое, ну чего тогда сразу не делать дистрибутив Линукса или BSD?
  • Serge Kernel Developer
    Posts 3952
    Joined: Wed Mar 08, 2006 6:25 pm

    bw

    L4 вещь которую надо знать, но построить на нём систему очень непросто. Я искал любительские системы на ядре L4 и результат неутешительный. Обычно всё сводится к запуску Линукс. Ещё есть попытка сделать клон OS/2 на ядре L4 ( OSFree). Ничего самобытного на L4 не нашлось. Хотелось бы иметь ядро более дружелюбное к разработчикам.

    Почему микроядро.
    1. Хорошо проработанное микроядро защищено от обрастания всякими ненужными фичами.
    Монолит будет разбухать как бы этому все не противились. За примером далеко ходить не надо - http://www.kernel.org Начиная с 2.6.31 туда запихнули DRI2/DRM/TTM под общим названием kms (kernel modesetting). Было обсуждение. Один разработчик с X.org комментировал ситуацию так: "Microsoft переносит драйверы из ядра в user-mode а мы всё тянем в ядро". Торвальдс противился и упирался как мог, назвал одну из версий кода "куском дерьма" и отказался вносить в git. Теперь улучшенная версия этого кода будет во всех Убунтах. Завтра в ядро запихнут mesa или gallium потому что это сделает 3D быстрее на 1%.

    2. Масштабируемость, о чём сказал Марат.

    3. Система на микроядре требует более тщательной проработки программных интерфейсов что положительно сказывается на работе системы. Ядро задаёт простые и одинаковые для всех правила работы. Меньше шансов на то что кто-то из разработчиков "срежет угол" и вместо "как правильно" сделает "как проще". Хотя бы на уровне ядра.

    4. В работе микроядра проще разобраться.
    • Post Reply

    Return to “Design”

    Who is online

    Users browsing this forum: No registered users and 2 guests