Релиз встраиваемой системы реального времени Embox v0.3.25

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

фантасмагория какая то:)

А есть какая-нибудь статья на эту тему, сравнивающая эту дичь с «классическими» микроядрами? Реально интересно, но по Вашим комментариям понять что-то сложно.

Ты про какие привилегии? Какие потоки и процессы? Я про привилегии исполнения кода на уровне хардвари, например в х86 есть четыре уровня (т.н. кольца защиты), для армов вроде два (kernel mode, user mode), это на хардварном уровне задано, архитектура проца.

Все правильно, я них же.

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

а вот тут не точность. Переключение не между уровнями привелегий, а между процессами (приведенная Вами смена карты памяти), приводит к накладным расходам. Ядерный процесс, через который по идее идут все сискалы (организован IPC), ничем в этом плане не отличается от пользовательского. Так вот, если сделать все процессами (медленно, как Вы сами, отметили) то не важно, идет ли переключение привелений или нет. Ну естественно, всегда будет один ядерный процесс!

Я, конечно, извиняюсь заранее за невнимательность, но где может работать эта штука? И какие системные требования? И вообще, что даёт? Интересует в плане всяких H3 процов, на которых OrangePI работает и всякой ерунды мелкой типа STM32F10 или ATMega32U4.

сравнивающая эту дичь с «классическими» микроядрами

:) Да, это действительно выглядит как дичь, но очень не хочется завязываться на «классические» микроядра. То есть, нашей идеей была попытка выйти за рамки классического подхода микроядро — медленно и надежно (много сисколов) монолитное — быстро, но менее надежно. Ведь в реальных системах сейчас как говориться 'все сложно". И в одной системе зачастую встречаются оба эти подхода. Пример fuse для linux.

Изначально Embox ориентировался на совсем мелкие системы (deep embedded), отсюда думаю кто то написал на википедии что архитектура экзоядро, мы когда то так и говорили. То есть еще более легкое чем микроядро, ресурсы проверяются только на старте, дальше все идет напрямую. Но потом, то ли университет сказался, то ли еще что, но захотелось поэкспериметировать. И предоставить разработчику самому проектировать архитектуру ОС (то есть где то нужно микроядро, где то монолит, где то еще что то).

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

но где может работать эта штука? И какие системные требования?

Архитектуры: ARM, x86, SPARC, Microblaze, MIPS, PPC, E2k

Для адекватного функционала нужно 8кб ОЗУ это STM32VLDISCOVERY.

На atmega наверное нет смысла запускать, то есть ничего не даст.

OrangePI - планируем, но пока руки не дошли. А так на подобных ARM-ах cortex-A запускается.

H3 процов - это Allwinner Technology Не сталкивались, архитектура то поддерживается (32 битный арм), но переферию прийдется допиливать.

И вообще, что даёт?

Ну порой мы говорим, что можно использовать приложения Linux без него, и на маленьких платформах. Пример PJSIP телефон на stm32f7discovery.

Но данную идею раскритиковали. То есть если есть OrangePI то наверное дешевле будет использовать Linux.

Еще мы говорим, что можно использовать приложения Linux в одной системе с задачами реального времени, ножкой пошивилить, с большой точностью например, с управлением по веб-интерфейсу.

arm

на заборе много чего пишут.

Техническая поддержка <support@rusbitech.ru> К сожалению ARMv5 не подходит.

Там все начинает от ARMv6

Пришлось запилить квази-барематал без картографии.

Хл динамичнее

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

я в курсе, но тут речь шла про использование в закрытых же проектах не так ли?

Зависит от лицензии. Лицензия у сабжа вот такая:

зависит да, но в production я скорее возьму qnx да. (я не про микроконтроллеры что если)

спаибо. Разработчик ОС которая все таки существует и даже используется, не компетентен в архитектуре ОС.

это может быть вполне реалистичной картиной.

Давайте так, если интересно, что имеется в виду. Я попытаюсь объяснить, если цель комметрариев сказать, что кто то некомпетентный несет бред, то просто соглашусь. Ведь описанная идеальная картина, еще действительно не полностью реализована.

