Jaderné noviny 170 (diskuse)

[Petr Krčmář]

Ahoj, nebylo by naskodu vysvetlit, co je to RTLinux (predpokladam, ze Real Time, ale co to je nevim) a tech par zkratek. Jinak klasicky diky za Jaderne noviny a drzim ti Leosi pesti, abys v nich pokracoval.

Peter

[Leoš Literák]

RealTime (RT) oznacuje operacni system, ktery dokaze schedulovat (pridelovat procesor) procesy prediktivnim zpusobem (da se vypocitat ci zarucit, kdy na proces prijde rada).

V podstate jde o to, ze nektere aplikace a ovladace maji extremni naroky na presnost, kdy maji mit procesor. Treba kazde 2 nanosekundy. Normalni kernel toto nedokaze zarucit, jednou to treba stihne, jindy o fous ne a potreti nekdo zrovna provadi neco narocneho a tak se ten proces vzbudi az za 10 milisekund. Jenze ten driver treba kvuli tomu prijde o cenna data, ktere nestihl precist z externiho zarizeni. A kvuli tomu vybuchne jaderna elektrarna nebo umre pacient.

Proto existuji real time operacni systemy, ktere dokazi zarucit, ze se proces dostane ke slovu ve chvili, kdy to potrebuje.

[Michal Dobeš]

V podstatě máta pravdu. RT systém má definovanou odezvu, ať už se jedná na jakou dobu maji přiděleny jednotlivé procesy CPU, kdy jim zase bude nejpozději (případně i nejdříve) procesor opět přidělen, tyto možnosti jsou dány zvoleným RT schedulerem. Dále jsou definovány odezvy na přerušení, je třeba řešena problematika nezablokování nějaké části atd. Jen ty uváděné časové nároky jsou trošku nepřesné. Na architektuře IA32 si o nanosekundách můžete jenom zdát. V případě RT linuxu je řekneme přesnost časování a i odezev na přerušení v řádu jednotek mikrosekund, většinou je chyba pod 10 us, záleží dost na použitém HW a toho co vše běží. Pokud máte jádro rozšířené o RT podporu a nad tím si pustíte normální XFree, tak vám jde RT do kopřiv, je vhodné vše překompilovat v tomto prostředí znova, protože RT část pro ten zbytek virtualizuje např i zakázaní přerušení, kdy to z pohledu jádra vypádá, že přerušení je zakázáno, ale pravda je pro RT část jiná. Bežná aplikace na jádře s 100 Hz schedulerem samozřejmě není schopna přidělovat čas jinak, než po 10 ms kvantech a nemáte nijak zajištěno, zda se za požadovanou dobu opět k CPU dostanete, částečně to řeší "měkký" real time dostupný aplikacím běžícím pod uživatelem root, ale ani tam nemáte zaručeno, že vaše úloha bude spuštěna každých N ms.

Z pohledu programování je RT-Linux minisystém běžící jako vícevláknová aplikace na úrovni jádra, kdy celé jádro včetně celého user space beží jako jeden thread s nejmenší prioritou, přičemž je v podstatě možné z RT části volat omezené množství funkcí normálního jádra. Takže to máte jako normální vícevláknovou aplikaci, která má jen navíc některé věci ohlědně časování, řízení přerušení apd Ovládáte-li knihovnu pthread, tak umíte i RT-Linux. ) Pro komunikaci s běžnými proecesy v user space se používá buď sdílená pamět nebo speciální RT FIFO. Na stranu komunikace s HW si to každá aplikace obvykle řeší sama, existuje ale dost knihoven pro RT komunikaci po síti, měřicími kartami atd.

RT-Linux upřednosťnuji proto, protože odpovídá v podstatě příslušné POSIX normě, takže pokud nepoužijete některé vylomeniny, tak je to pak přenosné i na další systémy. RTAI (a i RT-Linux 1.X) používal vlstní API, což je trošku nepříjemné, ale možná se to už změnilo. RTAI také špatně nese situaci, kdy v RT části běží více vláken bez nějaké systematické vlastní synchronizace.

Co se licence na RT-Linux týče, tak jsou v podstatě 3: a) plně komerční, kdy podle toho, zda je se zdrojáky, či bez, podpory multiprocesingu atd je cena od 1000 USD výše, b) open RT licence, ta umožňuje používat RT linux i pro uzavřené komerční projekty bez licnčních poplatků za podmínky, že můžete použít jen oficiální verze distribuované FMSlabs, c) zmíňená GPL licence. Doufám, že jsem je pochopil dobře. Ale stejně v tom je dost chaos a budu rád, pokud by to někdo objasnil. Už jen otázka binárních modulů a privátního kódu v nich má několik názorových proudů. )

[Leoš Literák]

diky za upresneni, ty nanosekundy jsem schvalne strelil jako nadsazku

[Petr Krčmář]

Ja zase obema dekuju za vysvetleni. Matne jsem tusil o co se jedna a ted mam jasno. Jeste jednou diky.

[Martin Koníček]

nejak mi nejde do hlavy jakej je ale rozdil mezi normalnim Linuxem??? Ten kdyz obsluhuje seriak tak musi byt taky dosti presny... Ano ma buffer, ale nesmi podtext, navic vetsina bufferu je vlastne softwarovych...

[Leoš Literák]

obycejny kernel ti nedava zadne zaruky ohledne schedulovani kernelu, RT ano.

[bart]

