DESIGN OF RTOS SYSTEMS UVOD U RTAI LINUX

DESIGN OF RTOS SYSTEMS UVOD U RTAI - LINUX RTAI Plug-in za Linux , treba da pomogne Linux OS da ispuni neka ogranićenja realnog vremena ( napr. deadline od nekoliko milisekundi, ni jedan dogadjaj ne smije biti izgubljen, itd. ). On je baziran na RTHAL : tj REAL TIME HARDWARE ABSTRACTION LAYER – hadverskom abstrakcionom sloju za realno vrijeme. Ovaj koncept je takodjer poznat i koristi se i kod Win. NT OS. HAL eksportuje neke Linux podatke i funkcije koje su u uskoj vezi sa hardverom. RTAI ih modificira da bi dobio kontrolu nad hardverskom platformom. To dozvoljava RTAI taskovima realnog vremena da se izvršavaju istovremeno sa Linux procesima. HAL definira jasan interfejs izmedju RTAI i Linuxa. 1

DESIGN OF RTOS SYSTEMS Sumarni pregled zahtjeva OS * Općenito govoreći, mi bi željeli da se softverske komponente oslanjaju na platformu koja nudi i podršku za realno vrijeme i '' standardne'' API opšte namjene. * Platforma treba izvršni program realnog vremena ( real time executive) koji ima mali otisak ( footprint), ispunjava zahtjeve graničnih vremena ( deadlines), kao i sveobuhvatan OS za aplikacije ( NT, UNIX , Linux. . ). * Na softverskom tržištu postoji nekoliko programa koji ovo nude kao: za NT OS : proširenja za realno vrijeme kao što je Radisysov Intime ili Ventur. Com-ov RTX. za UNIX: mikro kernel bazirane tehnologije izvorno 2 podržavaju realno vrijeme i bogate UNIX nalik API-jeve.

DESIGN OF RTOS SYSTEMS * Linux OS izvozi isti nivo aplikacionih servisa, ali trpi zbog nedostatka podrške za realno vrijeme. Na sreću, neke opcije se mogu predvidjeti: Izvorna realtime podrška u Linuxu: ne izgleda da je glavna tema u samom Linuxu. Linux modifikacije za ograničenja realnog vremena ( KURT – Kansas University Realtime ): nema neke posebne pozadine. Linux i djeljenje resursa eksperimentalni projekat. u realnom vremenu ( L 4 Linux): Linux kao task izvršnog dijela za realno vrijeme: RTLinux, RTAI, e. Cos, Nucleus, . . 3

DESIGN OF RTOS SYSTEMS Linux , kao i drugi OS, nudi aplikacijama, najmanje slijedeće servise: * Hardverski menadjment sloj koji je odgovoran za poling dogadjaja ili interapte od periferije ka procesoru. * Klase rasporedjivača koje su odgovorne za aktiviranje procesa, prioritete, vremenske odsječke ( time slice), i mekano realno vrijeme. * Komunikaciona sredstva izmedju aplikacija ( barem FIFO ). Pojednostavljeni prikaz Linuxa 4

DESIGN OF RTOS SYSTEMS Novije verzije Linuxa , nude neke mogućnosti za mekani real tajm ( soft real time ), ali nema garancije za tvrde realtime taskove i njihove deadlajne niti spriječavanje gubitka dogadjaja. Linux je koncipiran i razvijan kao operativni sistem opšte namjene i nalik na UNIX. Ciljevi kod razvoja jednog multikorisničkog OS su u suprotnosti sa ciljevima za realtime rad. Postoji nekoliko razloga zašto standardni Linux nije pogodan za realtime korištenje: 5

DESIGN OF RTOS SYSTEMS * Gruba rezolucija sinhronizacije. Ovo je ustvari način da se kaže da sistemski pozivi kernela nisu preimtabilni. Jedanput kada proces udje u kernel, ne može se priemptirati sve dok nije spreman da izadje iz kernela. Ako se desi neki dogadjaj dok se kernel izvršava, proces koji ćeka na taj dogadjaj se neće moći rasporediti sve dok proces koji se trenutno izvršava ne izadje iz kernela. Neki pozivi kernela kao što je naprimjer fork(), mogu zadržati priempciju i nekoliko desetaka milisekundi. * Pajdjiranje( paging) – Proces svopiranja strana u i iz virtuelne memorije je, zbog praktičnih razloga , neograničen. 6

DESIGN OF RTOS SYSTEMS Zbog toga nema načina da saznamo koliko će dugo trajati da OS skine stranu sa disk drajva i ubaci je u glavnu memoriju, jer jednostavno mi ne možemo postaviti gornju granicu na vrijeme koliko proces može biti zakašnjen zbog toga što postoji greška u stranici. * Korektnost ( fearness) u rasporedjivanju. U odnosu na naslijedje iz UNIXa kao OS višekorisničkog sistema sa djeljenjem vremena, konvencionalni rasporedjivač Linuxa takodjer čini najbolje što može da bi bio korektan prema svim procesima. Zbog toga je moguće da rasporedjivač dodjeli procesor procesu niskog nivoa prioriteta koji je ćekao dugo vremena, iako postoji proces višeg nivoa prioriteta koji je spreman da se izvršava. 7

DESIGN OF RTOS SYSTEMS * Zahtjev za promjenom redoslijeda- Linux mjenja redoslijed zahtjeva za I/O uredjajima kod postojanja više procesa koji ih zahtjevaju, da bi imao efikasnije korištenje hardvera. Napr. hard disk blokiranje čitanja od strane procesa nižeg prioriteta može dobiti prednost od zahtjeva za čitanje sa diska od procesa višeg prioriteta da bi se minimiziralo kretanje glave diska ili povećale šanse za oporavak od greške. * Bačing - Linux će objediniti ( batch ) operacije da bi postigao efikasnije korištenje resursa. Naprimjer, umjesto da oslobadja jednu po jednu stranicu kada raspoloživa memorija postane nedovoljna, Linux će prolaziti kroz listu strana, čisteći ih što je god više moguće, i zbog toga zakašnjavajući izvršavanje svih procesa. 8