описана нереальная картина, вы ж понимаете что не только драйвера в микроядре вынесены из ядра? да или нет?

Я пытаюсь об этом сказать. То есть Вас не смущает, что в Embox MMU нет, а приложения пишутся со стандартной точкой входа, main(). я не сомневаюсь, что Вы понимаете, что в одном образе пересекающихся символов быть не может.

это решаемый вопрос, причем это реально.

Дальше, для чего то у нас есть понятия модуля, и зачем то, сначала код линкуется в отдельные объектники, библиотеки и так далее.

побольше подумайте зачем вам эти понятия и ответите себе на вопрос.

Ну и наконец, в описании модулей (да есть и такое понятие) есть прямо такое ключевое слово depends

вдумчиво читайте мой коммент который был ранее.

хозяин барин, нравиться QNX используйте его.

дело не только в нравится или ненравится, дело в ф-ли.

ну для микроконтроллеров, достаточно других проектов.

и? идеального то все равно нет, не было и не будет, а чем больше выбор тем лучше.

Мы же считаем что пытаемся привнести какую то новую идею (парадигму если хотите). Возможно Вы правы и у нас не получится, увидим.

запуская на этом quake? простите, но я не вижу тут ничего нового, и идеи никакой там не вижу.

но в production я скорее возьму qnx

так-то от QNX давно все отказались в пользу Linux

Папа-программист рассказал школьникам о QNX?

так-то от QNX давно все отказались в пользу Linux

нет. в linux нет RT, и не будет, все эти RTLinux это несерьезно.

Папа-программист рассказал школьникам о QNX?

QNX не работает без MMU, так что не понимаю причем тут это. другой класс ОС совсем.

нет. в linux нет RT, и не будет, все эти RTLinux это несерьезно

да это давно уже не проблема Linux - микроядерные гипервизоры наверно на каждом углу клепают они и сертификацию системы упрощают.

да это давно уже не проблема Linux - микроядерные гипервизоры наверно на каждом углу клепают они и сертификацию системы упрощают.

далеко не всегда и очень далеко не везде.

далеко не всегда и очень далеко не везде

кто-то наверно и на QNX дрочит. QNX не даст такой реалтайм как RTOS на микроконтроллерах, гибридный SoC c Linux и микроконтроллерной RTOS на разных ядрах порвет его по всем параметрам

QNX не даст такой реалтайм как RTOS на микроконтроллерах,

никто с этим не спорит

гибридный SoC c Linux и микроконтроллерной RTOS на разных ядрах порвет его по всем параметрам

ну ну, это все зависит от того что там крутится и от требований, сейчас QNX запускается как одна из OS на SoC с гипервизором, и туда ваш linux никто в здравом уме не пихает.

сейчас QNX запускается как одна из OS на SoC с гипервизором, и туда ваш linux никто в здравом уме не пихает

туда - это куда :) и почему туда не поставить Linux если там есть гипервизор ?

https://www.electronicsweekly.com/market-sectors/automotive-electronics/green...

Что с SMP на ARM? Пока увидел только для x86.

это решаемый вопрос, причем это реально.

Автоматически линкёром переименовываете символы?

я в курсе, но тут речь шла про использование в закрытых же проектах не так ли?

насколько я знаю, лицензия QNX подразумевает плату за экземпляр. И передача прав вообще невозможна. Поэтому Linux в закрытых проектах используют, VxWorks (хотя он закрытый, но слышал что переименовать умудрялись) тоже, а вот QNX вроде нет. Но могу ошибаться.

зависит да, но в production я скорее возьму qnx да. (я не про микроконтроллеры что если)

все таки лицензия влияет, были проекты, когда хотели взять QNX, но взяли сабж, из за лицензии.

вы ж понимаете что не только драйвера в микроядре вынесены из ядра? да или нет?

