RTLinux - RTLinux

For ikke at forveksle med Real-Time Linux , det officielle patchset til hård real-time support i Linux-kernen.
RTLinux
Originale forfattere Victor Yodaiken, Michael Barabanov
Udvikler (er) FSMLabs, Wind River Systems
Skrevet i C
Operativ system Linux
Tilgængelig i engelsk
Type Kerne
Licens GPL2

RTLinux er et patenteret hårdt real-time operativsystem (RTOS) mikrokerne, der kører hele Linux- operativsystemet som en fuldstændigt forebyggende proces. Den hårde real-time ejendom gør det muligt at styre robotter, dataindsamlingssystemer, produktionsanlæg og andre tidssensitive instrumenter og maskiner fra RTLinux-applikationer. På trods af det lignende navn er det ikke relateret til Real-Time Linux- projektet fra Linux Foundation .

RTLinux blev udviklet af Victor Yodaiken, Michael Barabanov, Cort Dougan og andre ved New Mexico Institute of Mining and Technology og derefter som et kommercielt produkt hos FSMLabs. Wind River Systems erhvervede FSMLabs integreret teknologi i februar 2007 og stillede en version til rådighed som Wind River Real-Time Core til Wind River Linux . I august 2011 har Wind River afbrudt Wind River Real-Time Core-produktlinjen, hvilket effektivt afslutter kommerciel support til RTLinux-produktet.

Baggrund

Det centrale RTLinux-designmål var at tilføje hårde realtidsfunktioner til et handelsoperativsystem for at lette udviklingen af ​​komplekse kontrolprogrammer med begge funktioner. For eksempel vil man måske gerne udvikle en motorstyring i realtid, der brugte en varedatabase og eksporterede en weboperatørgrænseflade. I stedet for at forsøge at bygge et enkelt operativsystem, der kunne understøtte realtids- og ikke-realtidsfunktioner, blev RTLinux designet til at dele en computerenhed mellem et real-time og ikke-real-time operativsystem, så (1) real-time operativsystem kunne aldrig blokeres for udførelse af det ikke-real-time operativsystem, og (2) komponenter, der kører i de to forskellige miljøer, kan let dele data. Som navnet antyder, var RTLinux oprindeligt designet til at bruge Linux som ikke-real-time system, men det udviklede sig til sidst, så RTCore realtidskernen kunne køre med enten Linux eller BSD UNIX .

Multi-Environment Real-Time (MERT) var det første eksempel på et realtidsoperativsystem, der samtidig eksisterede med et UNIX-system. MERT stolede på traditionelle virtualiseringsteknikker: kernen i realtid var værtens operativsystem (eller hypervisor ) og Bell Systems UNIX var gæst . RTLinux var et forsøg på at opdatere MERT -konceptet til pc -æra og råvarehardware. Det var også et forsøg på også at overvinde ydelsesgrænserne for MERT, især de omkostninger, der blev indført ved virtualisering.

Teknikken blev kun brugt til at virtualisere gæsteafbrydelsesstyringen. Denne metode gjorde det muligt for realtidskernen at konvertere gæstestyresystemet til et system, der var fuldstændigt forudsigeligt, men som stadig kunne styre f.eks. Lagerenheder. Især standarddrivere til gæsten arbejdede uden kildeændringer, selvom de skulle kompileres igen for at bruge virtualiserings "kroge". Se også paravirtualisering . UNIX "pipen" blev tilpasset til at tillade programmer i realtid og ikke-realtid til at kommunikere, selvom andre metoder såsom delt hukommelse også blev tilføjet.

Fra programmørens synspunkt lignede RTLinux oprindeligt et lille gevindmiljø til realtidsopgaver plus standard Linux-miljøet for alt andet. Realtidsoperativsystemet blev implementeret som et indlæseligt kernemodul, der begyndte med at virtualisere gæsteafbrydelsesstyring og derefter startede en realtidsplanlægger. Opgaver blev tildelt statiske prioriteter, og planlægning var oprindeligt rent prioritetsdrevet. Gæsteoperativsystemet blev inkorporeret som den lavest prioriterede opgave og fungerede i det væsentlige som den inaktive opgave for realtidssystemet. Opgaver i realtid kørte i kernel mode. Senere udvikling af RTLinux vedtog POSIX-tråde applikationsprogrammeringsinterface ( API ) og tillod derefter oprettelse af tråde i brugerfunktion med realtids-tråde, der kører inde i gæsteprocesser. I multiprocessormiljøer blev tråde låst til processorkerner, og det var muligt at forhindre gæstetråden i at køre på den udpegede kerne (effektivt reservere kerner til kun behandling i realtid).

Implementering

