Цитата:
- да, микроядерность ТЕОРЕТИЧЕСКИ повышает безопаснось...
- ты в курсе, что qnx - очень тормозная система?
- это во первых... а во вторых, при разнесении кода по разным адресным пространствам, появляются ТАКИЕ тормоза, что мама не горюй...
Здесь на эти три пункта отвечу.
Алексей, а Вы, вообще-то, на QNX работали? Не теоретически или, услышав отзывы от сверстников, «на домашнем компе установивших», чего-то привычного не нашедших и опфукавших «эту hалимость», а вот в каком-нить проекте с реальным железом, ограничениями и результатами?...
Я работал. Конкретно и с конкретными проектами.
Рассуждать ТЕОРЕТИЧЕСКИ можно, читая теорию в книжках или бродя по форумам, где масса молодёжи плюётся на файловый менеджер той или иной системы, «патамушта сочетаниия клавиш там hалимые»...
Могу Вас заверить, что QNX именно ПРАКТИЧЕСКИ мне лично доказала свою безопасность. Более того, после работы с QNX, и увидев ПРАКТИЧЕСКИЕ результаты тех самых ТЕОРЕТИЧЕСКИХ академических работ по надёжности, мне уже просто тоскливо на рассуждизмы о «надёжности» с помощью иных средств слушать...
Я уже написал на примере отдела, где работал, про разработку и отладку драйверов. Я лично нигде и никогда не видел такого уровня надёжности. Здесь теория отлично подтвердилась практикой, когда я удалённо из Харькова через Интернет на объекте под Хмельницким мог перезагружать исправленные драйвера. При этом мне не нужен был человек, «висящий» на телефоне на объекте и по моей команде нажимающий там на кнопку ресет.
При этом я ЧИСТО ПРАКТИЧЕСКИ «тормознутости» QNX ну никак (почему-то
), не заметил...
И, потом, про какую «тормознутость» Вы говорите?
Мы преименяли эту ОСь для коммутации информационных потоков как на КА, так и на наземной аппаратуре... Про скорости информации ап-линка и даун-линка, например с «Терры» надо ли говорить?
То, что ТЕОРЕТИЧЕСКИ (и по Таненбауму) и ПРАКТИЧЕСКИ (по многочисленным тестам и того же Таненбаума и самой QSSL) ЕСТЕСТВЕННОЕ падение скорости решения задач ИНТЕНСИВНОГО ОБМЕНА ИНФОРМАЦИИ МЕЖДУ ПРОЦЕССАМИ будет порядка 3-10%, мы знали. И - СОЗНАТЕЛЬНО на это шли. Почему? Да всё по той же причине: нам нужна была ПРАКТИЧЕСКИ 100%-ная НАДЕЖНОСТЬ и ИМЕННО СИСТЕМА
ЖЕСТКОГО РВ.
Теперь о третьем пункте.
А Вы вообще-то задавались вопросом, ПОЧЕМУ у Вас появляются «появляются ТАКИЕ тормоза, что мама не горюй...»?
А сесть и подумать не пробовали?
Дам намёк: вчитайтесь в слоган QSSL (автора QNX)...
Цитата:
- что имеем на практике - при дроблении ядро на части появляется и лавинообразно растет сложность взаимодействия этих частей
ЧТО ЗА ЧУШЬ???
Ладно, ответом на этот вопрос я отвечу на свой же, заданный двумя строчками выше Вам...
«Лавинообразно растет сложность взаимодействия этих частей» только в том случае, КОГДА ВЫ НЕ ПЕРЕСМАТРИВАЕТЕ АРХИТЕКТУРУ СИСТЕМЫ С УЧЁТОМ МИКРОЯДРА И СИСТЕМЫ ОБМЕНА СООБЩЕНИЯМИ.
КАКИЕ примеры приложений мы берём для рассмотрения «роста сложности взаимодействия» для «перезаписи в микроядерную Ось с обменом сообщениями»?
1)исполняющиеся и взаимодействующие внутри ядра?
2)взаимодействующие с элементами ядра, но исполняющие в пространстве пользователя?
3)взаимодействующие между собой пользовательские приложения?
Ответы по пунктам:
1) Даже в случае такого взаимодействия, разработчики "монолитно-модульных" ядер ПРЕКРАСНО ПОНИМАЮТ, с кем им «придётся иметь дело» - с «чужеродным кодом», далеко не всегда правильно написанным. По сему случаю, они вынуждены ВВОДИТЬ МНОГОЧИСЛЕННЫЕ проверки для того, что бы максимально оградить ядро от неправильных указателей и индексов реализаторов драйверов (например)... Можно, конечно, как всегда, попробовать хак... Но, хорошо, если ваш хак работает на Вашем же столе, а если за пределами атмосферы в тысячах километров, или среди болот в тундре?
Для микроядра этой проблемы ВООБЩЕ не существует.
2) и 3) можно объединить, так, как и том, и в другом случае Вы никуда не денитесь от проблемы переноса массивов данных между разными адресными пространствами...
Естественно, что если Вы напрямую будете копировать стиль и приёмы работы, когда элементы данных или напрямую были доступны или применялись «классический» набор средств синхронизации доступа к ним, то Вы будет страшно тормозить... Для того, что бы реализовывать нормально работающую систему, надо пересматривать собственную философию разработки. А что Вы хотели? Всякий шаг в развитии технологии меняет подходы к реализации поддержки новых технологий. А когда и где было иначе?!
Именно отсюда идёт и тезис о, якобы, возрастающей сложности взаимодействия...
На самом деле сложность взаимодействия УМЕНЬШАЕТСЯ!
Опять же — из собственного опыта работы с QNX, я Вам это заявляю. Механизм обмена сообщениями с блокировкой просто удаляет массу ненужного кода (как в ядре, так и в приложениях), обеспечивающих общение частей системы. Там многое, что описывалось, в традиционных системах, целыми классами и разновидностями механизмов, сливается в простой обмен по каналам сообщениями с аргументами. В системах с микроядрами и обменом сообщениями как раз идут наоборот: зная, что в системе могут работать или в систему могут переписываться (переноситься) приложения, спроектированные на старых философии и идеологии, реализуют старые механизмы НА ОСНОВЕ механизма обмена сообщениями с блокировками. ЕСТЕСТВЕННО, что это — дополнительные накладные расходы. И именно они, скорее всего, дали основания некоторым «знатокам» рассуждать о катастрофическом замедлении работы на микроядрах с сообщениями...
Замедление на 3-10%, в случае микроядра и обмена сообщениями (при прочих равных) имеется. Но оно - НЕОТЪЕМЛЕМО и СИСТЕМНО присуще микроядрам. Но я согласен двумя руками держаться за 100% надёжную систему, чем иметь систему с «рюшечками», но с любым количеством девяток после запятой...
Цитата:
- в Линуксе есть философия - все части ядра должны быть открытыми... тогда их можно отладить и падений не будет...
О какой «открытости» мы говорим?
Философия не в этом, а в том, что Вам дали код и сказали: «Мужик, мне пофиг твои разглогольствования на счёт четких описаний и соблюдений интерфейсов! Вот тебе исходники — смотри сам!»
Ну так я потому и сказал, что Билл Гейтс должен был возглавить движение за открытые исходники, опубликовать тексты винды и убрать все описания!...
Мне не нужен «фон» и накладные расходы по копанию в исходниках! Мне нужно описание ПРЕДСКАЗУЕМЫХ реакций «черного ящика» на мои воздействия на него.
В остальных «открытых системах» ситуация примерно такая же.
Вот я сейчас с одной из подсистем Фрюхи. Всё — на ладони. В итернете масса обсуждений. Но «соли»-то нигде не описано! Пока я допёр до главных идей авторов, времени прошло достаточно! А ведь даже они ничего в переписке не рассказывали! А когда я поделился обобщённым мнением и «догадками», они сказали «гут киндер!». Да нафига мне их похвалы, мне нужно было страничку с описанием главных идей и их выразителей в коде! А они сопли жевали «угадал/не угадал»...
Цитата:
- если я этот самый программист (которому заказали написать драйвер под linux) - у меня на руках будут все исходники, как мои собственные, так и ядерные... если я в этих условиях не напишу корректно работающий драйвер - значит я хреновый программист и зря взялся за эту работу, вот и все...
Это — лозунги! Или - благие пожелания. По младости - дозволительно. Но, с возрастом это проходит...
В QNX, имея на руках прекрасные руководства (при полностью закрытой системе!), я начал работать продуктивно в два раза быстрее (и, выполняя объёмы работ в разы большие!), чем с «полностью открытым» вариантом Юникс-системы...
Пока, что у меня от состояния мира «открытых исходников» только два слова : «бардак» и «заносчивость»...
Кстати, в перечислении условий, Вы ПОЧЕМУ-ТО
, не указали ЕЩЁ НЕСКОЛЬКО НЕПРЕМЕННЫХ условий успешности написания драйвера... (если следовать "духу и букве" открытых исходников...)
Вам также понадобились бы:
1) Принципиальная и монтажная схемы самого устройства
2) Схемы всех, составляющих микрух в нём
3) Весь код всех микроконтроллерах устройства
4) хHDL-ные тексты прошивок ПЛИСок, буде такие окажутся на плате
Почему же вы это не указали? Странно - да, согласитесь? ЗЫ вообще же складывается некоторое представление о какой-то органической дебильности отрасли: ядра (при таком подходе — «монолите»), как раз и надо было бы писать на чём-то подобном оберон-языкам... Вот приложения пользователя, если они в отдельных адресных пространствах, - пишите, на чём вам заблагорассудится! Развлекайтесь, падайте, вылетайте нулу, индексам вне диапазона — ваши проблемы! Но ядро — дело святое!...
А получается — совсем наоборот! МАРАЗМ!