реклама на сайте
подробности

 
 
3 страниц V   1 2 3 >  
Reply to this topicStart new topic
> Технология динамической загрузки модулей для RTOS, Какие есть методы и инструменты.
AlexandrY
сообщение Dec 29 2012, 21:48
Сообщение #1


Ally
******

Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050



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

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

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

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


Go to the top of the page
 
+Quote Post
a9d
сообщение Dec 29 2012, 22:03
Сообщение #2


Местный
***

Группа: Участник
Сообщений: 312
Регистрация: 9-04-10
Пользователь №: 56 532



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

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


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

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

Сообщение отредактировал a9d - Dec 29 2012, 22:04
Go to the top of the page
 
+Quote Post
haker_fox
сообщение Dec 30 2012, 13:09
Сообщение #3


Познающий...
******

Группа: Свой
Сообщений: 2 963
Регистрация: 1-09-05
Из: г. Иркутск
Пользователь №: 8 125



QUOTE (AlexandrY @ Dec 30 2012, 06:48) *
И тогда вопрос - заморачивается ли кто-нибудь с этим и известны ли инструменты автоматизации всего этого процесса.

Очень интересный вопрос! Я тут как-то даже чуть для scmRTOS под ARM это не попытался сделать загрузку модулей и программ "как в дос или виндовс". Конечно, в масштабах домашней мастерской. Но не хватило квалификации)


--------------------
Выбор.
Go to the top of the page
 
+Quote Post
AlexandrY
сообщение Dec 30 2012, 13:41
Сообщение #4


Ally
******

Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050



Цитата(a9d @ Dec 30 2012, 00:03) *
Как видно загружать программы не обязательно.

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


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

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

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

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

Go to the top of the page
 
+Quote Post
a9d
сообщение Dec 30 2012, 14:31
Сообщение #5


Местный
***

Группа: Участник
Сообщений: 312
Регистрация: 9-04-10
Пользователь №: 56 532



Насколько я помню в винде адреса API функций программа получает по ANSI именам. Так решиться проблема с адресацией.

Тогда нужно реализовать функцию которой передается имя функции а она вернет адрес. Этот адрес загоняем в массив и дальше используем.
Но эта не самая большая проблема. MMU все таки нет а значит будет тоже самое, что и с uclinux.

Сообщение отредактировал a9d - Dec 30 2012, 22:36
Go to the top of the page
 
+Quote Post
haker_fox
сообщение Dec 31 2012, 06:04
Сообщение #6


Познающий...
******

Группа: Свой
Сообщений: 2 963
Регистрация: 1-09-05
Из: г. Иркутск
Пользователь №: 8 125



Гм... чувствую благовейный ветерок) Как когда-то для восьмибитников RTOS была желанной новинкой. Так сейчас и в RTOS будут появляться возможности запустить скомпилированную "дядей Васей" левую программу, модуль или драйвер. Вообще для ARM7TDI хотябы уже актуальная задача. Не могу реализовать. Но очень бы хотелось, не перепрошиваю всю программу целиком, завершать исполнение одной, а загружать новую) Я в теме? Или речь о другом?)


--------------------
Выбор.
Go to the top of the page
 
+Quote Post
AlexandrY
сообщение Dec 31 2012, 12:09
Сообщение #7


Ally
******

Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050



Цитата(a9d @ Dec 30 2012, 16:31) *
Насколько я помню в винде адреса API функций программа получает по ANSI именам. Так решиться проблема с адресацией.

Тогда нужно реализовать функцию которой передается имя функции а она вернет адрес. Этот адрес загоняем в массив и дальше используем.
Но эта не самая большая проблема. MMU все таки нет а значит будет тоже самое, что и с uclinux.



Это вы наверно имеете в виду как выполняется динамическое связывание для dll.
Это известный стандартный способ, но для этого ядро должно содержать в себе таблицу символов.
В моих проектах с RTOS такая таблица заняла бы более 300 Кб в RAM.
Даже жирным однокристалкам с Cortex это будет уже за много.
Это не считая того, что сами загруженные таким образом модули подвергаются модификации, т.е. должны выполняться из RAM или по крайней мере по началу туда грузиться.
Решение, скажем прямо, не совсем для малых RTOS.
Go to the top of the page
 
+Quote Post
a9d
сообщение Dec 31 2012, 14:59
Сообщение #8


Местный
***

Группа: Участник
Сообщений: 312
Регистрация: 9-04-10
Пользователь №: 56 532



