RTLinux - RTLinux

Niet te verwarren met Real-Time Linux , de officiële patchset voor harde realtime ondersteuning in de Linux-kernel.
RTLinux
Oorspronkelijke auteur(s) Victor Yodaiken, Michael Barabanov
Ontwikkelaar(s) FSMlabs, Wind River Systems
Geschreven in C
Besturingssysteem Linux
Beschikbaar in Engels
Type Kernel
Vergunning GPL2

RTLinux is een gepatenteerde harde realtime realtime besturingssysteem (RTOS) microkernel die het volledige Linux- besturingssysteem als een volledig preventief proces uitvoert . De harde real-time eigenschap maakt het mogelijk om robots, data-acquisitiesystemen, fabrieken en andere tijdgevoelige instrumenten en machines vanuit RTLinux-applicaties te besturen. Ondanks de gelijkaardige naam is het niet gerelateerd aan het Real-Time Linux- project van de Linux Foundation .

RTLinux is ontwikkeld door Victor Yodaiken, Michael Barabanov, Cort Dougan en anderen aan het New Mexico Institute of Mining and Technology en vervolgens als een commercieel product bij FSMlabs. Wind River Systems verwierf de ingebouwde technologie van FSMlabs in februari 2007 en stelde een versie beschikbaar als Wind River Real-Time Core voor Wind River Linux . Met ingang van augustus 2011 heeft Wind River de Wind River Real-Time Core-productlijn stopgezet, waardoor de commerciële ondersteuning voor het RTLinux-product effectief is beëindigd.

Achtergrond

De belangrijkste ontwerpdoelstelling van RTLinux was om harde real-time mogelijkheden toe te voegen aan een standaard besturingssysteem om de ontwikkeling van complexe besturingsprogramma's met beide mogelijkheden te vergemakkelijken. Men zou bijvoorbeeld een realtime motorcontroller kunnen ontwikkelen die gebruikmaakt van een goederendatabase en een weboperatorinterface exporteert. In plaats van te proberen een enkel besturingssysteem te bouwen dat real-time en niet-real-time mogelijkheden zou kunnen ondersteunen, werd RTLinux ontworpen om een ​​computerapparaat te delen tussen een real-time en niet-real-time besturingssysteem, zodat (1) de realtime besturingssysteem kan nooit worden geblokkeerd voor uitvoering door het niet-realtime besturingssysteem en (2) componenten die in de twee verschillende omgevingen worden uitgevoerd, kunnen gemakkelijk gegevens delen. Zoals de naam al aangeeft, was RTLinux oorspronkelijk ontworpen om Linux te gebruiken als het niet-realtime systeem, maar het evolueerde uiteindelijk zodat de RTCore realtime-kernel met Linux of BSD UNIX kon draaien .

Multi-Environment Real-Time (MERT) was het eerste voorbeeld van een realtime besturingssysteem dat naast een UNIX-systeem bestond. MERT vertrouwde op traditionele virtualisatietechnieken: de real-time kernel was het hostbesturingssysteem (of hypervisor ) en Bell Systems UNIX was de gast . RTLinux was een poging om het MERT-concept te updaten naar het pc-tijdperk en de standaardhardware. Het was ook een poging om ook de prestatielimieten van MERT te overwinnen, met name de overhead die door virtualisatie werd geïntroduceerd.

De techniek werd alleen gebruikt om de guest interrupt control te virtualiseren. Met deze methode kon de realtime-kernel het gastbesturingssysteem omzetten in een systeem dat volledig verwijderbaar was, maar dat nog steeds rechtstreeks controle kon uitoefenen op bijvoorbeeld opslagapparaten. In het bijzonder werkten standaardstuurprogramma's voor de gast zonder wijziging van de bron, hoewel ze opnieuw moesten worden gecompileerd om de virtualisatie-"hooks" te gebruiken. Zie ook paravirtualisatie . De UNIX "pipe" werd aangepast om real-time en niet-real-time programma's met elkaar te laten communiceren, hoewel er ook andere methoden werden toegevoegd, zoals gedeeld geheugen.

Vanuit het oogpunt van de programmeur zag RTLinux er oorspronkelijk uit als een kleine threaded-omgeving voor real-time taken plus de standaard Linux-omgeving voor al het andere. Het real-time besturingssysteem werd geïmplementeerd als een laadbare kernelmodule die begon met het virtualiseren van guest-interrupt control en vervolgens startte met een real-time scheduler. Taken kregen statische prioriteiten en planning was oorspronkelijk puur prioriteitsgestuurd. Het gastbesturingssysteem was opgenomen als de taak met de laagste prioriteit en fungeerde in wezen als de inactieve taak voor het realtime systeem. Realtime taken werden uitgevoerd in de kernelmodus. Latere ontwikkeling van RTLinux nam de POSIX-threads application programming interface ( API ) over en stond vervolgens het creëren van threads toe in de gebruikersmodus met realtime threads die in gastprocessen werden uitgevoerd. In omgevingen met meerdere processors waren threads vergrendeld op processorkernen en was het mogelijk om te voorkomen dat de gastthread op aangewezen kernen draaide (waardoor de kernen effectief werden gereserveerd voor alleen realtime verwerking).

Implementatie