да, что такое микроядро, я понимаю. И Таненбаума конечно читал. Но как я уже написал в комментарии выше, сейчас реальные проекты, (и иследовательские тоже) стремятся совмещать в себе лучшие свойства подходов. Естественно понимая, что микроядро-надежно и медленно, монолит ... У нас появилась идея выйти за рамки чистых архитектур и дать конечному разработчику, возможность задать свойства системы. Для этого используем дополнительную информацию из описания модулей (о которых Вы предложили подумать).

Теперь если считаем что у нас есть мета-информация о модуле (будь то драйвер, службы или еще что то), который может работать как напрямую (условно назовем это функциями read/write), так и в качестве сервера через сообщения (IPC) и так далее, то мы можем сгенерить обертку (или не генерить, если не нужно) которая запускается как процесс, а вызовы общения (read/write) переопределить, скажем в макросах, или в инлайн функциях. И тогда получается, что мы можем использовать один и тот же код и в качестве классического драйвера, и в качестве службы в микроядре. Тут есть где то нереалистичный сценарий?

Собственно, к сожалению вынужден с Вами согласиться выглядит странно. Поскольку до конца это не реализованно. Но мы работаем в данном направлении и какие то результаты все таки есть. И пока называть данную идею бредом, не готов. Но вполне возможно через какое то время, я так и сделаю.

Автоматически линкёром переименовываете символы?

Да, и запихиваем в секцию точек входа в приложение. Если система без mmu то это пока наилучший вариант

SMP на ARM

Сейчас на больших армах (cortex-a) он сплошь и рядом, странно когда его нет. Для микроконтроллеров, обычно не используется smp, поскольку если есть ядра, то они несут разные функции, например cotrex-m0 для совсем маленьких задач в спящем режиме, и cortex-m4 и выше

Другое дело например системы реального времени, о которых тут пошла речь выше, не очень укладываются в многоядрерность. Например, ARINC-653 (для бортовых систем), только недавно стал описывать многоядерные системы, и то это экспериментальный раздел.

туда - это куда :) и почему туда не поставить Linux если там есть гипервизор ?

Вы совершенно правы, один из вариантов добиться предсказуемости это использовать гипервизор архитектура MILS стандарт (ARINC-653), и туда в один из разделов можно поместить Linux.

но я думаю, тут речь идет о другом класе ОСРВ, для управления каким нибудь мотором, нужно чтобы квант времени был ну скажем 1 мкс, а это с помощью гипервизора очень трудно добиться, если вообще возможно

QNX не даст такой реалтайм как RTOS на микроконтроллерах, гибридный SoC c Linux и микроконтроллерной RTOS на разных ядрах порвет его по всем параметрам

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

да это давно уже не проблема Linux - микроядерные гипервизоры наверно на каждом углу клепают они и сертификацию системы упрощают.

Согласен. Но Вы говорите про один класс систем реального времени, назовем их бортовыми системами, ARINC-653 у них просто по стандарту положено использовать гипервизор.

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

тут важно понимать, что несколько физических чипов и соединение между ними

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

вам пора познакомиться с гетерогенными системами на кристалле

https://www.nxp.com/products/processors-and-microcontrollers/arm-based-proces...

дело не только в нравится или ненравится, дело в ф-ли.

простите, ф-ли, это что?

а чем больше выбор тем лучше.

согласен.

запуская на этом quake? простите, но я не вижу тут ничего нового, и идеи никакой там не вижу.

Ну тут могу только повториться, квака - это демонстрация возможностей графического стека и что приложения Linux можно запускать почти без изменений. То есть разрабатывать на обычном linux как то привычнее, а дальше запускаешь это на целевой системе.

кто-то наверно и на QNX дрочит.

вы правы qnx давно куплен blackberry. и rtos уже совсем не основное направление. Просто в россии очень многие под ним сидят.

вам пора познакомиться с гетерогенными системами на кристалле
https://www.nxp.com/products/processors-and-microcontrollers/arm-based-proces...

спасибо, с imx8 знаком, лежит тут рядом на столе.

Но как это отменяет, приведенные Вами цитаты?

спасибо, с imx8 знаком

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

