LINUX.ORG.RU

LOR, it's BuguRTOS, I need help!

 , ,


1

4

Привет, LOR!

У меня небольшой творческий крысис, суть такова:

  1. в течение нескольких месяцев планирую зарелизить BuguRTOS-1.0.0 и окончательно перейти на семантическое версионирование;
  2. сделано это будет на основе текущей ветки (0.9.х);
  3. в будущем BuguRTOS будет представлять собой что-то вроде xenomai, только для микроконтроллеров;
  4. то есть будет относительно маленькое портируемое ядрышко, к которому можно будет прикручивать разные RTOS API;
  5. дальше хочу но основе BuguRTOS сделать микроядро b4 (набор костылей и велосипедов в духе L4);

Почему?

Интересно же!

Так вот на пути к b4 есть определенные проблемы:

  1. есть системные вызовы BGRT_SYSCALL_SYNC_OWN и BGRT_SYSCALL_SYNC_TOUCH, которые повышают приоритет задачи до высшего и делаются перед вызовом BGRT_SYSCALL_SYNC_SLEEP;
  2. есть итерационные системные вызовы BGRT_SYSCALL_SYNC_SLEEP, BGRT_SYSCALL_SYNC_WAKE, BGRT_SYSCALL_SYNC_WAIT, их надо вызывать в цикле, пока завершаются со статусом BGRT_ST_ROLL;
  3. пока все это работает в закрытой системе (монолитная прошивка микроконтроллера) и использыется API ядра, проблем нет;
  4. но это не годится для проекта микроядра, т.к. «неправильное использование» этих системных вызовов может приветси к DoS;

Решение этой проблемы я вижу в том, чтобы:

  1. не использовать BGRT_SYSCALL_SYNC_TOUCH в микроядре;
  2. переписать BGRT_SYSCALL_SYNC_OWN так, чтобы в случае неудачи происходил вызов BGRT_SYSCALL_SYNC_SLEEP и задача блокировалась;
  3. скрыть от пользователя итерационную природу BGRT_SYSCALL_SYNC_SLEEP, BGRT_SYSCALL_SYNC_WAKE, BGRT_SYSCALL_SYNC_WAIT, то есть пользователь должен делать один вызов, а цикл должен делать диспетчер системных вызовов без участи пользователя;

С последним пунктом самое интеерсное, ибо цикл можно сделать за счет:

  1. подмены адреса возврата в стеке прерванной задачи (грязненько!!!);
  2. в ядре с вытеснением в одной точке (замедлит обработку некоторых прерываний);
  3. сделать ядро полностью вытесняемым с исполнением в отдельном потоке(надо писать слой виртуализации прерываний, замедлит обработку нектороых прерываний, надо память под стек потока ядра);

Что из этого выбрать???

Можете считать голосовалкой...

в течение нескольких месяцев планирую зарелизить BuguRTOS-1.0.0

Давай, я в тебя верю.

CYB3R ★★★★★ ()

переписать BGRT_SYSCALL_SYNC_OWN так, чтобы в случае неудачи происходил вызов BGRT_SYSCALL_SYNC_SLEEP и задача блокировалась;

(c) Denis Popov. Level up. My success story.
Извини, я не удержался. А если по теме — все три варианта одобряю, дерзай. Держи нас в курсе.

znenyegvkby ()
Ответ на: комментарий от loz

По разному.

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

shkolnick-kun ★★★★★ ()
Ответ на: комментарий от anonymous

Для наследования приоритетов.

Обычно делают «наивную» реализацию наследования приоритетов с циклом внутри критической секции.

Я такой вариант отбросил и вынес циклы из критических секций, чтобы получить сложность системного вызова O(1).

shkolnick-kun ★★★★★ ()
Ответ на: комментарий от Deleted

А что оно делает?

Вызов BGRT_SYSCALL_SYNC_OWN пытается поиметь примитив синхронизации, а BGRT_SYSCALL_SYNC_TOUCH только трогает за попу.

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