RTLinux biedt de mogelijkheid om speciale real-time taken en interrupt-handlers op dezelfde machine uit te voeren als standaard Linux. Deze taken en handlers worden uitgevoerd wanneer ze moeten worden uitgevoerd, ongeacht wat Linux aan het doen is. De tijd in het slechtste geval tussen het moment dat een hardware-interrupt wordt gedetecteerd door de processor en het moment dat een interrupt-handler begint uit te voeren, is minder dan 15 microseconden op RTLinux die draait op een generieke x86 (circa 2000). Een periodieke RTLinux-taak draait binnen 35 microseconden van de geplande tijd op dezelfde hardware. Deze tijden zijn hardwarematig beperkt en naarmate de hardware verbetert, zal RTLinux ook verbeteren. Standaard Linux heeft uitstekende gemiddelde prestaties en kan zelfs planningsprecisie op millisecondenniveau bieden voor taken met behulp van de POSIX soft realtime-mogelijkheden. Standaard Linux is echter niet ontworpen om submilliseconden precisie en betrouwbare timing garanties te bieden. RTLinux was gebaseerd op een lichtgewicht virtuele machine waar de Linux "gast" een gevirtualiseerde interruptcontroller en timer kreeg, en alle andere hardwaretoegang was direct. Vanuit het oogpunt van de real-time "host", is de Linux-kernel een thread. Interrupts die nodig zijn voor deterministische verwerking worden verwerkt door de realtime core, terwijl andere interrupts worden doorgestuurd naar Linux, dat een lagere prioriteit heeft dan realtime threads. Linux-stuurprogramma's verwerkten bijna alle I/O . First-In-First-Out-pipes ( FIFO's ) of gedeeld geheugen kunnen worden gebruikt om gegevens te delen tussen het besturingssysteem en RTLinux.

Doelstelling

De belangrijkste ontwerpdoelstelling van RTLinux is dat het systeem transparant, modulair en uitbreidbaar moet zijn. Transparantie betekent dat er geen zwarte dozen zijn die niet kunnen worden geopend en dat de kosten van elke operatie bepaalbaar moeten zijn. Modulariteit betekent dat het mogelijk is om functionaliteit en de kosten van die functionaliteit weg te laten als deze niet nodig is. En uitbreidbaarheid betekent dat programmeurs modules moeten kunnen toevoegen en het systeem aan hun eisen moeten kunnen aanpassen. Het basis RTLinux-systeem ondersteunt snelle afhandeling van interrupts en niet meer. Het heeft een eenvoudige prioriteitsplanner die gemakkelijk kan worden vervangen door planners die meer geschikt zijn voor de behoeften van een specifieke toepassing. Bij het ontwikkelen van RTLinux werd het ontworpen om het voordeel te maximaliseren dat we krijgen door Linux en zijn krachtige mogelijkheden beschikbaar te hebben.

Kern onderdelen

RTLinux is gestructureerd als een kleine kerncomponent en een set optionele componenten. De kerncomponent maakt de installatie mogelijk van interrupt-handlers met zeer lage latentie die niet door Linux zelf kunnen worden uitgesteld of voorkomen, en enkele low-level synchronisatie- en interruptcontroleroutines. Dit kernonderdeel is uitgebreid om SMP te ondersteunen en tegelijkertijd is het vereenvoudigd door enkele functionaliteit te verwijderen die buiten de kern kan worden geleverd.

Functionaliteit

Het merendeel van de RTLinux-functionaliteit bevindt zich in een verzameling laadbare kernelmodules die optionele services en abstractieniveaus bieden. Deze modules omvatten:

  1. rtl sched - een prioriteitsplanner die zowel een "lite POSIX"-interface ondersteunt die hieronder wordt beschreven als de originele V1 RTLinux API.
  2. rtl time - die de klokken van de processor bestuurt en een abstracte interface exporteert voor het verbinden van handlers met klokken.
  3. rtl posixio - ondersteunt de lees/schrijf/open-interface in POSIX-stijl voor apparaatstuurprogramma's.
  4. rtl fifo - verbindt RT-taken en interrupt-handlers met Linux-processen via een apparaatlaag, zodat Linux-processen naar RT-componenten kunnen lezen/schrijven.
  5. semafoor - een bijgedragen pakket van Jerry Epplin dat RT-taken geeft die semaforen blokkeren.
  6. POSIX mutex-ondersteuning is gepland om beschikbaar te zijn in de volgende kleine versie-update van RTLinux.
  7. mbuff is een bijgedragen pakket geschreven door Tomasz Motylewski voor het leveren van gedeeld geheugen tussen RT-componenten en Linux-processen.

Realtime taken

RTLinux realtime taken worden geïmplementeerd als kernelmodules vergelijkbaar met het type module dat Linux gebruikt voor stuurprogramma's, bestandssystemen, enzovoort. Realtime taken hebben directe toegang tot de hardware en maken geen gebruik van virtueel geheugen. Bij initialisatie informeert een realtime taak (module) de RTLinux-kernel over zijn deadline, periode en releasetijdbeperkingen.

Draden

RT-Linux implementeert een POSIX API voor de manipulatie van een thread. Een thread wordt gemaakt door de pthread_createfunctie aan te roepen . De derde parameter van pthread_createis een functie die de code bevat die door de thread wordt uitgevoerd.

Het is noodzakelijk om threadprioriteiten in RTLinux in te stellen. Discussies met hogere prioriteiten kunnen voorrang hebben op discussies met lagere prioriteiten. We kunnen bijvoorbeeld een schroefdraad hebben die een stappenmotor bestuurt. Om de motor vloeiend te laten bewegen, is het noodzakelijk om deze draad met strikt regelmatige tussenpozen te starten. Dit kan worden gegarandeerd door een hoge prioriteit toe te kennen aan deze thread. Het voorbeeld threads2.c stelt verschillende threadprioriteiten in. Het instellen van threadprioriteit wordt gedaan door de onderstaande code: 

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");
...
}

De output van het programma is als volgt. 

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

De draad 2 heeft de hoogste prioriteit en de draad 3 heeft de laagste prioriteit. Het eerste bericht wordt afgedrukt door thread 1 met middelste prioriteit omdat het kort voor thread 2 wordt gestart.

Zie ook

Referenties

bronnen

Externe links