DESIGN OF RTOS SYSTEMS Smanjenje kašnjenja kod Linuxa Postoji nekoliko stvari koje mogu smanjiti kašnjenje kod standardnog Linuxa. Tako je moguće promjeniti strategiju rasporedjivanja kod kernela, i prioritete procesa, kao i zaključati memorijsku sliku procesa u RAM , tako da neće biti svopovana iz glavne memorije. Default strategija rasporedjivanja se zove SCHED_OTHER koristi algoritam korektnosti ( fairness algorithm) i daje svim procesima koji koriste ovu strategiju prioritet 0, tj. najniži prioritet. Ovo je u redu za ‘’normalne’’ procese. Alternativne srategije rasporedjivanja su SCHED_FIFO ( first in first out rasporedjivanje ) i SCHED_RR ( rasporedjivanje round robin ). SCHED_FIFO se može koristiti samo sa statičkim prioritetima većim od nule, što znači da kada SCHED_FIFO procesi postanu spremni, on će odmah priemptirati tekuči proces koji se izvršava 9 ukoliko je on normalni SCHED_OTHER proces.

DESIGN OF RTOS SYSTEMS Ove strategije su namjenjene za vremenski kritične procese koji zahtjevaju manja zakašnjenja. Procesi koji koriste ove alternativne strategije rasporedjivanja moraju imati prioritet veći od 0. Dakle proces koji je rasporedjivan sa SCHED_FIFO ili SCHED_RR će priemptirati bilo koji drugi normalni proces kada postane spreman. SCHED_FIFO je jednostavni algoritam rasporedjivanja bez vremenskog rezanja ( time slicing). Za procese koji su rasporedjivani sa SCHED_FIFO strategijom, primjenjuju se slijedeća pravila: SCHED_FIFO proces koji je bio priemptiran od strane drugog procesa većeg prioriteta će ostati na čelu reda ( liste) za svoj prioritet i ponovo će nastaviti svoje izvršenje čim procesi višeg prioriteta budu ponovno blokirani. Kada SCHED_FIFO proces postane spreman, bit će unesen na kraj reda za svoj prioritet. 10

DESIGN OF RTOS SYSTEMS Poziv ka sched_setscheduler ili sched_setparam će postaviti SCHED_FIFO ili SCHED_RR proces identificiran sa pid na početak liste ako je spreman. Kao posljedica toga, on može priemptirati proces koji se izvršava ako je on istog prioriteta. ( POSIX* 1003. 1 specificira da proces treba ići na kraj reda). Proces koji poziva sched_yield bit će stavljen na kraj reda. Nikakvi drugi dogadjaji neće pomjeriti proces koji je rasporedjen sa strategijom SCHED_FIFO u listu ćekanja sa procesima koji su spremni sa istim statičkim prioritetom. SCHED_FIFO proces se izvršava sve dok ne bude blokiran od strane I/O zahtjeva, ili je priemptiran od strane procesa većeg prioriteta, ili ako pozove sched_yield. 11

DESIGN OF RTOS SYSTEMS SCHED_RR je jednostavno unapredjenje SCHED_FIFO algoritma rasporedjivanja. Sve ono što je rečeno za SCHED_FIFO procese vrijedi i za SCHED_RR izuzev što je dozvoljeno da traje neki maksimalni iznos vremena. Ako se SCHED_RR proces izvršavao vremenski period jednak ili duži nego što je vremenski kvantum, on će biti stavljen na kraj reda svog prioriteta SCHED_RR proces koji je bio priemptiran od strane procesa većeg prioriteta, i nakon toga ponovno nastavi svoje izvršenje, će kompletirati svoj nepotrošeni dio round robin vremenskog intervala ______________________ * POSIX – je zajedničko ime za familiju standarda specificiranih od strane IEEE koji definiraju aplikacioni progamski interfejs ( API ) za softvere kompatibilne sa varijantama UNIX OS. 12

DESIGN OF RTOS SYSTEMS Dužina vremenskog intervala se može dobiti iz poziva sched_rr_get_interval. SCHED_OTHER je default Linux rasporedjivanje sa djeljenjem vremena ( time sharing). Ovo rasporedjivanje se može koristiti samo kod statičkog prioroteta od 0. On je namjenjen za sve procese koji ne zahtjevaju specijalan mehanizam statičkog prioriteta realnog vremena. Proces koji će se izvršavati je izabran iz reda statičkog prioriteta 0, na bazi dinamičkog prioriteta koji se odredjuje samo unutar ovog reda. Dinamički prioritet je baziran na nivou koji se postavlja pomoću setpriority sistemskog poziva, i povećava se svaki put kod isteka vremenskog intervala ako je proces bio spreman za izvršenje ali mu rasporedjivač nije doznačio procesor. Ovo obezbjedjuje fer progres medju svim SCHED_OTHER procesima. 13

DESIGN OF RTOS SYSTEMS Linux za uronjene i realtime aplikacije Konceptualno, kernel održava FIFO red procesa koji se mogu izvršavati za svaku moguću vrijednost prioriteta u opsegu 0 -99. Da bi se odredio slijedeći proces koji će se izvršavati, rasporedjivač nalazi red koji nije prazan sa najvećim prioritetom i uzima iz njega njegov prvi proces. Ako je SCHED_FIFO proces priemptiran, od strane procesa većeg prioriteta, on ostaje na čelu svog reda prioriteta. Kada SCHED_FIFO proces postane ponovo spreman pošto je prethodno bio blokiran, on ide na kraj reda svog prioriteta. SCHED_FIFO proces se izvršava dok se ili ne blokira ili ne završi. Kako smo rekli SHED_RR je mala varijacija u odnosu na SCHED_FIFO koja dodaje još i djeljenje vremena ( time slicing). Ako SCHED_RR proces prevazidje svoj interval vremena on se postavlja na kraj svog reda prioriteta. 14

DESIGN OF RTOS SYSTEMS Dva pristupa u daljem poboljšanju realtime performansi Dakle vidjeli smo da Linux nije realtime OS. Postoje najmanje dva različita pristupa da se Linux-u da determinističko ponašanje. Poboljšanje priempcije Jedan pristup je da se modificira sam Linux kernel, da bude brže odzivan. Ovo primarno uključuje uvodjenje dodatnih tačaka priempcije u sam kernel da bi se reduciralo zakašnjenje. Jedan lagani način da se ovo učini je da se koriste ‘’spinlock’’ makroi, koji već postoje u kernelu da bi podržali simetrično multiprocesiranje ( SMP ). U SMP okruženju, spinlock spriječava da više procesora simultano izvršava kritičnu sekciju koda. Kod jednoprocesorskog okruženja ( UP ) , spinlock nisu operativni. 15