А как планируете решать проблему с MMU ? Также как и в uclinux?
Go to the top of the page
 
+Quote Post
AlexandrY
сообщение Dec 31 2012, 15:31
Сообщение #9


Ally
******

Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050



Цитата(a9d @ Dec 31 2012, 16:59) *
А как планируете решать проблему с MMU ? Также как и в uclinux?


В тех однокристаллках которые я подразумеваю нет MMU, соответственно нет и проблемы wink.gif

Но интересно какую проблему MMU вы имеете ввиду?
Go to the top of the page
 
+Quote Post
a9d
сообщение Dec 31 2012, 15:37
Сообщение #10


Местный
***

Группа: Участник
Сообщений: 312
Регистрация: 9-04-10
Пользователь №: 56 532



Вот об отсутствии и идет речь.

Вот простой пример.
В программе A по смещению 0 располагается переменная int.
В программе B по смещению 0 располагается переменная char.
Как планируете решать эту ситуацию?

В uclinux каждая программа знает какое адресное пространство занимает. Это создает неудобства.
Go to the top of the page
 
+Quote Post
AlexandrY
сообщение Dec 31 2012, 16:50
Сообщение #11


Ally
******

Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050



Цитата(a9d @ Dec 31 2012, 17:37) *
Вот об отсутствии и идет речь.

Вот простой пример.
В программе A по смещению 0 располагается переменная int.
В программе B по смещению 0 располагается переменная char.
Как планируете решать эту ситуацию?

В uclinux каждая программа знает какое адресное пространство занимает. Это создает неудобства.


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

Я в начале привел сценарий именно когда загружается бинарник сторонней программы специально слинкованной для размещения по определенному адресу.
Это самый элементарный подход для организации загрузки.

Существуют несложные механизмы и по размещению программы с произвольного адреса в пределах разрешенных зон. Это например elf-загрузчики. Они грузят не бинарник, а объектный файл с формате elf. При загрузке они превращают файл в бинарник с подменой адресной информации в операторах на реальные адреса.

Go to the top of the page
 
+Quote Post
haker_fox
сообщение Jan 2 2013, 09:39
Сообщение #12


Познающий...
******

Группа: Свой
Сообщений: 2 963
Регистрация: 1-09-05
Из: г. Иркутск
Пользователь №: 8 125



QUOTE (AlexandrY @ Jan 1 2013, 01:50) *
Существуют несложные механизмы и по размещению программы с произвольного адреса в пределах разрешенных зон.

Товарищи, а можно послать меня по нужным ссылкам? Я несколько нашел, но может быть Вы предложете более интересные материалы. AlexandrY, для меня Вы специалист очень высокого уровня, и хотелось бы получить пинок именно от Вас rolleyes.gif


--------------------
Выбор.
Go to the top of the page
 
+Quote Post
vshemm
сообщение Jan 2 2013, 20:42
Сообщение #13


Частый гость
**

Группа: Участник
Сообщений: 167
Регистрация: 15-08-07
Пользователь №: 29 803



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

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

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

Про загрузку кода по произвольным адресам - гуглите relocation и fixup. Классическая дока по эльфам (собственно,
виндовый PE формат это упрощенный эльф) - http://www.becbapatla.ac.in/cse/naveenv/docs/LL1.pdf
Там есть все - разные архитектуры, разный эндианнес, вопросы MMU...
Go to the top of the page
 
+Quote Post
AlexandrY
сообщение Jan 3 2013, 07:51
Сообщение #14


Ally
******

Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050



Цитата(vshemm @ Jan 2 2013, 22:42) *
Про загрузку кода по произвольным адресам - гуглите 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"
Go to the top of the page
 
+Quote Post
vshemm
сообщение Jan 8 2013, 16:07
Сообщение #15


Частый гость
**

Группа: Участник
Сообщений: 167
Регистрация: 15-08-07
Пользователь №: 29 803



Цитата(AlexandrY @ Jan 3 2013, 11:51) *
Насчет loader-ов есть сильное семантическое отличие этого понятия в контексте компьютерной информатики и малых встраиваемых систем.


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

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

Разница между "компьютерными системами" и "малыми встраиваемыми системами" заключается только в
ресурсах. Т.е. надо дать определение, что такое малые встраиваемые. Моя эмпирическая оценка -
это 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.
Go to the top of the page
 
+Quote Post

3 страниц V   1 2 3 >
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 27th July 2025 - 08:06
Рейтинг@Mail.ru


Страница сгенерированна за 0.02075 секунд с 7
ELECTRONIX ©2004-2016