shkolnick-kun ★★★★★ ()
Ответ на: комментарий от tailgunner

Уж какие есть...

Просто bgrt_sync_t - базовый тип, из которого можно путём обертывания получить мьютекс\семафор\условную переменную\IPC-ендпойнт...

Соответственно, трудно было дать связанному с этим типом безобразию традиционные названия...

shkolnick-kun ★★★★★ ()
Ответ на: комментарий от shkolnick-kun

И у этого необычного типа стопудово примитивы с необычной семантикой. Тем не менее, ты спрашиваешь о них, ничего не объясняя.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Я спрашиваю об общем устройстве ядра, это [должно быть] понятно более широкому кругу лиц, чем я и моя с@$%ая кошка...

shkolnick-kun ★★★★★ ()
Ответ на: комментарий от tailgunner

Насчет необычности: наиболее близкий аналог - RPC endpoint, соответственно, аналогия такая:

  • BGRT_SYSCALL_SYNC_SLEEP - call(ep,...)
  • BGRT_SYSCALL_SYNC_WAIT - wait(ep,...)
  • BGRT_SYSCALL_SYNC_WAKE - reply(ep,...)
  • BGRT_SYSCALL_SYNC_OWN - попытаться открыть endpoint для wait/reply...
shkolnick-kun ★★★★★ ()
Ответ на: комментарий от shkolnick-kun

Я спрашиваю об общем устройстве ядра

Общее устройство ядра, естественно, должно быть таким, что опасные операции доступны только trusted-коду (наверное, ты это имел в виду под «монолитным»); а самовольное повышение приоритетов системой (если это имеется в виду под «систмные вызовы [...] повышают приоритет задачи до высшего») - это за гранью фола.

соответственно, аналогия такая

Похоже на send-receive-reply, но названия, конечно, кондовые. Даже если они соответствуют SRR, текст трудно читать, мысленно производя замену. Кстати, что семантику TOUCH ты не описал.

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 2)
Ответ на: комментарий от tailgunner

Кстати, что семантику TOUCH ты не описал.

Оно просто вызывается перед SLEEP, чтобы те, кто хочет делать WAIT или сразу WAKE дождались этого самого SLEEP...

а самовольное повышение приоритетов системой
- это за гранью фола.

Это лучше, чем цикл с неизвестным числом шагов при запрещенных прерываниях как в ChibiOS/RT... То есть это плохо, но ничего лучше на ум не пришло

shkolnick-kun ★★★★★ ()
Ответ на: комментарий от tailgunner

Похоже на send-receive-reply, но названия, конечно, кондовые.

wait - это receive call - это send_and_receive

shkolnick-kun ★★★★★ ()

поизучай лучше zephyr project, как никак от windriver - мастер рубить капусту на rtos и они наверняка знакому с DO-178B

dimon555 ★★★★★ ()
Ответ на: комментарий от dimon555

Посмотрел, интересная вещь, сделано близко к 3 варианту, не совсем понял, что там с требованиями к ресурсам...

shkolnick-kun ★★★★★ ()

есть системные вызовы BGRT_SYSCALL_SYNC_OWN и BGRT_SYSCALL_SYNC_TOUCH, которые повышают приоритет задачи до высшего и делаются перед вызовом BGRT_SYSCALL_SYNC_SLEEP;

переписать BGRT_SYSCALL_SYNC_OWN так, чтобы в случае неудачи происходил вызов BGRT_SYSCALL_SYNC_SLEEP и задача блокировалась;

А почему бы не переписать так, чтоб вызов BGRT_SYSCALL_SYNC_SLEEP происходил вообще автоматом после вызова BGRT_SYSCALL_SYNC_TOUCH тогда? В независимости от успеха.

anonymous ()

Привет всем!

Готовлю новый релиз, кому не лень, прошу глянуть в исходники и диоксиген-комменты, вдруг, чего накосячил.

Зананнее спасибо!

shkolnick-kun ★★★★★ ()
Последнее исправление: shkolnick-kun (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.