Je otazka co je dost presny ? Trocha matematiky nebo spis kupeckych poctu okolo serioveho portu na PC: Nejhorsi situace z hlediska odezvy na preruseni je tato: rychlost 115200b/s, nastaveni tresholdu ve 3/4 16B FIFO => 4B (40bitu) rezerva ~ 350us od preruseni do precteni 1. bytu z UARTU,coz je o rad ne-li o dva vice nez zarucuje RT[AI|Linux] a to je ten _nejhorsi_ mozny pripad u serioveho portu na PC. No a tak to je zhruba asi se vsim HW co funguje pod normalnim Linuxem. Navic jsou zde jeste vetsinou vyssi vrstvy (TCP/IP, PPP ...), ktere pripadne chyby zjisti a opravy takze si vlastne normalni uzivatel ani niceho nevsimne Jak jiz bylo zmineno vyse jina situace je u embedded zarizeni vyzadujicich hard real time.

[Michal Dobeš]

Myslím, že sériový port není dost vhodný příklad. Ale to, že se váš obslužný kód vyvolá až za 350 us než přišlo přerušení, tak to už může být hodně pozdě, to také turbína může být už mimo budovu strojovny. )
Popravdě řečeno, tak většina jednoduchých RT aplikací vypadá tak, že běží pár periodických tásků, co se spustí každých pár desítek us až ms dle přání autora, přečte to pár bajtů odněkud, něco s nimi udělá a zase to pošle někam ven. A žádné přerušení se nepoužívá.
Mějme trapně nesmyslný příklad:
void *periodic_update_digi_triggers(void *p)
{
   struct sched_param sp;
   hrtime_t abstime;
   unsigned short port=0x300;
   unsigned short data;
   hrtime_t perioda=100000;

   pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL);
   sp.sched_priority=sched_get_priority_min(SCHED_FIFO)+3;
   pthread_setschedparam(pthread_self(), SCHED_FIFO, &sp);

   abstime=clock_gethrtime(CLOCK_REALTIME);
   while (1) {
     data=inw(port);
     data=~data;
     outw(data, port+1);
     abstime+=perioda;
     clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, hrt2ts(abstime), NULL);
   }

   return NULL;
}
Tohle je doufám funkční nesmysl, co každých 100 us přečte něco z jednoho portu a negovaně to pošle na port vedle, řekněme, že takto nesmyslně revezruji otáčení něčeho, co kdyby se otočilo o něco více později, tak se to rozbije. V RT jádře vím, že těch 100 us mám s chybou do těch cca 10 us a navíc tu chybu dokáži i přesně určit a zachovat se dle toho. Pokud to uděláte bez RT (stačí změnit ten nanosleep a vyhodit věci kolem hrtime), tak to půjde v podstatě táké, ale jednak 100 us nezačasujete a už vůbec nemáte nikde zajištěno, že se to čekání neukončí klidně až za hodinu. RT jádro se pokusí zuby nechty zařídit, aby se ten sleep vrátil ve správnou dobu.

[Pavel]

predem pripoustim, ze se v problemu neorientuju, nicmene podle tohoto prekladu bylo RTLinuxu vytykano, ze pripadne prispevky nezavislych vyvojaru se defakto stavaji majetkem dane spolecnosti, ktera je sice najedne strane uvolnuje pod GPL, ale na druhe je siri jako uzavreny sw. To je jednani na ktere ma vyvojar samozrejme pravo, nicmene ve chvili kdy kod obsahuje i praci ostatnich, stava se takove chovani kontroverzni.

Nektere reakce od Linuse tak jak se je docitam (tedy zprostredkovane) mi pripadaji jako od cloveka, ktery si na kritice vybere jen kousek ktery mu sedne a zbytek ignoruje :o(

[Leoš Literák]

v originalnim textu to take nebylo zcela jasne, zda FSMLabs odmita veskere prispevky z vnejsku anebo je krade. spise ale plati moznost 1, jinak by vyvojari reagovali dost nahlas.

[Michal Dobeš]

Ono je to tak, že v podstatě existují dvě větve RT-Linuxu vedle sebe: a) oficiální od FSMLabs, kde je opravdu naprostá většina kódu jen od producentů. Toto je nabízeno pod všemi třemi licencemi. b) je větev doplněná o další věci a porty na další procesory dostupná jen pod GPL.

V podstatě FSMLabs čas od času vydá vlastní verzi s kódem jen od nich a tu bafne banda lidí a dál si ji rozvíjí. Tyto rozšíření jsou dostupné na FTP FSMLabu, ale oni je do dalších verzí nepoužijí. Takže se majetkem firmy se další kód nestane (pokud se samozřejmě nějak s autorem nedohodnou), spíše jsou další autoři točeni z toho, že jejich úpravy jsou ignorovány do dalšího hlavního vývoje. Trochu začínám mít pocit, že se tento spor asi brzo vyřeší, že se FSM na linux úplně vybodne a přejde se k BSD klonům.

[bart]

Tak by me zajimalo co z toho plyne pro mne jako prosteho [obcana|vyvojare|firmu pouzivajici RTAI ve svych produktech] ? Musi se platit nejake licencni poplatky ? Je legalni pouzivat RTAI jako GPL ?

[Michal Dobeš]

Pokud chcete používat RTAI, tak musíte používat GPL. Pokud GPL nechcete, tak musíte použít komerční licenci RT-linux Pro nebo jejich Open RT licenci. Samozřejmě případně použít produkt jiné strany (QNX, VxWorks, .....).