ОСРВ как тема кандидатской диссертации

[sasamy 0]

А в RTOS вообще не должно быть сбоев.

 

вы как всегда в ударе, капитан очевидность :)

 

Недаром на навороченных чипах типа i.MX53 c MMU и прочими фичами для жизненно важных приложений выбирают uC/OS RTOS без всякой виртуализации.

 

использовать на таких процессорах голые RTOS - это как в анекдоте про лису "обманула, обманула - деньги таксисту заплатила, а сама не поехала", а теперь куда вы засунете эти бумажки от uC/OS, если нужно что-то чуть более, чем круто дернуть ножкой ? Нормальные парни давно об этом подумали, даже комитеты создали по стандартизации Trusted Computing Group & ISO/IEC, GlobalPlatform TEE. А виртуализацией пользуются многие, например

http://www.ok-labs.com/releases/release/ok...quipment-from-k

Edited October 29, 2012 by sasamy

[Cosmojam 0]

Какие еще есть способы защитить программу? Как это делают FreeRTOS и остальные без MMU.

От кого защитить? От своей же соседней программы?

Смысл защиты памяти в том чтобы оградить программу (и ядро) от произвольной сторонней программы, написанной кулхацкером Васей из 7а, осилившим журнал "какер". Или от одноклассника Васи - Пети, который осиливает указатели в Си по K&R и то и дело портит данные в драйвере файловой системы и теряет данные на диске.

В МК же вы заранее пишите весь софт, который там будет работать, и, соответственно вылавливаете баги и уж точно не станете специально портить данные ядра или других программ.

Например, во FreeRTOS-MPU чтобы для Cortex-M3 настроить правильно распределение памяти для задач уйдёт много больше времени и сил чем отлов реальных багов. А попытка программы обратиться куда нельзя так же вызовет MemFault. Надёжность только если на случай порчи данных, например вдруг так совпало и записываем неверные данные в буфер отправки сообщения по какому-либо каналу связи и так получится что вместо "привет" отправится что-то нецензурное. Т.е. гарантируется "плановый" сбой на случай бага с указателями или иными косяками в работе с памятью. Так на этот случай вроде достаточно простого MPU в кортексах М3

[SyncLair 0]

http://www.ertos.nicta.com.au/research/l4....ed/approach.pml

 

L4 -- это семейство ядер почти все из них ориентированы на наличие MMU. И вообще наверное скорее следует говорить о MPU! Поэтому Вас не поддерживаю в этом, а вот в том чтобы "использовать ЯВУ" с защитой -- это да!

На мой взгляд java и Lua лучшие кандидаты.

 

 

А виртуализацией пользуются многие, например

http://www.ok-labs.com/releases/release/ok...quipment-from-k

 

Опять таки L4-тое ядро.

 

Но надо:

-многозадачность (многопоточность);

-защита программ друг от друга (виртуализация, МК без MMU), скорее всего аппаратными средствами;

-по возможности оптимизация.

 

1. По надёжности -- Нет MPU -- нет надёжности от быдлокода!

2. По методикам -- различные стандарты требуют куча всего для того чтобы код был надёжным.

То есть направо не ходить, налево не ходить, компиляторными нестандартными фишками не пользоваться,

память выделять так, именовать так и так далее -- все эти требования выглядят как ритуал который впринципе помогает кодить среднеквалифицированым специалистам. НО! это всё не даёт 100% гарантии на выполнение!

ДЛЯ доказательства того что ВСЯ система надёжна нужно доказывать всё до последнего байта!

 

Если есть MPU -- то для доказательства надёжности нужно доказать что ядро+аппаратный механиз защиты памяти надёжны (L4 и прочее тут как раз рулит!) и то что нужные Вам высокоприритетные важные процессы надёжны!

 

3. РТОС без ММU c "гарантирванным временем вытеснения!" даёт возможность проводить математическое докозательство того что при любых условях самые высокоприоритетные процессы-"элита" получат себе нужное быстродействие а система уложится в отведённые дедлайны!

ВСЁ!

 

Edited October 29, 2012 by SyncLair

[wedmeed 0]

MPU!

Это если необходимо защищать встроенную память. Если пользуется внешняя - можно и MMU, правда выглядеть он будет довольно монстроидально. Исходя из задачи - да, MPU достаточно и гораздо оптимальнее.

 

"использовать ЯВУ"

Насколько сложно портировать среду явы?

Сложно ли гарантировать корретность портирования и отсутствие ошибок в среде?

Насколько понимаю, это накладные расходы x3 минимум?

 

З.Ы. На яве никогда не писал и, тем более, не портировал.

[SyncLair 0]

З.Ы. На яве никогда не писал и, тем более, не портировал.

ЯВУ не означает ТОЛЬКО ява. Ничем помочь не могу у самого реальный опыт ноль! Но на то она и диссертация....

[wedmeed 0]

ЯВУ не означает ТОЛЬКО ява.

Я Вас понял.

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

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

На мой взгляд, маленькая простенькая ОС с MMU/MPU выглядет гораздо элегантнее. Даже не ОС, диспетчер. Какие еще преимущества кроме контроля исполнения дают ЯВА-подобные среды?

 

Почему микроконроллеры с флэшью >64 Кб не оснащают MMU/MPU? Ведь уже в таком объеме можно наворотить довольно сложную систему. Насколько я понимаю это, по крайней мере MPU, не такой сложный модуль, который можно сделать даже не влезая в ядро (просто мониторить шину и генерировать прерывания-ловушки).

Edited November 1, 2012 by wedmeed

[Snaky 0]

