Jaderné noviny 170

17. 6. 2002 | Leoš Literák | Jaderné noviny | 2247×

Dlouhá diskuse nad patenty v RTLinuxu. Do konference přišlo 1832 emailů od 446 lidí, nejvíce psali Alan Cox, Martin Dalecki, Andrew Morton a Linus Torvalds.

Diskuse nad patenty v RTLinuxu, 212 emailů

Během diskuse někdo zmínil, že algoritmy použité v RTLinuxu jsou patentovány. Karim Yaghmour napsal:

Už dva roky válčím proti tomuto patentu. Během této doby jsem se setkal s mnoha lidmi a bavil se s nimi o něm. Dnes jsem si jist, že rtlinux patent brání Linuxu proniknout do této oblasti. Linux nikdy nebude životaschopný embedded operační systém, dokud nás někdo nezbaví tohoto patentu. Mnoho direm se rozhodlo použít raději WinCE kvůli němu. Mnoho vývojářů naší komunity kolem real time Linuxu je znepokojeno faktem, že kerneloví vývojáři považují real-time za vedlejší trh.

Poslední průzkumy VDC http://www.linuxdevices.com/articles/AT6328992055.html ukazují, že hlavním důvodem, proč se Linux neprosazuje do embedded oblasti, je ve skutečnosti real-time. Proto se nedivme, že zavedení dodavatelé (WindRiver, QNX, ..) se necítí Linuxem ohroženi. Ví, že kdykoliv bude Linux vyhodnocován, bude nakonec zavrhnut kvůli tomuto patentu. A protože embedded zařízení mají předhonit desktopy a servery v počtech nasazení, myslím, že se jedná o více než okrajový trh. Dokud nebude patent na RTLinux zrušen, Linux nepronikne výrazněji do embedded zařízení. Bohužel.

Linus Torvalds odpověděl: Tento patent je ale licencován pro GPL kernely, tedy i Linux. Viz http://www.fsmlabs.com/about/patent/openpatentlicense.htm. Slyšel jsem hodně diskusí na téma, že patenty s licencí pro GPL software podvracejí patentový systém stejně, jako copyleft podvrací copyright. Dokonce i FSF podporuje tento patent. V podstatě, pokud půjdeš příliš daleko a odejdeš od GPL, ztratíš také patentová práva. Ale pokud zůstaneš na správné straně, licence je tvoje a zadramo. Přesně jak GPL požaduje.

Karim odpověděl: Rozumím tomu, co říkáš, ale velkou část historie patentu neprobíhala skutečná komunikace s kernelovými vývojáři. Pokusím se vysvětlit své stanovisko. Když Jerry Epplin získal patent na začátku roku 2000, poslal do konference dotaz, ve kterém jasně říká, že jeho hlavním účelem je obrana. A tak real-time komunita čekala, co bude následovat. Pak přišla první verze licence, která porušovala GPL tím, že požadovala registraci všech uživatelů ve FSMLabs. Jedna z podmínek říkala, že software je zdarma pro programy šířené pod GPL kdekoliv a všechny uživatele RTLinuxu (nezávisle na licenci). Victor tím říkal, že pokud nechcete platit licenci, buď uvolněte software jako GPL nebo používejte jeho Open RTLinux Execution Environment.

Toto trvalo, dokud FSF veřejně neprohlásila, že patent porušuje GPL. Eben Moglen posléze zaslal opravenou licenci a její důsledky: http://www.aero.polimi.it/~rtai/documentation/articles/moglen.html. Pak se situace zklidnila a vývojářský tým RTAI se snažil plnit Ebenovy doporučení. Vše by bylo v pořádku, kdyby Victor nevnesl další nejistotu: http://linuxdevices.com/articles/AT6164867514.html. Eben říkal, že real-time aplikace nejsou předmětem patentu, jenže najednou Victor Yodaiken napsal, že se patent vztahuje na veškerý software. Tímto Victor zpochybnil závěry respektovaného právníka Ebena Moglena.

V současnosti RTAI jednoznačně vede na RTLinuxem. Abyste rozuměli, co se děje. Spousta vývojářů měla zájem přispívat i do RTLinuxu, ale Victor je všechny odradil. Je proto logický důvod: FSMLabs používá duální licenci RTLinuxu a poskytuje svým klientům uzavřenou licenci. To znamená, že všechen kód musí vlastnit FSMLabs. Pokud se podíváte do jejich zdrojových kódů, všude je copyright pouze FSMLabs. Na tom není nic špatného, ale pak jsou všechny nezávislé příspěvky zahazovány. V tuto chvíli nejnovější vývoj RTLinuxu není dostupný jako GPL a musí být zakoupen. To není problém, neboť RTAI převyšuje RTLinux ve schopnostech, portech i podpoře. Problémem je, že RTLinux patent je používán jako FUD proti RTAI. A když se někdo podívá na RTAI, narazí na FUD a nakonec skončí u jiného OS.

Linus však nesouhlasil: Musí být část poskytující RealTime GPL? Ano. Stejně jako kernelové moduly, pokud jsou odvozenou prací, což je v tomto případě zřejmé. Tak rozděl svůj problém na RT ovladač a aplikace a přestaň s tímto hloupým FUD. Znechucuje mě používání patentu jako falešné stopy. Skutečným problémem je, že některým lidem se nelíbí, že je kernel uvolněn jako GPL. Přestaň dělat vyjímky. Osobně jsem šťasten, že lidé mají další důvod uvolňovat své moduly jako GPL. Vidím přiliš mnoho problémů s věcmi jako je ovladač od firmy nVidia a když vidím, že někoho děsí GPL, tak mě to nezajímá. Někteří lidé (ty a Karim) si myslíte, že požadavek GPL ubližuje Linuxu v oblasti embedded. Totéž ale tvrdili lidé z BSD o Linuxu na serverech a desktopech. Osobně sázím na Open Source. I v embedded. A pokud s tím někdo nesouhlasí, tak mě to nezajímá.

Tento článek vychází ze seriálu Kernel Traffic (http://kt.zork.net) a je zveřejněn pod licenci GPL verze 2.

       

Komentáře

[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, .....).