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

[AlexandrY]

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

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

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

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

[vshemm]

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

Мысль не очень, динамическая загрузка приложений ортогональна понятию ОС.
Практика показывает, чем более эмдеддед ОС, тем проще и технологичнее использовать статическое связываение,
в виде либ + хидеров, например.

Про загрузку dll - там связывание может происходить по ординалам, т.е. тупо по номерам. Есть еще связывание по хешу,
тот же CRC32 подойдет, причем все делается на этапе компиляции (включая проверку на коллизии). Где смотреть
примеры реализации - тот же линух и сорцы прочих ос. Так что 300КБ можно уменьшить в разы. Грубо говоря, при экспорте
символа он оборачивается в макрос, строится отдельная секция, которую потом обрабатывает линкер в ld-скрипте.
Ну а загрузчик уже юзает данную секцию в своих целях.

Про загрузку кода по произвольным адресам - гуглите relocation и fixup. Классическая дока по эльфам (собственно,
виндовый PE формат это упрощенный эльф) - http://www.becbapatla.ac.in/cse/naveenv/docs/LL1.pdf
Там есть все - разные архитектуры, разный эндианнес, вопросы MMU...

[AlexandrY]

Про загрузку кода по произвольным адресам - гуглите relocation и fixup. Классическая дока по эльфам (собственно,
виндовый PE формат это упрощенный эльф) - http://www.becbapatla.ac.in/cse/naveenv/docs/LL1.pdf
Там есть все - разные архитектуры, разный эндианнес, вопросы MMU...

Книжка в целом очень хорошая, но как всегда что касается embedded не очень целевая.

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

Пока единственный виденный мной доступный, рабочий, переносимый, чисто написанный elf-loader а видел в исходниках VwWorks. Они есть в местном хранилище.
Про статическое связывание лучше чем в доке на сами средства компиляции не найти. Поэтому прямиком на сайт www.arm.com - "Application Note 242"

[vshemm]

Насчет loader-ов есть сильное семантическое отличие этого понятия в контексте компьютерной информатики и малых встраиваемых систем.

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

Дока по L&L на примере ELF-а описывает как раз компоновку софта и последуещее развертывание
на девайсе. Есть и другие форматы, но ELF настолько получился удачным и гибким, что решает в 95%.
В любом случае, человек, хотя бы ознакомившийся с этой докой сможет сформулировать запрос в гугл

Разница между "компьютерными системами" и "малыми встраиваемыми системами" заключается только в
ресурсах. Т.е. надо дать определение, что такое малые встраиваемые. Моя эмпирическая оценка -
это 64КБ RAM, если меньше, то нужны *очень* веские доводы для реализации динамической загрузки.
Но никто даже в противном случае не мешает создать прошивку в виде эльфа, где уже бутлоадер
(даже являющийся частью того самого эльфа) будет загружать всю систему (ОС + прикладнуха).
Вообще, gcc + binutils + make + objcopy позволяет делать любые вещи, начиная от генерации под
виндой опшнромов, досовских EXE- и COM-файлов и заканчивая велосипедами для контроллеров. Но это
так, лирика.

Пока единственный виденный мной доступный, рабочий, переносимый, чисто написанный elf-loader а видел в исходниках VwWorks. Они есть в местном хранилище.
Про статическое связывание лучше чем в доке на сами средства компиляции не найти. Поэтому прямиком на сайт www.arm.com - "Application Note 242"

elf-loader есть как минимум в линуксе (тоже чистый и кросс), в BSD-like, QNX и т.д. Но они несколько
громоздки для начального изучения, поэтому я позволю себе дать пару ссылок: prex и embox. Первый
тоже кросс и MMU-независим, второй более наворочен, но требует MMU.