RTLinux giver mulighed for at køre særlige realtidsopgaver og afbryde håndterere på den samme maskine som standard Linux. Disse opgaver og håndtere udføres, når de skal udføre, uanset hvad Linux gør. Tiden i værste fald mellem det øjeblik, hvor en hardware -afbrydelse registreres af processoren, og det øjeblik, en afbrydelseshandler begynder at udføre, er under 15 mikrosekunder på RTLinux, der kører på en generisk x86 (ca. 2000). En RTLinux periodisk opgave kører inden for 35 mikrosekunder af sin planlagte tid på den samme hardware. Disse tider er hardware -begrænsede, og efterhånden som hardware forbedres, vil RTLinux også blive forbedret. Standard Linux har fremragende gennemsnitlig ydeevne og kan endda levere præcision i planlægning på millisekundniveau for opgaver ved hjælp af POSIX soft-real-time funktioner. Standard Linux er imidlertid ikke designet til at levere præcision under millisekunder og pålidelige timinggarantier. RTLinux var baseret på en letvægts virtuel maskine, hvor Linux "gæst" fik en virtualiseret afbrydelsescontroller og timer, og al anden hardwareadgang var direkte. Set fra realtids "vært" er Linux-kernen en tråd. Afbrydelser, der er nødvendige for deterministisk behandling, behandles af kernen i realtid, mens andre afbrydelser videresendes til Linux, som kører med en lavere prioritet end realtidstråde. Linux -drivere håndterede næsten alle I/O . First-In-First-Out-rør ( FIFO'er ) eller delt hukommelse kan bruges til at dele data mellem operativsystemet og RTLinux.

Objektiv

Det centrale RTLinux -designmål er, at systemet skal være gennemsigtigt, modulært og udvideligt. Gennemsigtighed betyder, at der ikke er nogen uåbnelige sorte bokse, og omkostningerne ved enhver operation bør kunne bestemmes. Modularitet betyder, at det er muligt at udelade funktionalitet og omkostningerne ved denne funktionalitet, hvis det ikke er nødvendigt. Og udvidelse betyder, at programmører skal kunne tilføje moduler og skræddersy systemet til deres krav. Base RTLinux -systemet understøtter højhastighedsafbrydelse og ikke mere. Den har en enkel prioritetsplanlægger, der let kan erstattes af planlæggere, der er mere velegnet til behovene i en bestemt applikation. Ved udviklingen af ​​RTLinux blev det designet til at maksimere den fordel, vi får ved at have Linux og dets kraftfulde funktioner til rådighed.

Kernekomponenter

RTLinux er struktureret som en lille kernekomponent og et sæt valgfrie komponenter. Kernekomponenten tillader installation af meget lave latency -afbrydere, der ikke kan forsinkes eller forhindres af Linux selv og nogle synkroniserings- og afbrydelsesstyringsrutiner på lavt niveau. Denne kernekomponent er blevet udvidet til at understøtte SMP, og samtidig er det blevet forenklet ved at fjerne nogle funktioner, der kan leveres uden for kernen.

Funktionalitet

Størstedelen af ​​RTLinux -funktionaliteten er i en samling af indlæselige kernemoduler, der leverer valgfrie tjenester og abstraktionsniveauer. Disse moduler omfatter:

  1. rtl sched - en prioritetsplanlægger, der understøtter både en "lite POSIX" grænseflade beskrevet nedenfor og den originale V1 RTLinux API.
  2. rtl -tid - som styrer processorens ure og eksporterer en abstrakt grænseflade til tilslutning af håndtere til ure.
  3. rtl posixio - understøtter POSIX -stil læse/skrive/åbne grænseflade til enhedsdrivere.
  4. rtl fifo - forbinder RT -opgaver og afbryder håndterere til Linux -processer gennem et enhedslag, så Linux -processer kan læse/skrive til RT -komponenter.
  5. semafor - en bidraget pakke af Jerry Epplin, som giver RT -opgaver, der blokerer semaforer.
  6. POSIX mutex support er planlagt til at være tilgængelig i den næste mindre version opdatering af RTLinux.
  7. mbuff er en bidraget pakke skrevet af Tomasz Motylewski til at levere delt hukommelse mellem RT -komponenter og Linux -processer.

Opgaver i realtid

RTLinux -realtidsopgaver bliver implementeret som kernemoduler, der ligner den type modul, Linux bruger til drivere, filsystemer og så videre. Realtidsopgaver har direkte adgang til hardwaren og bruger ikke virtuel hukommelse. Ved initialisering informerer en realtime-opgave (modul) RTLinux-kernen om dens deadline, periode og frigivelsestidsbegrænsninger.

Tråde

RT-Linux implementerer en POSIX API til manipulation af en tråd. En tråd oprettes ved at kalde pthread_createfunktionen. Den tredje parameter for pthread_createer en funktion, der indeholder koden udført af tråden.

Det er nødvendigt at angive trådprioriteter i RTLinux. Tråde med højere prioriteter kan forhindre tråde med lavere prioriteter. For eksempel kan vi have en gevind, der styrer en trinmotor. For at flytte motoren flydende, er det nødvendigt at starte denne tråd med strengt regelmæssige intervaller. Dette kan garanteres ved at tildele denne tråd en høj prioritet. Eksemplet threads2.c angiver forskellige trådprioriteter. Indstilling af trådprioritet udføres ved hjælp af koden vist nedenfor: 

int init_module(void)
{
pthread_attr_t attr;
struct sched_param param;
pthread_attr_init(&attr);
param.sched_priority = 1;
pthread_attr_setschedparam(&attr, &param);
pthread_create(&t1, &attr, &thread_code, "this is thread 1");
rtl_printf("Thread 1 started\n");
...
}

Outputprogrammet er som følger. 

Thread 1 started
Thread 2 started
Thread 3 started
Message: this is thread 1
Message: this is thread 2
Message: this is thread 2
Message: this is thread 2
Message: this is thread 1
Message: this is thread 1
Message: this is thread 3
Message: this is thread 3
Message: this is thread 3

Tråden 2 har den højeste prioritet, og tråden 3 har den laveste prioritet. Den første besked udskrives af den midterste prioritetstråd 1, fordi den startes kort tid før tråden 2.

Se også

Referencer

Kilder

eksterne links