что-то сомневаюсь

Прислать фотографию? :)

ядра cortex-m которые совершенно независимо работают от ядер cortex-a

я говорил о разных чипах а не ядрах. Когда все ядра в одном чипе это безусловно улучшает ситуацию. В этом случае, обычно вообще никакую ОС на микроконтроллеры не ставят, а используют какой нибудь самописный цикл именно для обработки прерываний.

Ну и гипервизор в таких системах тоже не спасает. Гипервизор, насколько я знаю, ставят на большие системы, и там не совсем обычный гипервизор, а со статическим расписанием. То есть разработчик описывает расписание и остальные ресурсы, и он должен гарантировать что все задачи выполняться за время отведенное расписании. Поэтому я и говорю что кванта времени в 1 мкс тяжело добиться.

Ну тот же ThreadX даёт SMP, ещё в ecos, nuttx, sylixos (из открытых). Хотя глубоко не копал. Но... соглашусь, там где видел использование ThreadX, там от RTOS только название оставалось. Я могу ошибаться, но для меня RTOS в первую очередь - детерминированное поведение системы. Если его нет, то и RTOS нет.

но для меня RTOS в первую очередь - детерминированное поведение системы.

Да, совершенно с Вами согласен. Тут вопрос только как этого добиться.

же ThreadX даёт SMP

ну я имел в виду не микроконтроллеры, что в них нет smp, а не rtos - ы.

ну я имел в виду не микроконтроллеры, что в них нет smp, а не rtos - ы.

В нашем современном мире уже трудно понять, что такое микроконтроллер. Tiny13 - микроконтроллер, а Cypress FX3 микроконтроллер? А ZynQ Ultrascale+? Или BCM2837B0, на малинке там на VideoCore4 (двухядерном) ThreadX, а на ARM ядрах... ну можно и Linux.

я говорил о разных чипах а не ядрах
Ну и гипервизор в таких системах тоже не спасает

я про одно а вы про другое - разговор ни о чем, ваша ОС вообще где-то далеко в стороне от современных трендов как и её разработчики :)

я про одно а вы про другое - разговор ни о чем, ваша ОС вообще где-то далеко в стороне от современных трендов как и её разработчики :)

:))))) вот и поговорили :) Вроде про чипы, ядра, гипервизоры, rtos и внезапно «ваша ОС и ее разработчики» :)))

Кстати, а от каких трендов? Попыток использовать Linux в системах реального времени, так я с Вами согласился, попытки есть! В нашей ОС в том числе, я имею в виду прикладное ПО для linux, ну и в каком то виде некоторые интерфейсы ядра, идеи и так далее.

Попыток использования гипервизоров как основу определенного класса ОСРВ, так вроде тоже согласился :) В нашей ОС ... ну Вы поняли :)

В нашем современном мире уже трудно понять, что такое микроконтроллер.

Согласен, всякие SoC системы на кристалле, все спутали.

Наверное я бы определил микроконтроллеры не как ядра cortex-m, и не как наличие или отсуствие MMU, а наличие памяти прямо на кристалле

Например, Tiny13 имеет встроеную flash-память, BCM2837B0 может только с внешней памятью работать, ZynQ Ultrascale+ - это вообще монстр хоть и предназначен для систем реального времени.

Запуск Linux тоже не показатель, где то видел что запустили на 8-разрядной avr- написав эмулятор :)

наличие памяти прямо на кристалле

Тоже сомнительное деление. Тот же Cypress FX3. Ядро - ARM926E-JS. Там нет флеш памяти, но есть 512кБ RAM, куда загрузчик из ROM может загрузить код из SPI-flash/I2C-EEPROM или дождаться его по USB и передать управление. Больше кода - меньше RAM. По сути - микроконтроллер, но флеша нет.

Или же Cypress FX2, там ядро 8051, и есть куча контроллеров с аналогичным ядром, где флеш на борту, а вот в FX2 - нет, грузится аналогично FX3 (ну или FX3 аналогично FX2, с какого ракурса смотреть).