DESIGN OF RTOS SYSTEMS Strategija poboljšanja priempcije pretvara spinlocks u ekvivalentne Enter. Critical() i Exit. Critical() pozive. Dakle, dok kod standardnog kernela priempcija je spriječena sve dok nije specifično omogućena, priemptabilni kernel dozvoljava primepciju izuzev kada je specifično blokirana od strane koda kritične sekcije. Obrada interapta je takodjer modificirana da dozvoli za prerasporedjivanje ( rescheduling) nakon povratka iz interapta, ako je u medjuvremenu proces većeg prioriteta postao spreman. Ovaj pristup se često kombinuje sa novim rasporedjivačem koji obezbjedjuje fiksni dodatak ( overhead) za realtime taskove. Monte Vista i Timesys su glavni zagovornici ovog pristupa u poboljšanju priempcije. Primjetimo, da kada govorimo o priempciji kernela, mi mislimo na zakašnjenje procesa, ne zakašnjenje interapta. 16

DESIGN OF RTOS SYSTEMS Sa standardnim jednoprocesorskim kernelom Linuxa, zakašnjenje interapta je reda oko 60 µs, zavisno naravno od brzine procesora. Kao što je već bilo primjećeno ranije, maksimalno zakašnjenje procesa za standardni kernel je reda desetaka milisekundi. Strategija poboljšanja priempcije smanjuje ovo na jednu do dvije milisekunde. Prednost pristupa sa smanjenjem priempcije je u tome što realtime aplikacije se izvršavaju u korisničkom prostoru kao i sve druge Linux aplikacije koriste standardne Linux/POSIX APIje. Realtime procesi su podvrgnuti istim pravilima zaštite memorije kao i obićni procesi. Medjutim, postoji i nekoliko nedostataka: * Modifikovanje kernela do ovoga nivoa je dosta ozbiljan zahvat. Kako možemo biti sigurni da naše modifikacije nisu 17 uništile nešto drugo u OS.

DESIGN OF RTOS SYSTEMS Nadalje, svaki put kada se kernel promjeni, mi moramo da implementiramo naše modifikacije. * Ovo još uvjek nije realtime. Zakašnjenje je smanjeno ali postoji isuviše mnogo staza izvršenja u kernelu da dozvoli konzistentnu i sveobuhvatnu analizu determinizma. Za verziju 2. 4 kernela, poboljšanja primepcije su raspoloživa kao kernelska zakrpa ( patch). Počevši od verzije 2. 5. 4 , zakrpa za priempciju je uključena u glavno razvojno drvo kernela i sada je ona konfiguraciona opcija. Ovo efektivno anulira prvi gornji cilj. Abstrakcije interapta U mnogim aplikacijama, samo mali dio sistema zahtjeva tvrdi realtime determinizam. Napr. kontrola PID konture velike brzine, ili pokretanje robotske ruke su primjeri zahtjeva tvrdog realnog 18 vremena.

DESIGN OF RTOS SYSTEMS Ali logiranje temperature koju vrši PID kontura, ili grafički displej trenutne pozicije robotske ruke nisu u opštem slučaju zahtjevi u tvrdom realnom vremenu. Alternativa , i za neke i efikasniji pristup za realtime performansu u Linuxu se oslanja na ovu razliku izmedju onoga šta jeste realno vrijeme a šta nije. Tahnika se sastoji u tome da se izvršava Linux kao task najnižeg nivoa prioriteta ( kao vrsta idle taska), pod kontrolom malog realtime kernela. Realtime funkcije su upravljane od strane taskova višeg prioriteta koji se izvršavaju pod ovim kernelom. One stvari koje nisu realtime, kao napr. grafika, menadjment fajlova i mrežni rad, koje Linux već dobro radi, bit će upravljane od strane Linuxa. Ovaj pristup se naziva ‘’apstrakcija interapta’’, pošto realtime kernel preuzima upravljanje interaptima od Linuxa. Kernel Linuxa ‘’misli’’ da on onemogućava interapte, dok u stvarnosti on to ne 19 radi.

DESIGN OF RTOS SYSTEMS Pošto je mnogo manji i jednostavniji, realtime OS je podložan analizi izvršenja u realnom vremenu, koja obezbjedjuje pouzdane gornje granice na zakašnjenja. Sa druge strane, RTOS uvodi svoje vlastite API-je i ‘’čistunci’’ insistiraju da ovo više nije ‘’istinski’’ Linux. I dok ovaj pristup takodjer uključuje modifikaciju kernela, obim ovih modifikacija je značajno manji nego kod pristupa sa poboljšanjem priempcije. Realtime taskovi se izvršavaju u prostoru kernela. Ovo je dobra vijest, ali i loša. Dobra je zbog toga što su vremena odziva u prostoru kernela vrlo kratka. Tako napr. odziv na interapt i vremena prekljućenja su ispod desetak mikrosekundi. Loša vijest je naravno ta, da nema zaštite u kernelskom prostoru i realtime task može oboriti cijeli sistem. Realtime taskovi su ustvari proširenja kernela. 20

DESIGN OF RTOS SYSTEMS Postoje dvije glavne implementacije pristupa apstrakcije intrapta: * RTLinux – Ovo je originalna implementacija interapt apstrakcije. Razvijena je na New Mexico Institute of Mining and Technology, pod rukovodstvom Victora Yodaikena. Mada je open source verzija RTLinuxa još uvjek raspoloživa, mnogo razvojnog rada se odigrava na proprietary verziji koja je nazvana RTLinux/Pro koju nudi firma FSM Labs Inc. * RTAI – Ovo je jedno poboljšanje RT Linuxa koje je razvijeno na na DIAPM (Dipartimento di Ingegneria Aerospaziale - Politecnico di Milano ), pod rukovodstvom Prof. Paolo Mantegazza. Riječ je o vrlo aktivnom Open source projektu sa mnogim ućesnicima. 21

DESIGN OF RTOS SYSTEMS Resursi i raspoloživost Realtime Linux implementacija RTLinux je podržavan i raspoloživ od strane FSM Labs na URL adresi : www. fsmlabs. com/community RTAI je raspoloživ na URL adresi : www. rtai. org Relatime Linux fondacija je neprofitna organizacija čiji cilj je da podržava realtime Linux zajednicu. Njihova URL adresa je: www. realtimelinuxfoundation. org. Monta Vista Software nudi priemptabilni kernel kao Monta Vista Linux u obadvije verzije i kao ‘’Professional Edition’’ i kao ‘’Carrier grade Edition’’ na adresi : www. mvista. com. Time. Sys priemptabilni kernel se može naći na : www. timesys. com Linux. Works nudi verziju RTLinuxa, licenciranu od FSM Labs, koja 22 se naziva Blue. Cat RT na adresi : www. bluecat. com.

