[SyncLair 0]

Ну инверсия и произошла. Низкоприоритетная задача в результате остановила важные задачи по оперативному управлению.

 

Теперь вопрос. Как MMU могло бы помочь этой проблеме? Ответите и докторская у вас в кармане.

 

Конкретно тут -- никак. Тем не менее наличие MPU наверное позволило гарантировать что ядро системы не убиваемо, а раз ядро не убиваемо, то высокоприоритетный процесс-загрузчик может быть активирован соответвенно активировав его систему можно было перезагрузить/перепрошить или чего то подобное. Хотя конечно всегда можно тупо соседним контроллером сделать RESET и вперёд!

 

 

 

а кто вам сказал что если есть MPU - то сразу появляется надёжность от быдлокода?

 

то есть к доказательству надёжности каждой строчки проекта надо ещё и доказать надёжность дополнительного кода поддержки MPU?

Если ядро системы защишено через MPU, то в крайнем случае быдлокод можно приостановить. Приостановить его может более высокоприоритетный процесс-контролёр. Его тоже конечно надо ооочень тщательно проектировать!

 

Да доказываем надёжность ядра и надёжность CPU support package куда включается управление MPU!

Изменено 2 ноября, 2012 пользователем SyncLair

[Kopa 0]

Я Вас понял.

Виртуальные машины вещь очень сильная, но и расточительная. Когда люди говорят о микроконтроллерах - часто это связано с маломощными платформами и ужатыми ресурсами.

...

Предлагаю для ознакомления один из ресурсов где есть "определённое" обсуждение данного и смежных вопросов по вашей теме Форт форум Читайте, обсуждайте если сочтёте полезным экспериментируйте и делайте выводы.

Изменено 2 ноября, 2012 пользователем Kopa

[Mahagam 0]

Если ядро системы защишено через MPU, то в крайнем случае быдлокод можно приостановить. Приостановить его может более высокоприоритетный процесс-контролёр. Его тоже конечно надо ооочень тщательно проектировать!

 

быдлокод он такой быдлокод. вот какая-нить задача позахватывает мютексов на периферию и не отдаст. и всё. и вся защищённая система станет колом. нет у неё юзера с Ctrl-Atl-Del для того чтобы снять тупую задачу.

 

 

 

[SyncLair 0]

быдлокод он такой быдлокод. вот какая-нить задача позахватывает мютексов на периферию и не отдаст. и всё. и вся защищённая система станет колом. нет у неё юзера с Ctrl-Atl-Del для того чтобы снять тупую задачу.

Значит эта задача сидит в функциях что пишут на перефирию. Значит она не вызывает функцию программного ватчдога. Значит снимаем эту задачу, отрываем у неё мьютексы, периферию делаем init() и всё.

 

 

Юзера нет, зато есть другие процессы которые а)как супервизор её контролируют б) после 100ой попытки длиной в 10мсек взять мьютекс на перифирию, перезапускают модуль перифирии, а при перезапуске модуля все задачи которые его юзают получают фиг... ой то есть FALSE.

 

 

[wedmeed 0]

В теме говорилось о том что "Только придется среду исполнения портировать", так вот ее не обязательно портировать - ЯВУ (Haskell по ссылке) используется для создания прототипа микроядра

Прошу прощения, я не сразу понял суть. Идея в том , чтобы использовать ЯВУ для мат. доказательства правильности работы ядра (или хотя бы его алгоритмов)?

 

Форт форум

Основное преимущество форта (говорим про быстродействие) - в малом объеме программ на нем? За счет отсутствия необходимости частой подкачки?

 

 

 

Теперь про L4. Я не особо силен в иностранном, поэтому чтобы вникнуть воспользовался этим: обзор.

Есть пара вопросов:

Синхронная передача сообщений означает что оба процесса должны одновременно быть в режимах приемника (один) и передатчика (другой). То есть для передачи оба процесса должны сменить состояние и отдать управление ядру, так?

Наличие многоуровневых менеджеров памяти. То есть аппаратно виртуализацию/защиту поддерживает только менеджер высшего уровня (в ядре L4)? В остальных виртуализация программна и менеджер работает в usermode? Например, ОС, работающая поверх L4 не имеет внутри абсолютных защит между своими процессами?

[Mahagam 0]

Значит эта задача сидит в функциях что пишут на перефирию. Значит она не вызывает функцию программного ватчдога. Значит снимаем эту задачу, отрываем у неё мьютексы, периферию делаем init() и всё.

 

 

Юзера нет, зато есть другие процессы которые а)как супервизор её контролируют б) после 100ой попытки длиной в 10мсек взять мьютекс на перифирию, перезапускают модуль перифирии, а при перезапуске модуля все задачи которые его юзают получают фиг... ой то есть FALSE.

 

вы сути не поняли: от быдлокода нет защиты. и никакие MMU/MPU не помогут. это всё для самозащиты системы от _внешних_ программ.

[SyncLair 0]

вы сути не поняли: от быдлокода нет защиты. и никакие MMU/MPU не помогут. это всё для самозащиты системы от _внешних_ программ.

Видимо действительно не понял, а разве внешняя программа не есть равно потенциальный быдлокод?

 

 

[Mahagam 0]

Видимо действительно не понял, а разве внешняя программа не есть равно потенциальный быдлокод?

 

в случае когда я сам себе код пишу - мне не от чего защищаться. если я подразумеваю возможность запуска внешний приложений - я буду защищаться параноидально. но много систем с многозадачностью такой возможности не предусматривают