Но на них да, SMP точно нет :)

Но, в принципе, судя по беглому гуглежу, народ склоняется к тому, что микроконтроллер - самодостаточная тараканина, где и flash и RAM (если нужна) на борту, а SoC - тот же процессор, который к себе на кристал забрал кучу периферии, но оставил RAM и постоянные накопители снаружи. В контексте этого, будет забавно увидеть какой-нибудь, гм, микроконтроллер, с 4 ядрами Cortex-A53 и встроенной flash/RAM :-D

Любая классификация не вечна. Вот были смартфоны и были коммуникаторы. Потом они слились в экстазе, а поскольку победило таки смартфонное начало, то слово «коммуникатор» почти все забыли. :(

P.S. Лично мне бы хватило КПК с возможностью выхода в интернет и отдельным девайсом - кнопочный (но не примитивный) телефон для звонков и SMS. Но рыночек порешал по-другому. И при взгляде на все эти SoC-и и микроконтроллеры меня по-прежнему сверлит идиотская мечта, нельзя ли из них сделать тот самый КПК. Но сам я это, конечно, не осилю.

народ склоняется к тому, что микроконтроллер - самодостаточная тараканина, где и flash и RAM

да, я тоже к этому склоняюсь :)

забавно увидеть какой-нибудь, гм, микроконтроллер, с 4 ядрами Cortex-A53 и встроенной flash/RAM

сомневаюсь, что такой может появиться на рынке. То есть микроконтроллеры это прежде всего для относительно небольших задач, хотя конечно «640 кб хватит всем», и ставить туда огромный Cortex-A53, который перекрывает по затратам всю периверию, как то очень странно.

К тому же насколько я помню, cortex-m от cortex-a отличается и в части модели памяти. Большие армы подразумевают всякие фишки для динамической (вшешней памяти).

И при взгляде на все эти SoC-и и микроконтроллеры меня по-прежнему сверлит идиотская мечта, нельзя ли из них сделать тот самый КПК.

Конечно можно. Но рынок узкий, и по соотношению цена/качество данный вид будет сильно уступать смартфонам. То есть рынок сейчас подразумевает, что пользователь может доставить приложения из репозитория. А если такой возможности нет или репозиторий маленький, то спрос падает. С КПК наверное это и произошло.

а вот тут не точность. Переключение не между уровнями привелегий, а между процессами (приведенная Вами смена карты памяти), приводит к накладным расходам. Ядерный процесс, через который по идее идут все сискалы (организован IPC), ничем в этом плане не отличается от пользовательского. Так вот, если сделать все процессами (медленно, как Вы сами, отметили) то не важно, идет ли переключение привелений или нет. Ну естественно, всегда будет один ядерный процесс!

Никакой неточности, причём здесь процессы, IPC и пр. ? Я говорю о смене текущего уровня привилегий процессора (hint: открой доку на х86, смотри флаги CPL, IOPL). В монолитном ядре смена уровня привилегий никогда не происходит, хоть там 100500 потоков и процессов (единственный случай - вызов ядра пользовательским процессом, но это совсем другая история). Если это не так - ядро НЕ монолитное, и обычно зовётся микрокернелом потому что в нулевом кольце защиты крутиться только небольшая жизненно важная часть ядра.

добавили первую версию (точнее 0.1) новой документации .

русский мануал пользователя

Надеюсь продолжим улучшать.

Если это не так - ядро НЕ монолитное, и обычно зовётся микрокернелом потому что в нулевом кольце защиты крутиться только небольшая жизненно важная часть ядра.

дело не в уровне привилегий (хотя конечно, глупо запускать изолированный процесс, не в режиме ядра). А в том что все находиться в одном ядерном процессе, то есть в адрессном пространстве, и переключаться никуда не нужно. Другое дело если у вас ядерный процесс это только планировщик и IPC, тогда естественно вам нужно переключаться часто. Но повторюсь, представить когда файловая система в отдельном сервере, но с привелегиями ядра, вполне реально.

Спасибо!