Я Вас понял. Виртуальные машины вещь очень сильная... Какие еще преимущества кроме контроля исполнения дают ЯВА-подобные среды?

По-моему не поняли. ЯВУ - язык высокого уровня. Си, например. В отличие от ассемблера который низкоуровневый.

[wedmeed 0]

ЯВУ - язык высокого уровня. Си, например.

Извиняюсь, только сейчас понял что это аббревиатура.

Тогда не понимаю. В теме говорилось про возможность контроля за процессом и защита памяти. Си, даже Си++, это не умеют. А вот джава-подобные (с виртуальной машиной) умеют.

Edited November 1, 2012 by wedmeed

[sasamy 0]

Тогда не понимаю. В теме говорилось про возможность контроля за процессом и защита памяти. Си, даже Си++, это не умеют. А вот джава-подобные (с виртуальной машиной) умеют.

 

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

 

Despite its ability to run real user code, the Haskell ker-

nel remains a prototype, as it does not satisfy our high-

performance requirement. Furthermore, Haskell requires a

significant run-time environment (much bigger than our ker-

nel), and thus violates our requirement of a small TCB. We

therefore translated the Haskell implementation manually

into high-performance C code. An automatic translation

(without proof) would have been possible, but we would

have lost most opportunities to micro-optimise the kernel in

order to meet our performance targets. We do not need to

trust the translations into C and from Haskell into Isabelle —

we formally verify the C code as it is seen by the compiler

gaining an end-to-end theorem between formal specification

and the C semantics.

 

 

 

[AlexandrY 0]

, маленькая простенькая ОС с MMU/MPU выглядит гораздо элегантнее. Даже не ОС, диспетчер.

 

Почему микроконтроллеры с флэшью >64 Кб не оснащают MMU/MPU?

 

Voyager-1 летит уже 35 лет. Никакого MMU на нем нет.

 

Планировщики в осях тоже никакого отношения к MMU не имеют.

Если вы согласны с мыслью, что в RTOS вообще не может быть ошибок, то должны сконцентрироваться на их отлавливании на этапе разработки, а не на фиксации сбоев благодаря MMU на этапе эксплуатации.

 

Поэтому для RTOS гораздо важнее JTAG отладчики и трассировщики.

Использовать же MMU на этапе разработки только для того чтобы вычислить пару специфических ошибок сильно расточительно.

[Mahagam 0]

1. По надёжности -- Нет MPU -- нет надёжности от быдлокода!

а кто вам сказал что если есть MPU - то сразу появляется надёжность от быдлокода? надёжность с наличием/отсутствием MPU никак не связана (конечно, в проектах, где внешнюю программу подгрузить нельзя). надёжность зависит только от количества быдлокода.

 

Если есть MPU -- то для доказательства надёжности нужно доказать что ядро+аппаратный механиз защиты памяти надёжны (L4 и прочее тут как раз рулит!) и то что нужные Вам высокоприритетные важные процессы надёжны!

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

[wedmeed 0]

ЯВУ (Haskell по ссылке) используется для создания прототипа микроядра

Хаскель - функциональный "чистый" язык. В нем по логике не может быть коллизий памяти, пока не начать использовать функции с побочными эффектами. А как без последнего работать со временем или реализовать закон управления по передаточной функции (где обязательно иметь переменные состояния) я не представляю. Буду рад если сможете привести пример.

Почему прототип? Какие функции он выполняет и есть ли среди них защита процессов друг от друга? Есть ли подобная реализация на Си?

 

Использовать же MMU на этапе разработки только для того чтобы вычислить пару специфических ошибок сильно расточительно.

Человек есть человек. Все ошибки найти или гарантировать что они все найдены невозможно. http://www.osp.ru/os/1998/06/179592/

Или зачем тогда делают системы с резервированием?

 

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

Доказать надёжность кода поддержки MPU можно один раз и использовать во всех дальнейших проектах.

При защищенности процессов друг от друга можно плотно доказывать надежность только критических модулей программы, остальных - поверхностно. Если классифицировать уровень критичности модуля в соответствии с тем же КТ178.

[sasamy 0]

Почему прототип? Какие функции он выполняет и есть ли среди них защита процессов друг от друга? Есть ли подобная реализация на Си?

 

Вы похоже не то что по ссылкам не ходите - даже не читаете то что тут цитируют - удачной беседы самому с собой :)

[AlexandrY 0]

Человек есть человек. Все ошибки найти или гарантировать что они все найдены невозможно. http://www.osp.ru/os/1998/06/179592/

Или зачем тогда делают системы с резервированием?

 

А не удивительно, что за столько лет все продолжают приводить в пример замусоленные случаи с Ariane 5 и Therac-25?

 

Почему бы не привести проблему с Opportunity?

 

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

 

Там речь шла о том, что марсоход в определенный момент экпедиции вдруг стал жутко тормозным и долго не реагировал на команды.

Его пришлось остановить и долго перезаливать софт.

Там была RTOS VxWorks. Поскольку нынче на космической технике применяю радиационно стойкие RAD750 (аналог PowerPC) то WxVorks там использует MMU.

Программист то ли из-за лени, то ли из-за невысокой своей квалификации подумал, что в RTOS можно кое в каких местах пропустить использование мьютексов.

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

Хотя проблема инверсии приоритетов ему была прекрасно известна.

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

 

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

[Aner 0]

Да уж! ... вообще то средне-инженерная задача, но с неё делают кандидатскую и/или затем на докторскую замахиваются.

Что дальше? Или такое сильное отставание по OS в стране и какой!?

 

проблема с Opportunity ... хороша, но не фейк ли это? Они же тестируют все на модели на земле потом туда, или просто прохлопали.