660 likes | 851 Views
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.).
E N D
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 WinNT 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.
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 Radisys- ov Intime ili VenturCom-ov RTX. za UNIX: mikro kernel bazirane tehnologije izvorno 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 u realnom vremenu ( L4 Linux): eksperimentalni projekat. Linux kao task izvršnog dijela za realno vrijeme: RTLinux, RTAI, eCos, Nucleus,....
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
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:
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.
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.
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.
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 uredu 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 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.
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.
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.
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.
DESIGN OF RTOS SYSTEMS Linux za uronjene i realtime aplikacije Konceptualno,kernel održavaFIFO 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.
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.
DESIGN OF RTOS SYSTEMS Strategija poboljšanja priempcije pretvara spinlocks u ekvivalentne EnterCritical() i ExitCritical() 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.
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 koje koriste standardne Linux/POSIX API-je. 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 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 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 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.
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.
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. TimeSys priemptabilni kernel se može naći na : www.timesys.com LinuxWorks nudi verziju RTLinuxa, licenciranu od FSM Labs, koja se naziva BlueCat 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 RTAI real time entiteti su jednostavni monokončani taskovi dok su Linux aplikacije mono ili multi končani procesi sa svim 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
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.
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 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 poznatefunkcije : 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)
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 descriptiontable)tretirajući Linux kao jednostavnog korisnika. * Linux pristupa RTAI modificiranim funkcijama. HAL kontejner 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.
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_8259A_irq(irq); orginalni kod rthal.unmask_8259A_irq(irq);// novi kod koristeči RTHAL funkciju ). Linux inicijalizira HAL sa funkcijama pokazivanja na izvorne 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.
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
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.
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 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.
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.
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.
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 0x3fffFfff kao najniži. Linuxu je dodjeljen prioritet 0x7fffFfff. 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
DESIGN OF RTOS SYSTEMS Sistemski pozivi koji izvršavaju rt-rasporedjivanje pozivajući funkciju ''rt_schedule'' su: rt_task_delete rt_sem_signal rt_send rt_task_yield rt_sem_wait rt_send_if rt_task_suspend rt_sem_wait_until rt_send_until rt_task_resume rt_return rt_rpc rt_task_make_periodic rt_receive rt_rpc_if rt_task_wait_period rt_receive_if rt_rpc_until rt_sleep rt_receive_until rt_sleep_until RTAI preuzima brigu o aktivaciji Linuxa.
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 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.
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 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
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>
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)
DESIGN OF RTOS SYSTEMS Utilities unsigned long nam2num ( const char *name); void num2nam ( 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
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
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.
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 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.