DESIGN OF RTOS SYSTEMS RTAI okruženje Realtime aplikacioni interfejs ( real-time application interface. RTAI), koristi pristup apstrakcije interapta , da doda determinističke realtime karakteristike na Linux kernel. RTAI ima prilično velik broj API-ja. Arhitektura RTAI real time entiteti su jednostavni monokončani taskovi dok su Linux aplikacije mono ili multi končani procesi sa svim 23 karakteristikama.

DESIGN OF RTOS SYSTEMS * RTAI taskovi mogu biti u kernel modu ( kreirani unutar modula) , ili u korisničkom modu ( user-mode), kreirani od strane Linuxa a zatim ''ukradeni'' od strane RTAI. * RTAI je u suštini dispečer interapta. Interapti sa Intelovog procesora ( 0, . . 31), su još uvjek upravljani od strane Linuxa. RTAI uglavnom ''lovi'' ( traps), periferne ISA interapte i , ako je potrebno, re rutira ih do Linuxa, ( napr. interapte sa diska). On je takodjer sposoban da upravlja i drugim vrstama interapta. * On podržava, kao i Linux, i SMP ( Symmetric Multi Processor) i UP ( Uni- Processor ) arhitekture. Sa tačke gledišta realnog vremena, on je vrlo slićan RTLinux-u. * Dok je RTLinux intrusivna modifikacija kernela, RTAI koristi koncept HAL da dobije informaciju od Linuxa i da uhvati ( trap ) neke osnovne funkcije 24

DESIGN OF RTOS SYSTEMS * Ovaj HAL obezbjedjuje nekoliko zavisnosti od Linux Kernela. Ovo vodi ka: - jednostavnoj adaptaciji na Linux kernel - lagano prenošenje (porting) RTAI od jedne do druge verzije Linuxa. - lagano korištenje drugih proširenja OS umjesto RTAI. * RTAI smatra Linux kao pozadinski task koji se izvršava kada nema aktivnosti realnog vremena. Definisanje termina kod RTAI * vlastiti ( ''proprietary'') se koristi da se napravi razlika izmedju standardnih i nestandardnih entiteta. 25

DESIGN OF RTOS SYSTEMS ''Standardni entitet'' , znači ili: - korištenje standardnih mehanizama: protokoli, API, okviri ( framework kao Corba , itd) -da djeluje kao standardni dio od : Linuxa, Windowsa, itd. * Na ovako postavljenoj razini ''proprietary'' nije uopšte vezano sa pitanjima licenci za proizvod. • U nastavku opisa mi ćemo koristiti termine ''taskovi'‘ kao RTAI i ''procesi'' kao Linux korisnički entiteti. Softverska arhitektura RTAI je sačinjena od: * 1 interfejsa ka Linux hadverskom menadjmentu ( HAL), što je u osnovi struktura podataka. * 3 bazične komponente ( dispečer ili dostavljač , rasporedjivač ili rasporedjivač i FIFO-i ). * 1 interfejs ( koji je set funkcija ), koji se koristi u korisničkim taskovima, da inicijalizira start 26 komponenata.

DESIGN OF RTOS SYSTEMS Sa tačke gledišta Linuxa, ovi entiteti su popunjeni sa modulima Modul je kernelska komponenta, koja je dinamički punjiva ( loadabilna), koja se izvršava zaključana ( locked) u prostoru kernela. Dobija iste kernelske privilegije i prava pristupa. Šta više, modul koji je kvalifikovan u vremenu kompilacije, mora deklarisati vrlo dobro poznate funkcije : init_module i cleanup_module. Modul je installed/uninstalled putem insmod/rmmod komandi. Interfejs izmedju RTAI i Linuxa je uglavnom: *struktura koja sadrži nekoliko važnih funkcija i podataka ( RTHAL) 27