[AlexandrY 3]

Синхронная передача сообщений означает что оба процесса должны одновременно быть в режимах приемника (один) и передатчика (другой). То есть для передачи оба процесса должны сменить состояние и отдать управление ядру, так?

 

Кстати о передаче сообщений.

Вот пример ошибки с которой столкнулся вот прямо сегодня.

В применяемой операционке нет очередей. Вернее нет возможности послать в очередь из ISR.

Пришлось применить установку простого флага. Вполне подходящая процедура, а главное быстрая (что и подвело)

И все было хорошо и протестировано.

Но вот прошел год и понадобилось в программу ввести новую задачу и поменять распределение приоритетов у задач.

И начал сбоить тот драйвер который работал с флагом.

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

 

Так вот L4 это сплошное заумное теоретизирование никакого отношения к реальному риалтайму и RTOS не имеющее.

RTOS это детерминизм, профилирование, и замеры. Все силы направлены на обеспечение абсолютного быстродействия.

Отсюда и вытекают большинство компромиссов и ошибок.

Поработайте лучше над этим. Будет хоть какая-то польза обществу. ;)

 

 

[sasamy 9]

Теперь про L4. Есть пара вопросов:

 

Сразу оговорюсь - я не специалист по L4 и интересовался только чисто практически - что можно поиметь с того что есть на данный момент - портирование микроядра, L4Linux

 

Синхронная передача сообщений означает что оба процесса должны одновременно быть в режимах приемника (один) и передатчика (другой). То есть для передачи оба процесса должны сменить состояние и отдать управление ядру, так?

 

Да. Если интересует что-то по L4 на родном языке - обратитесь лучше сюда

 

http://l4os.ru/forum/

 

Alman - настоящий фанат L4

 

ОС, работающая поверх L4 не имеет внутри абсолютных защит между своими процессами?

 

Систему можно построить по-разному, например в L4Linux процессы Linux - это задачи микроядра работающие каждый в отдельном адресном пространстве, а все системные вызовы Linux работают через IPC микроядра.

[SyncLair 0]

Кстати о передаче сообщений.

Вот пример ошибки с которой столкнулся вот прямо сегодня.

В применяемой операционке нет очередей. Вернее нет возможности послать в очередь из ISR.

 

Так вот L4 это сплошное заумное теоретизирование никакого отношения к реальному риалтайму и RTOS не имеющее.

 

Так вот, создавайте высокоприоритетный поток, посылайте ему СИНХРОННОЕ сообщение из ISR а уж он затем пусть послылает асинхронное сообщение драйверу. Да -- согласен накладные расходы. Но никто не скажет что такая схема не обладает реалтаймом ).

 

 

[AlexandrY 3]

Так вот, создавайте высокоприоритетный поток, посылайте ему СИНХРОННОЕ сообщение из ISR а уж он затем пусть послылает асинхронное сообщение драйверу. Да -- согласен накладные расходы. Но никто не скажет что такая схема не обладает реалтаймом ).

 

Про "СИНХРОННОЕ сообщение из ISR" не понял. Звучит так словно ISR должна тормознуть пока какой-то поток не примет сообщение.

В какой RTOS это есть и как называется вызов API?

 

[SyncLair 0]

Про "СИНХРОННОЕ сообщение из ISR" не понял. Звучит так словно ISR должна тормознуть пока какой-то поток не примет сообщение.

В какой RTOS это есть и как называется вызов API?

 

Это есть в L4 ядрах. Не ISR тормозит, а ISR отправляет сообщение, если что либо хочет принять "псевдосообщение от ISR" . Перед тем как его принять поток должен вызвать стандартный ipc_recv со спец идентификатором который обозначает номер прерывания, номер ловушки, номер ещё чего либо.

 

Interrupts are delivered as an IPC call to the interrupt handler thread (i.e., the pager of the interrupt thread).

Изменено 13 ноября, 2012 пользователем SyncLair

[Kopa 0]

Интересный пост

RetroBSD on Maximite

[wedmeed 0]

Я уже давно тут не отписывался, так как пока хочу лучше изучить предложенные решения (конкретно L4 и Forth). Но параллельно встречаются и другие вопросы, которые хотелось бы обсудить.

 

1) Какие способы оценки качества (а в случае моей целевой системы читать - надежности) существуют и могут быть актуальны. Последний классический учебник который я встречал (Майерс) датировани 1980 годом. Кнниги Липаева классическими не называют, да и основываются на совсем другом классе систем (большие, сложны, распределенные). То, что предлагают современные стандарты (чаще взаимодействуйте при разработке с сертифицирующим органом) не устраивает в связи с наличием человеческого фактора и отсутствием математически обоснованных методик.

Грубо говоря - как мне по науке доказать что то или иное решение принесет лучший результат.

2) Экзоядро. Я давно о нем слышал, но только недавно нашел хорошее объяснение, которое меня немного вдохновило. Еще раз про целевую систему: нет мму/мпу, памяти мало (дробить на страницы тяжело), не меняющийся набор программ, можно выполнять инструкции из флеш, много периферии, надо работать быстро, преобладание цикличных задач, вредоносного кода нет. Все так и подталкивает - отказаться от процессов в сторону потоков, написать простейшую переключалку по таймеру, а все остальное - в библиотеках. Защита - за счет инкапсуляции библиотек (ну и надеяться что в будущем к платформе пришьют мпу).

Кто сталкивался, поделитесь соображениями/ссылками/книжками.