Vlákno názorů k článku Operační systém NuttX: programování s RTOS na embedded zařízeních od ventYl - "Your scientists were so preoccupied with whether or...

"Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should."

Otazka je, ci je kompatibilita s POSIXom v embedded priestore niekomu na nieco vobec dobra. Dovolim si tvrdit, ze ani nie. Niektore casti POSIXu su uzitocne, vela ich je `meh` a niektore su ciste peklo.

Schopnost spustit embedded kod na Linuxovej masine sa da pohodlne dosiahnut aj bez tohto traitu.

Mať možnosť použiť hotový POSIX kód a priohnúť ho na embeded zariadenie je veľký benefit.

Reálne použitie je také, že môžeš mať rovnaký algoritmus a bežať ho v serverovej verzii a aj v embedded verzii pre malé zariadenie. Nie si potom obmedzený nástrojmi, ktoré ti ponúka development kit toho embedded zariadenia/ope­račného systému. Hovorím to z autopsie.

E: Aby som to zhrnul - je to dobré kvôli škálovatelnosti.

11. 6. 2026, 11:53 editováno autorem komentáře

Kolik je takovych use cases / domen problemu?

Kupodivu velmi mnoho. Velmi se hodi, kdyz clovek muze jen tak prikompilovat treba sqlite3 nebo MQTT.

Minimálne jedna doména, na ktorej som pracoval. A iba pre nás by výrobca ten produkt nerobil.

Vse kolem kryptovani.

To bude vyžadovať silnejší HW kde bude viac prostriedkov navyše a overhead nebude tak vadiť. Tam kde ich nieje nazvyš je CMRX vyhovujúce riešenie.

Lenze use caseov, ktore toto vyzaduju je pramalo. A use caseov, ktore toto dokazu prezit pri spusteni na znacne memory-constrained MMU-less HW je este menej.

A za nejakou hranicou to ohybanie uz zacne dost vadit. Napr. cely koncept shell-centrickeho pristupu na embedded zariadeni je tak nejako mimo misu, lebo embedded je hlavne o tom, ze pri normalnej prevadzke sa nikto v tom pocitacovom systeme nehrabe a ten system sa tvari, ze tam nie je.

Iste, NuttX ide nabehnut aj na regulernej x86tke. Tam to ale podla mna uplne straca zmysel, lebo na prakticky akejkolvek x86tke nabehnem aj Linux alebo NetBSD, ktore poskytuju ovela standardnejsie prostredie.

Algoritmus, ktory bude bezat v serverovej aplikacii aj v embedded prostredi mozem mat aj bez POSIXu, ak ten algoritmus je decouplovany od prostredia v ktorom bezi. To zas nie je tak velka raketova veda.

Treba muj OS neni vyslovene shell centric, ale po vice nez stovce aplikaci/projektu existuje jen par vyjimek, kde by shell nebyl soucasti, a jen velice malo produkcnich releasu melo shell vypnuty.

Mozna nedelam spravny embedded, nebo jsem vadnej s tim pristupem - ale pro me mit shell (dokonce s napovedou na TABu) byla vzdy vyhodou meho reseni, oproti nejake jednorazovce, kterou musit porad updatovat jako ovce.

S cim prijdete priste? Ze pouzivat #define pro konstanty je zle, a mame to upravovat na peti mistech, protoze to neni dost embedded?

Ne, naopak, pridavam se: UNIXovy "stavebnicovy" pristup mnoha modularnich drobotin, ktere poslepovany dohromady tvori mocny a hlavne flexibilni system, se velmi hodi.

Samozrejme tam vzdy bude nejaka rezie, suboptimalita proti hypotetickemu monolitickemu reseni, ale je to vyvazeno nesmirnou usporou mozku a casu vyvoje a nasledne schopnosti improvizovat, at uz na strane autora nebo uzivatele.

Ocenili jsme to i v druzici, bylo to naprosto zasadni.

Je to podobne i v HW ci mechanice. Clovek muze delat vetsi, jednoucelove celky, nebo to udelat vetsi a tezsi, ale vice modularni.

Kdyz jsem psal svuj IP stack pro AVR, tak jsem se rozhodl ze tam bude BSD sockets API, na rodil od tehdy konkurencnich ip stacku ktere meli nejaky frikulinsky callback system.

Priorita byla moznost portovat nebo testovat kod primo i na beznem OS. Jiste.. dalo by se to udelat mozna nejakou zbytecnou mezivrstvou, ale proc investovat sve prostredky do slepe ulicky.

To je v pohode, pretoze BSD socket API, bez ohladu na tom kde pobezi, stale bude robit konceptualne tu istu robotu.

Problem s plnohodnotnym POSIXom v rydzo embedded pouziti je, ze na niektore veci je POSIX overkill, pretoze pocita s konceptom ovela komplikovanejsim, nez je nutne. V pripade NuttX-u je to napriklad existencia "suborov".

Subory su v embedded do znacnej miery mimo misu. Vela embedded systemov realne ani suborovym systemom nedisponuje, lebo je to pre nich malo muziky za vela penazi. Vystacia si s jednoduchym key-value storage, ktory v pripade NuttX je nutne pretahovat cez VFS vrstvu, ak to nema byt riesenie robene na kolene.

Pekne pre tie styri aplikacie, co potrebuju hierarchicku, dynamicky generovanu konfiguracnu strukturu s moznostou introspekcie. Pre zvysok sveta overkill.

Podobne tazkopadne su v embedded svete POSIXove synchronizacne primitivy.