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

[AlexandrY]

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

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

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

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

[desh]

Контики от А. Дункельса и компании поддерживает загрузку модулей через elf для AVR, MSP430, x86 и др.
Ознакомиться с исходниками можно в contiki-2.6\core\loader\.
Сайт проекта http://www.contiki-os.org/

[SyncLair]

Контики от А. Дункельса и компании поддерживает загрузку модулей через elf для AVR, MSP430, x86 и др.
Ознакомиться с исходниками можно в contiki-2.6\core\loader\.
Сайт проекта http://www.contiki-os.org/

для AVR он немного "испортил" эльф и сделал его 16-и битным

Насчёт взаимодействия загружаемого модуля и ядра, моногие ARM-ы, например, имеют команду SVC - Supervisor Call, которая вызывает соответствующий .....

Вот этот пример показывает разницу между ABI и API ибо в первом случае чётко определены параметры вызовов и поэтому любая "прикладная задача" в ОС может воспользоваться функциями. Вопрос только в с ледующем а как же быть если есть задача и библиотека, и сначала грузиться библиотека а потом задача? и функции библиотеки не определены в SVC.


И на последок:

Координальное на мой взгляд решение в ембеддед мире -- специально готовить исполняемый прикладной файл с учётом того, что уже есть на плате. То есть линкер должен знать какое состояние флеши в контроллере и готовить очередной "прикладной процесс" (понятно что прикладной в смысле не ОС которая УЖЕ в МК) с учётом того что уже есть на плате. То есть ну вот есть функция TimeDelay() по адресу А так и не зачем пихать ещё одну а делаем вызов по адресу A.

Или если совсем просто, то пусть линкер линкует старые и новые объектные файлы только старые размещает по старому с нулевого адреса а новые далее. В этом случае загрузчику остаётся только сначала сделать memcmp, а уж потом оставшийся новый код догрузить во FLASH.

[haker_fox]

То есть ну вот есть функция TimeDelay() по адресу А так и не зачем пихать ещё одну а делаем вызов по адресу A.

Это правильно, но как этого добиться от линкера? Он-то о существовании оси не знает.
Допустим, у нас есть API для уже загруженной в МК операционки:

CODE

namespace OSAPI
{
void sleep( msec );
...
...
...
TPrio getSelfPrio();
...
...
...
void sendchar( char a );
}

Совершенно разные функции, которые уже есть в оси, на которые уже все заточено (прерывания, периферия, ядро). Допустим, мы решили воспользоваться одной из функций в нашем прикладном коде (драйвер, подгружаемая библиотека, просто программа):

CODE

....
int main( void )
{
....
while( 1 )
  {
    OSAPI::sleep( 100 );
    OSAPI::sendchar( '!' );
  }
....

Вот как объяснить линкеру, что нужно подставить только адреса функций, передать и принять аргументы.
Кроме, как в заголовочнике задать адреса этих функций (точно также, как мы делаем это в одном проекте "по месту") у меня идей нет... Вопрос, как сделать это красиво?

[AlexandrY]

Это правильно, но как этого добиться от линкера? Он-то о существовании оси не знает.

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

Кроме, как в заголовочнике задать адреса этих функций (точно также, как мы делаем это в одном проекте "по месту") у меня идей нет... Вопрос, как сделать это красиво?

Как это линкер не знает?

Первое.
Вы в проект вставляете файлы с объявлениями функций и процедур оси которые собираетесь использовать. Собираете, разруливаете зависимости, пишите если надо и концентрируете их в одном месте естественно руками.

Второе.
Вы подключаете к проекту symbol definition file который получаете автоматически когда компилируете ось перед загрузкой на голую платформу (не забыв галочку соответствующую поставить, естественно).

Этой информации линкеру более чем достаточно.

[haker_fox]

Вы подключаете к проекту symbol definition file который получаете автоматически когда компилируете ось перед загрузкой на голую платформу (не забыв галочку соответствующую поставить, естественно).

Ага! Про symdef слышу впервые. Зато теперь все вяжется! Спасибо

под AVR делал так:
имеем таблицу джампов переходов. Адресс таблицы "зашит жёстко". Сам по себе вектор может указыватьна любой адресс. А чтоб вызвать из прикладной прожки - то адресс известен. получается, что из любого места позвали известный адресс джамп перехода из ядра.

Кажется, это все вручную... печально