DESIGN OF RTOS SYSTEMS * nekoliko modifikacija kernelskih fajlova ( da bi mogla da koristi RTHAL). HAL čini mogućim da: * RTAI dobije kontrolu nad hadverskom platformom t. j IDT – Interrupt description table) tretirajući Linux kao jednostavnog korisnika. * Linux pristupa RTAI modificiranim funkcijama. ( HAL kontejner uključuje { * Pokazivač na IDT ( Interrupt description table) * Funkcije da omogući/onemogući interapte procesora ( cli, sti & flags , tj. clear interrupt and set interrupt komande) * Funkcije da se maskiraju i demaskiraju interapti sa interapt kontrolera 8259. 28

DESIGN OF RTOS SYSTEMS * Funkcije za upravljanje SMP (symmetrical multiprocessing) hadverom mašine ( APIC – advanced programmable interrupt controller). * Deskriptori podataka za interapte ( status, hendler, nivo ugnježdenja. . ) } Modifikacije Linux kernela Kernel je modificiran da izvrši HAL funkcije umjesto izvornih ( native). Primjer za ovo je: if(!(status&IRQ_DISABLED)) // enable_8259 A_irq(irq); orginalni kod rthal. unmask_8259 A_irq(irq); // novi kod koristeči RTHAL funkciju ). Linux inicijalizira HAL sa funkcijama pokazivanja na izvorne 29 funkcije.

DESIGN OF RTOS SYSTEMS Otprilike oko 70 linija koda je sve što je promjenjeno ili dodato na kernel Linuxa. Ovaj interfejs se takodjer sastoji od nekih drugih sredstava: * uključuje fajlove ( napr. : system. h, interrupt. h, module. h, . . ) * specifični #define koji se odnose na SMP i deskriptor interapta ( irq_desc, . . . ) * specifične kernel funkcije ( kfree, kmalloc, request_irq, queue_task, wake_up_interruptible, . . . ) Specifične funkcije kernela se koriste samo kod inicijalizacije modula, ne i u normalnom modu. One nisu re-entrant ( moguća je interna korupcija podataka kod istovremenih pristupa), i ne garantiraju realno vrijeme ( kašnjenje, inverzija prioriteta). Iz ovog razloga, korisnički taskovi ne treba da koriste ove Linux funkcije. 30

DESIGN OF RTOS SYSTEMS Ove promjene i provjere su obavezne , kod upgrejda verzije kernela Linuxa. Footprint kod verzije RTAI v 0. 3 Memorijski footprint ( tekst, podaci, bss) kod RTAI v 0. 3 komponenata, dobijen sa komandom ''objdump –h'' je: Tri komponente su C programi. Distribucija ''linija koda''( LC )je 31

DESIGN OF RTOS SYSTEMS RTHAL sam ima manje od 200 linija koda. Dispečer interapta Cilj: dispečer je hendler koji se poziva od strane IDT , kada ISA, SMP ili neki drugi interapt se desi. Dispečer aktivira odgovarajuči hendler zavisno od vlasnika drajvera : RTAI, Linux ili obadva ( RTAI prvi a zatim Linux). Adrese Linux hendlera se pohranjuju prije promjene IDT u HAL -u. Dispečer upravlja sa interapt kontrolerom i brine se o mogućim interaptima koji čekaju ili zahtjevima za servisiranjem. 32

DESIGN OF RTOS SYSTEMS Inicijalizacija: Ovo je dvostepeni proces. Kod inicijalizacije modula svi Linux podaci se pohranjuju uključujući HAL, i svi RTAI globalni podaci se setuju. Dispečer nije aktivan. Drugi korak akcija montaže ( mount) , koju izvršava rasporedjivač. Montaža RTAI uglavnom ažurira HAL i dispečer se starta. Čišćenje ( clean up): Ovo je takodjer dvostepeni proces. RTAI mora biti prvo demontiran ( unmounted). Ova operacija restaurira HAL, Linux IDT i deskriptore hendlera. Nakon toga se modul otklanja, a funkcija cleanup ustvari ne čini nikakvu akciju. Funkcionalno ponašanje: Šema na slijedećoj slici pokazuje da RTAI lovi ( traps) neke interapte. On ih ulančava sa Linux izvornim hendlerom ako takav postoji ( napr. 8254 hendler). Dispečer je ISR ( interapt servisna rutina), čija je adresa pohranjena u opštu tabelu ( napr. IDT na Intelovoj mašini). Ona 33 opslužuje interapte ili IRQ ( inerrupt request).

DESIGN OF RTOS SYSTEMS Dispečer uzima takodjer u obzir '' system request handlers'' i to: - SRQ ( service request) je hendler koji se koristi za implementaciju sistemskih poziva. SRQ može biti ili RTAI hendler ( napr. fifo), ili korisnički hendler ( User hendler). RTAI upravlja sa do 31 SRQ-ova. - SRQ hendler adrese su pohranjene u IDT. - IT dispečer opslužuje RTAI SRQ-ove dok drugi dispečer upravlja sa User SRQ. IDT tačka ulaza za User SRQ je 254, hendler starta kao ''trap'' i izvršava se na nivou privilegije User na Intel mašinama. 34

DESIGN OF RTOS SYSTEMS 35

DESIGN OF RTOS SYSTEMS Rasporedjivači Cilj: Rasporedjivač je zadužen za rasporedjivanje CPU na različite taskove koji su prisutni u sistemu ( uključujući i Linux). Rasporedjivanje se pojavljuje u slijedećim slučajevima: * * kada task izvrši neke sistemske pozive ( vidjeti u nastavku) kod aktivacije hendlera tajmera ( svaki 8254 interapt) Svaka arhitektura mašine ( SMP, UP ) dobija svoj vlastiti rasporedjivač i RTAI podržava obadva moda i jednookidne ( one-shot) i periodični mod. Slijedeći opisi će se fokusirati na periodični rasporedjivač za jednoprocesorsku mašinu. 36

DESIGN OF RTOS SYSTEMS Inicijalizacija: dvostruko uvezana lista koja održava deskriptor taska, se inicijalizira ( bazično, zaglavlje liste prestavlja Linux deskriptor ), i RTAI se montira da bi aktivirao izvršenje. Clean up : Kada rasporedjivać se namjerava zaustaviti, on mora: * počistiti ( clear ) tajmer – 8254 * pobrisati sve taskove da bi oslobodio memoriju * demontirati ( un-mount) RTAI Funkcionalno ponašanje rasporedjivača: rasporedjivač traži ready taskove ili taskove sa isteklim periodom ( napr. koji ćekaju na semaforima, koji su primili poruku, rpc ( remote procedure call ) , . . u nekom intervalu vremena) Na vremenski dogadjaj, hendler tajmera 8254 mjenja stanje ovih taskova da bi bili izabrani. 37

DESIGN OF RTOS SYSTEMS Task može biti u jednom od slijedećih stanja: READY, SUSPENDED, DELAYED, SEMAPHORE, SEND, RECEIVE, RPC, RETURN, RUNNING, DELETED. Rasporedjivač izabire prvi task sa najvećim prioritetom u READY stanju. RTAI smatra prioritet 0 kao najveći prioritet i 0 x 3 fff. Ffff kao najniži. Linuxu je dodjeljen prioritet 0 x 7 fff. Ffff. Za dati nivo prioriteta, prvi inicijalizirani task će biti prvi izabrani i izvršavaće se do završetka, izuzev kada: • task sa većim prioritetom je izabran • task se završio • task poziva blokiranu sistemsku funkciju 38

DESIGN OF RTOS SYSTEMS Sistemski pozivi koji izvršavaju rt-rasporedjivanje pozivajući funkciju ''rt_schedule'' su: rt_task_delete rt_task_yield rt_task_suspend rt_task_resume rt_sem_signal rt_sem_wait_until rt_return rt_task_make_periodic rt_receive rt_task_wait_period rt_receive_if rt_sleep rt_receive_until rt_send_if rt_send_until rt_rpc_if rt_rpc_until rt_sleep_until RTAI preuzima brigu o aktivaciji Linuxa. 39

DESIGN OF RTOS SYSTEMS Kada hendler tajmera se izvršava, i dostignut je slijedeći vremenski period Linuxa, Linux koji ćeka na interapt se podiže i bit će opslužen od strane dispečera. Opaska: rasporedjivač upravlja preklapanjem sa Linuxa na RTAI, sa RTAI na Linux uključujući i kontekst pokretnog zareza, i nakon toga starta izabrani task. Jiffies menadjment U Linuxu, kada se desi interapt tajmera, vrijednost jiffies se inkrementira, jiffies je prema tome broj otkucaja sata, od trenutka kada je računar uključen. Za izvršenje RTAI treba neko vrijeme, i može se desiti da se neki Linux jiffies propuste, i time poremete aktivnosti vezane sa vremenom. Ako je to tako, Linux vrijeme se ažurira i Linux aktivacija se 40 ponovno pripremi ( rt_pend_linux_irq)

DESIGN OF RTOS SYSTEMS Da bi RTAI održavao ovaj brojač ažurnim , instaliran je jedan interapt hendler ( recover_jiffies). Ovaj hendler se dodaje na 8254 interapt kao Linux dijeljeni hendler ( SA_SHIRQ). Ova karakteristika je upravljana od strane Linux kernela i namjenjena je za dijeljene višestruke uredjaje na istoj interapt liniji. FIFO-i Cilj: FIFO-i omogućavaju Linux procesima i RTAI taskovima da izmjenjuju bajt organizovane podatke. FIFO je jednostruko usmjereni kanal, tako da za duplex komunikaciju u obadva pravca su potrebna 2 FIFO-a. Sa tačke gledišta procesa, FIFO dozvoljava ne-blokirajuče ili asinhrone I/O. Da bi izvršio sinhrona čitanja ( i da izbjegne poling ), RTAI omogućava da se priključi korisnički real-time hendler na FIFO. 41

DESIGN OF RTOS SYSTEMS Sa softverske tačke gledišta FIFO-i se implementiraju kao: • Linux device drajver za procese • sistemski pozivi za real-time taskove Ponašanje FIFO-a Funkcionalno ponašanje: Dizajn FIFO-a je izgradjen na konceptu device drajvera kod Linuxa, koristeći odgodjenu (deferred) operaciju (donja polovina ). RTAI će koristiti ovu donju polovinu da upozori Linux da su podaci raspoloživi. Ova arhitektura, u skladu sa dizajnom Linuxa, desinhronizira izvršenje Linuxa od RTAI akcija. Ona nudi bolji kompromis izmedju: * Sigurnog korištenja osobina Linux kernela ( rasporedjivač, interapti, drajveri, . . . ). *RTAI performansi ( RTAI održava mali SAPI ( server application programming interface), i zakašnjava 42 neurgentne akcije).

DESIGN OF RTOS SYSTEMS Funkcionalno ponašanje FIFO'a se oslanja na 1. stranu Linuxa 2. stranu RTAI 3. komunikaciju izmedju obadvije strane 4. menadjment korisničkih podataka Djeljena memorija Mada API nije isti, on je vrlo slićan onome kod SYSTEM V djeljene memorije. Podaci se ne stavljaju u redove te: * aplikacija mora definisati hendšejk protokol * blokiranje nije direktno podržano 43

DESIGN OF RTOS SYSTEMS Dozvoljava djeljenje memorije izmedju i unutar real-time taskova i Linux procesa. Može se pristupiti od strane bilo kojeg broja taskova , dakle ne samo point-point ( tačka- tačka). API za djeljenu memoriju # include < rtai_shm. h> 44

DESIGN OF RTOS SYSTEMS Slijedeći graf pokazuje koje fajlove direktno ili indirektno uključuje ovaj fajl: Kernel funkcije void *rtai_kmalloc ( unsigned long name, int size ); void rtai_kfree ( unsigned long name); Procesne funkcije void *rtai_kmalloc ( unsigned long name, int size ); void rtai_kfree ( unsigned long name) 45

DESIGN OF RTOS SYSTEMS Utilities unsigned long nam 2 num ( const char *name); void num 2 nam ( unsigned long num, char *name); dinamička alokacija memorije void *rt_malloc (int size); void rt_free ( void *addr); Druge IPC primitive Servisi poruka ( messaging services) - rt_send / rt_receive : blokirajuće , neblokirajuće i vremenske Servisi daljinskih poziva ( remote procedure call – RPC ): - rt_rpc / rt_receive : blokirajuće , neblokirajuće i vremenske 46

DESIGN OF RTOS SYSTEMS Mailbox servisi - rt_mbx_send / rt_mbx_receive : blokirajuće , neblokirajuće i vremenske Semaforske primitive - rt_sem_wait / rt_sem_signal: vremenski ili ne LXRT * Obezbjedjuje servise za meko/tvrdo realno vrijeme u prostoru korisnika, omogučavajući korištenje svih servisa koji su raspoloživi u RTAI ( i njegovih rasporedjivača) u prostoru korisnika. * Omogućava razvoj real-time taskova pod memorijskom zaštitom Linuxa. * Omogućava dinamičko preključenje taskova izmedju hard/soft modova realnog vremena iz aplikacije 47

DESIGN OF RTOS SYSTEMS Kompromisi su: * nekoliko mikrosekundi kašnjenja zbog nužnosti da se prodju granice izmedju nivoa korisnika i kernela. * sistemski pozivi iz standardnog Linuxa koji vode do preključenja taska nisu više dozvoljeni : RTAI može presresti ove slučajeve ako to pokušamo i napravimo naš task soft realnim vremenom. Naš task će se vratiti u hard realtime kada pozove bilo koju RTAI funkciju. * Taskovi u hard realtime korisničkom prostoru su normalni Linux procesi koji se uparuju sa specijalnim blizanac task modulom u hard realtime kernelu. * Oni moraju biti POSIX realtime Linux procesi koji koriste SCHED_FIFO i zaključani su u memoriji, izbjegavjući na taj način da budu swapped out iz glavne memorije. 48

DESIGN OF RTOS SYSTEMS • Migracija od mekog ka tvrdom realtime-u ( što će dovesti do toga da će task biti rasporedjivan od strane RTAI ) se dešava u trenutku kada se poziva primitiva '' rt_make_hard_real_time()''. * Task je ukraden od Linux-ovog rasporedjivača i prebaćen ka RTAI rasporedjivaču. Nakon ove tranzicije, migrirani/ukradeni task ostavljen u TASK_UNINTERRUPTIBLE stanju iščezava iz Linux-ovog ''radara'' ( tj. pažnje), na isti način kao i svaki drugi suspendirani task. * Promjeniti strategiju rasporedjivanja na SCHED_FIFO i definirati njegov prioritet koristeći '' sched_setscheduler'', sistemski poziv iz Linuxa. - ovo će se desiti upravo na početku koda ( u inicijalizacionoj 49 fazi).

DESIGN OF RTOS SYSTEMS * U ovom trenutku task će biti soft realtime task i bit će u mogućnosti da koristi bilo koju RTAI primitivu. *Da bi se izbjeglo da task bude ''swapped out'', tj. prebaćen iz glavne memorije na sekundarnu memoriju, treba biti zaključan u RAM koristeći slijedeći kod prije njegove inicijalizacije : -mlockall ( MCL_CURRENT Ι MCL_FUTURE ); * Do ovog trenutka '' rt_make_hard_real_time()'' je mogao biti korišten da migrira task ka hard realtime rasporedjivaču, dok ga ''rt_make_soft_real_time()'' vraća natrag. 50

DESIGN OF RTOS SYSTEMS LXRT servisi #include <rtai_lxrt. h> Procesne funkcije Funkcije taskova ( registracija i deregistracija taskova) Utility funkcije 51

DESIGN OF RTOS SYSTEMS Hard realtime u korisnikovom prostoru rt_make_hard_real_time čini soft Linux POSIX realtime proces, od onog taska iz kojeg je pozvan hard realtime LXRT procesom. Važno je napomenuti da ova funkcija mora biti korištena samo sa soft Linux POSIX procesima koji imaju svoju memoriju zaključanu u glavnoj memoriji. rt_make_soft_real_time vraća ga u soft Linux POSIX realtime proces, task iz koga je pozvan, a koji je prethodno bio pretvoren u ovaj proces pomoću poziva prve funkcije. 52

DESIGN OF RTOS SYSTEMS Primjetimo da procesi koji su napravljeni hard realtime trebaju izbjegavati da pozovu bilo koji Linux sistemski poziv koji može dovesti do preključenja taska, pošto Linux ne može izvršavati procese koji su napravljeni hard realtime. Da bi interaktirali sa Linuxom potrebno je kuplovati proces koji je napravljen hard realtime sa Linux buddy serverom, bilo sa standardnim ili POSIX soft realtime procesom. Da bi komunicirali i sinhrozivali se sa buddy-jem , možemo koristiti obilje raspoloživih RTAI servisa kao i servisa njegovih rasporedjivača. Nakon svega, bilo bi besmisleno koristiti nonhard realtime operativni sistem, kao napr. Linux, iz samih hard realtime procesa. rt_allow_nonroot_hrt : ova funkcija omogućava non root korisniku da koristi Linux POSIX funkcije za soft realtime proces menadjment i zaključavanje memorije, kao i da omogući da može da izvrši bilo koju ulazno-izlaznu operaciju 53 iz korsničkog prostora.

DESIGN OF RTOS SYSTEMS Taskovi Cilj : task je predstava aktiviteta od : * aplikacija ( u kernelskom i/ili korisnikovom modu ) * drajvera periferala ( ISA ili vlastitih) ( u kernel modu ) Da bi se postigao cilj, RTAI izvozi olakšice ( facilities) kao što su : Funkcije taskova vremenske funkcije semafora 54

DESIGN OF RTOS SYSTEMS Komunikaciju izmedju taskova ( intertask communication) kao što su ( send, receive, rpc ). Servisne funkcije ( menadjment interapta ) FIFO komunikacione funkcije Osobine dijeljene memorije Taskovi: POSIX interfejs Interfejs nudi mnogo POSIX. 1 c fukcija koje omogućavaju korisniku da: * se odveže od izvršne jezgre ( executive) što pomaže zamjeni OS * unificira programiranje interfejsa ( LINUX, RTAI, … ) * olakša integraciju softvera trečih strana * koristi standardne razvojne i test alate 55 * razvija i debagira u drugom Posix okruženju

DESIGN OF RTOS SYSTEMS LXRT obezbjedjuje familiju servisa realtime rasporedjivača koji mogu biti korišteni od strane i RTAI realtime taskova kao i Linux taskova. Da bi stvari se zadržale jednostavnim za programere, implementacija je potpuno simetrična. Drugim riječima, isti funkcionalni pozivi se koriste i u kernelskom i u korisničkom prostoru. Pogledajmo detaljnije ove servise realtime rasporedjivača. RTAI nudi standardne servise kao što su : resume, yield, suspend, make periodic, wait until, itd. Naći ćemo takoder semafore, mail boksove, daljinske pozive procedura ( rpc- remote procedure calls), send i receive primitive, integrisane u state mašinu realtime rasporedjivača. 56

DESIGN OF RTOS SYSTEMS LXRT kreira realtime task koji postaje ‘’andjeo’’ našeg programa. Posao ovog andjela je da izvršava realtime servise za naše potrebe. Naprimjer, ako mi pozovemo rt_sleep(. . . ), LXRT će koristiti andjela da izvrši pravu rt_sleep() funkciju u okviru realtime rasporedjivača. Kontrola nad procesorom će se vratiti na naš program kada andjeo se vrati iz rutine rt_sleep(). Da li sa LXRT, Linux task može poslati poruku na realtime task? Da, i to se realizuje jednostavnim korištenjem rt_send(. . ) primitive koju bi normalno koristili u kodu kernelskog programa. LXRT poziva andjela da izvrši rt_send(. . . ). Kontrola se vraća na naš program kada ciljni task kompletira odgovarajući rt_receive(. . . ) poziv. 57

DESIGN OF RTOS SYSTEMS Šta se dešava kada pošaljemo poruku nekom drugom programu u korisničkom prostoru? Ono što se dešava je vrlo slično prethodnom slučaju, samo što ćemo sada imati dva andjela koji govore jedan sa drugim. Realtime task takodjer registrira svoje ime sa LXRT. Za to on koristi poziv rt_register( name, . . . ). Na taj način drugi programi, realtime ili ne, mogu naći task pokazivač na ovaj naš program i komunicirati sa njim. Nema potrebe za nekim kodom za realtime komponentu Linux taska kojeg pišemo. LXRT koristi standardne RTAI rasporedjivačke funkcije za to. U QNX svijetu, andjeo se naziva ‘’virtualno kolo’’ ( virtual circuit). Inlajn funkcije deklarisane u rtai_lxrt. h sve koriste softverski 58 interapt ( int 0 x. FC).

DESIGN OF RTOS SYSTEMS Linux sistem pozivi koriste softverski interapt 0 x 80. Pošto je pristup slićan onom za sistemske pozive, LXRT postavlja interapt vektor da bi pozvao rtai_lxrt_handler(void), tj. funkciju koja pohranjuje sve na stek, izmjenjuje ds i es registre u _KERNEL_DS i zatim poziva lxrt_handler, tj. funkciju koja će odraditi sam posao. Poziv lxrt_handler(. . . ) vadi prvi argument iz korisničkog prostora i odlučuje šta da radi iz broja servisnog zahtjeva srq. Za realtime servise, lxrt_resume(. . . ) će se pozvati sa pokazivačem na adresu funkcije rasporedjivača fun, zatim odredjeni broj preostalih argumenata, pokazivač na slijedeći argument, tipa servisa, kao i pokazivač na realtime task. Lxrt_resume(. . . ), će učiniti ono što je neophodno da se promjeni kontekst izvršenja RTAI i prebaci izvršenje na 59 specificiranu adresu funkcije u realtime rasporedjivaču.

DESIGN OF RTOS SYSTEMS lxrt_resume(. . . ) prvo kopira druge argumente na steku relatime taska. Bilo koji zahtjevani podaci se vade iz korisničkog prostora i kopiraju u rt_task ->msg_buf. U ovom trenutku, adrese tri funkcije se pohranjuju iznad stack_top ( LXRT će obezbjediti da ovaj wizard bude moguć kada je prvi put kreiran realtime task): top-1 lxrt_suspend(. . . ) top-2 fun(. . . ) top-3 lxrt_global_sti(. . . ) Stek se mijenja do top-3 , globalni interapti su onemogućeni i kontekst izvršenja se preključuje na RTAI sa pozivom na LXRT_RESUME(rt_task). RTAI izvršava lxrt_global_sti(. . . ), fun(. . ), i eventualno lxrt_suspend(. . . ). Podsjetimo se da je fun(. . . ) slićna funkciji RTAI rasporedjivača, napr. Rt_rpc(. . . ). 60

DESIGN OF RTOS SYSTEMS U ovoj tačci, fun(. . . ) se može ili ne mora kompletirati. Lagan način za povratak u korisnički prostor je sa – fun (. . . ) koja se odmah izvršava. RTAI ulazi u funkciju lxrt_suspend(. . . ), koja postavlja status realtime taska na 0 i poziva rt_schedule(). Kontekst izvršenja se eventualno preključuje natrag na Linux i ponovo nastavlja sistemski poziv nakon LXRT_RESUME(rt_task). Podaci za mail boksove se kopiraju u korisnički prostor i skok na ret_from_intr() se provodi da bi se kompletirao sistemski poziv. Vidimo da je dugi put povratka u korisnički prostor kojeg – fun(. . ) ne može trenutačno kompletirati. RTAI rasporedjuje Linux da se ponovo izvršava i status realtime taska je ne nulti, što indicira da je on zadržan. 61

DESIGN OF RTOS SYSTEMS Dakle, RTAI suspenduje zahtjev sistemskog poziva da bi instruktirao Linux da izvrši drugi sistemski poziv čiji hendler je funkcija lxrt_srq_handler(void). Kada Linux poziva lxrt_srq_handler(), originalni sistemski poziv se prerasporedjuje za izvršenje i vraća u korisnički prostor kao što je gore objašnjeno. U slučaju da Linux task krašira, tada: pošto je informirana verzija LXRT uspostavila pokazivač na callback funkciju n, u do_exit() kodu Linux kernela, ovaj callback se koristi da oslobodi resurse koji su bili registrirani za taj realtime task. Ona takodjer izbriše taj realtime task i deblokira bilo koji drugi task koji može biti tipa : SEND, RPC, RETURN, ili SEM koji je bio blokiran na tom realtime tasku koji je kraširao. 62

DESIGN OF RTOS SYSTEMS Tipično, IPC funkcionalni pozivi podržavaju: -Blokiranje dok se transakcija ne pojavi -Trenutačni povrat ako drugi kraj nije spreman. -Blokiranje transakcije dok se ne pojavi timeout Kako se podešava Linux program za LXRT? Potrebno je pozvati rt_task_init ( name, . . ). Ovaj poziv se razlikuje od svog realtime parnjaka ( pošto ipak postoje neki izuzetci od pravila simetrije), i po tome, izmedju ostalih, što je potrebno dati neko ime za naš program. Ovo ime mora biti jedinstveno i ono se registruje od strane LXRT. Odatle, drugi programi, bilo u realnom vremenu ili ne, mogu naći pokazivač na ovaj task i komunicirati sa njim. 63

DESIGN OF RTOS SYSTEMS Korisnički taskovi trebaju takodjer uključiti neke važne LINUX i RTAI fajlove kao : ‘’rtai. h’’, ‘’sched. h’’, ‘’rtai _fifos. h’’, ‘’module. h’’, ‘’kernel. h’’, ‘’errno. h’’, ‘’rtai_lxrt. h’’, …. Kao i RTAI, Linux uključuje fajlove koji kreiraju neke ‘’Linux zavisnosti’’ ( Linux dependencies), koje mogu da utiču na korisničke programe kada se Linux pojavi sa novom verzijom. Inicijalizacija taskova Slijedeće akcije omogućavaju korištenje taskova: - inicijalizacija taskova - izbor ponašanja rasporedjivača ( jednokidni ili periodični ) - startanje tajmera - uticaj na period taska 64

DESIGN OF RTOS SYSTEMS * Task deskriptori se statički doznačuju u RTAI memoriji ( stekovi taskova se dodjeljuju u Linux memoriji ( kmalloc)). - Modul mora startati tajmer da bi inicijalizirao 8254 i dobio regularne otkucaje tajmera za rasporedjivač taskova. * Taskovi su periodični, promjena perioda taska ga i pokreće. - Medjutim interfejs omogućava taskovima da se ponašaju i u neperiodičnom modu ( napr. da ćekaju na neki dogadjaj u beskonačnoj petlji. ) Za kernelske taskove, svi ovi koraci su uključeni u ulaznu tačku modula taska ( putem init_module). Za korisnike Linux taskova, ovi koraci se provode nakon neophodnih inicijalizacija koje su uvjetovane od strane LXRT. 65

DESIGN OF RTOS SYSTEMS Clean-up taskova * Task mora u svojoj završnoj fazi, osloboditi sve resurse koji su mu bili alocirani ( tj. memoriju, semafore, FIFO, itd. ) u fazi inicijalizacije ( uključujući i svoj vlastiti deskriptor taska ). * Ove aktivnosti trebaju biti izvršene unutar funkcije modula cleanup_module, u slučaju da je riječ o kernelskom tasku, ili nakon što se task vrati natrag u soft realtime mod, u slučaju da je riječ o hard realtime tasku u korisničkom modu rada. * Posljednji task u sistemu mora takodjer zaustaviti tajmer ( obično je to onaj isti task koji ga je i startovao). 66