Технология динамической загрузки модулей для RTOS, Какие есть методы и инструменты. Опции

[AlexandrY]

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

Очевидно, что это реализовать для небольших проектов и даже не с ОС совершенно элементарно.
Для этого при компиляции основного ядра делают symbol definition file и потом этот файл и файлы хидеров передают третьей стороне чтобы те могли правильно скомпилировать и слинковать свои приложения для ядра.

Но когда в ядре количество функций переваливает за тысячу, то сделать переносимые хидеры в ручную представляется проблемой.
Также желательно сделать отдельный модуль с так называемой jump table чтобы уменьшить зависимость от мелких изменений и перекомпиляций ядра. Как-то подумать о фильтрации, чтобы не все подряд сущности из ядра попадали в symbol definition file и т.д.

И тогда вопрос - заморачивается ли кто-нибудь с этим и известны ли инструменты автоматизации всего этого процесса.

[a9d]

Для начала

Операционная система (Operating system) по ГОСТ 15971-90
Совокупность системных программ, предназначенная для обеспечения определенного уровня эффективности системы обработки информации за счет автоматизированного управления ее работой и предоставляемого пользователю определенного набора услуг [из п. 16 Таблицы 1 ГОСТ 15971-90]

операційна система - сукупність програмних засобів,
призначених для автоматизованого керування виконанням програми та
надання користувачам певних послуг (ДСТУ 2938-94, п. 4.16);

Как видно загружать программы не обязательно.

Можно использовать Си подобные скрипты. Тогда не будет зависимости от версии ядра. Но размер скриптов будет большим и пострадает производительность.

Сообщение отредактировал a9d - Dec 29 2012, 22:04

[AlexandrY]

Как видно загружать программы не обязательно.

Можно использовать Си подобные скрипты. Тогда не будет зависимости от версии ядра. Но размер скриптов будет большим и пострадает производительность.

ГОСТ конечно сильный аргумент, но те кто задает моду на OS-и про ГОСТ наверно мало знают, если вообще знают.

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

Скажем та же функция загрузки сторонних приложений написанных на C-и в ось без виртуализации памяти выглядит очень опасной.
Скорее это подход из прошлого века времен DOS.
Т.е. для малых RTOS такая фича дала бы не преимущество, а большую проблему. Значит загрузку программ на С-и вычеркиваем из списка must-have.

Если говорить о HAL в RTOS. (это вдогонку закрытой предыдущей темы)
Тут тоже не все так просто. Обычно разработчики очень неохотно меняют семейства микроконтроллеров. Это довольно трудное занятие.
Именно потому, что вынуждены детально изучать всю аппаратную часть платформы.
Тогда зачем абстракции? Что HAL уровень упрощает в RTOS кроме переносимости верхнего уровня?
Но рискну предположить, что именно переносимость меньше всего волнует разработчиков. Она скорее важна тем кто разрабатывает оси чтобы расширить сегмент сбыта. Т.е. HAL ставим под вопросом в списке must-have для RTOS, хотя вообще для осей фича стоящая.