Die ganze Wahrheit über RTOS. Artikel 6. Andere RTOS-Dienste

In früheren Artikeln haben wir die Funktionalität des Kernels im Hinblick auf die ausgeführten Aufgaben und die Interaktion zwischen ihnen erörtert. In diesem Artikel sehen wir uns an, was der Kernel sonst noch tun kann, was sich größtenteils in einer Reihe anderer verfügbarer API-Aufrufe manifestiert. Wir werden auch die Frage beantworten, was den Kernel in ein Betriebssystem verwandelt.

Frühere Artikel in der Reihe:
Artikel 5. Aufgabeninteraktion und Synchronisation
Artikel 4. Aufgaben, Kontextwechsel und Interrupts
Artikel 3. Aufgaben und Planung
Artikel 2. RTOS: Struktur und Echtzeitmodus
Artikel 1. RTOS: Einführung.

Aufgabenverwaltung

Zusätzlich zur Aufgabenplanung und Interaktion zwischen ihnen enthält das RTOS Funktionen (API-Aufrufe) zum Verwalten von Aufgaben auf verschiedene Arten. Betrachten wir einige Möglichkeiten.

Aufgaben erstellen und löschen

Im "dynamischen" RTOS gibt es Funktionsaufrufe, mit denen Sie Aufgaben (und andere RTOS-Objekte) erstellen können, wenn sie benötigt werden. Solche Aufrufe umfassen eine Vielzahl von Parametern, die die Aufgabe definieren, z. B. Einstiegspunkt, Stapelgröße und Priorität. Mit dem entsprechenden API-Aufruf zum Entfernen von Aufgaben können Sie Ressourcen freigeben, nachdem die Aufgabe abgeschlossen wurde.

Im "statischen" RTOS werden die definierenden Parameter der Aufgabe während der Montage in einer Art Konfigurationsdatei konfiguriert.

Halten Sie an und setzen Sie eine Aufgabe fort

Wie wir gesehen haben, haben die meisten RTOS das Konzept eines „suspendierten“ Aufgabenzustands. Dies kann auf verschiedene Arten erreicht werden. Eine davon ist ein expliziter Aufruf der Suspend Task API-Funktion. Es kann durch sich selbst oder eine andere Aufgabe verursacht werden. Mit dem entsprechenden Aufruf "Aufgabe fortsetzen" kann die Aufgabe erneut für die Planung in die Warteschlange gestellt werden.

Task-Ruhezustand

Für ein Echtzeitsystem ist die Zeitsteuerung eine wichtige Anforderung und kann verschiedene Formen annehmen. Eine einfache Ansicht ist die Fähigkeit der Aufgabe, "einzuschlafen", dh die Aufgabe wird für einen bestimmten Zeitraum angehalten. Wenn die Zeit abgelaufen ist, wird die Aufgabe „aufgeweckt“ und erneut für die Planung in die Warteschlange gestellt. Zu diesem Zweck steht normalerweise ein API-Aufruf zur Verfügung. Diese Funktionalität hängt natürlich von der Verfügbarkeit des Timers ab.

Befreiung

Bei Verwendung des Round Robin-Schedulers ("Karussell") kann eine Aufgabe die Steuerung des Prozessors für die nächste Aufgabe in der Kette verweigern. Zu diesem Zweck steht die API-Funktion „Release Task“ zur Verfügung. Die Aufgabe wird nicht angehalten, sie steht für die Planung zur Verfügung, wenn sie an die Reihe kommt. Bei Verwendung des Zeitscheiben-Schedulers kann eine Aufgabe einen Teil ihres Zeitintervalls freigeben, wenn sie nicht sofort wichtige Aufgaben zu erledigen hat. Das Freigeben einer Aufgabe hat keine logische Bedeutung, wenn der Planer "Ausführen bis zum Abschluss" oder "Priorität" ausgeführt wird.

Aufgabenerfüllung

In einem früheren Artikel haben wir festgestellt, dass das RTOS zusätzlich zu den Zuständen "Bereit" oder "Angehalten" andere Aufgabenzustände unterstützen kann. Die Aufgabe kann "Abgeschlossen" sein, was bedeutet, dass ihre Hauptfunktion gerade noch übrig ist: Es ist kein spezieller API-Aufruf erforderlich. Eine Aufgabe kann "Beendet" werden. Dies bedeutet, dass sie nicht für die Planung verfügbar ist und zurückgesetzt werden muss, um wieder zum Starten verfügbar zu sein. Siehe "Zurücksetzen einer Aufgabe" weiter unten. Dies erfordert einen speziellen API-Aufruf. Die Verfügbarkeit dieser zusätzlichen Taskzustände, die verwendete Terminologie und ihre genauen Definitionen unterscheiden sich je nach RTOS.

Task zurückgesetzt

Viele RTOS bieten einen Aufruf der API-Funktion "Task zurücksetzen" an, mit der Sie die Task in ihren ursprünglichen Zustand zurückversetzen können. Sie befindet sich möglicherweise in einem angehaltenen Zustand und muss die Funktion „Aufgabe fortsetzen“ ausführen, um sich für die Planung in die Warteschlange zu stellen.

Prioritätsaufgaben usw.

In einem „dynamischen“ RTOS stehen möglicherweise API-Aufrufe zur Verfügung, um mehrere Taskparameter zur Laufzeit zu konfigurieren. Beispiele sind Priorität und Zeitintervalldauer.

Systeminformationen

In RTOS wird es eine Reihe von API-Aufrufen geben, um dem System Informationen über die Aufgabe bereitzustellen, darunter:
Informationen zu den Aufgaben . Wie viele Aufgaben befinden sich im System, ihre Konfiguration und der aktuelle Status.
Informationen zu anderen Kernelobjekten. Wie viele Objekte jedes Typs befinden sich im System, ihre Konfiguration und Informationen zum aktuellen Status. Zum Beispiel:

• Was ist die aktuelle Kapazität der Warteschlange? Kann ich weitere Nachrichten hinzufügen?
• Wie viele Aufgaben werden an einem bestimmten Postfach angehalten?

Informationen zur RTOS-Version . Ein API-Aufruf kann ähnliche Daten bereitstellen.

Speicherzuordnung

In vielen Anwendungen ist es wichtig, dass das Programm bei Bedarf dynamisch Speicher erfassen und freigeben kann, wenn er nicht mehr benötigt wird. Das gleiche passiert in der Firmware. Herkömmliche Ansätze sind jedoch anfällig für Probleme, die in Desktopanwendungen unwahrscheinlich oder unpraktisch sind, für ein eingebettetes System jedoch katastrophal sein können. Trotzdem gibt es Möglichkeiten, solche Dienste auch in einem statischen RTOS zu implementieren.

Probleme mit den Funktionen malloc () und free ()

In einem Desktop-C-Programm kann eine Funktion malloc () aufrufen, um anzuzeigen , wie viel Speicher benötigt wird, und einen Zeiger auf den Speicherbereich zurückerhalten. Mit Speicher kann es durch Aufrufen von free () freigegeben werden. Der Speicher wird aus einem Bereich namens Heap zugewiesen. Das Problem bei diesem Ansatz besteht darin, dass bei einer unkoordinierten Folge von Aufrufen dieser Funktionen der Heap-Bereich leicht fragmentiert werden kann und die Speicherzuweisung auch dann fehlschlägt, wenn genügend Speicher verfügbar ist, weil angrenzende Bereiche sind nicht groß genug. Einige Systeme (wie Java und Visual Basic) verwenden zur Defragmentierung ausgefeilte "Garbage Collection" -Schemata. Das Problem ist, dass diese Schemata zu erheblichen unvorhersehbaren Verzögerungen bei der Laufzeit führen können und dass indirekte Zeiger verwendet werden müssen (was in C nicht funktioniert).

Wenn malloc () und free () reentrant implementiert wurden (normalerweise nicht) und von den RTOS-Tasks verwendet wurden, tritt eine Fragmentierung sehr schnell auf und ein Systemausfall ist fast unvermeidlich. In C ++ gibt es neue und gelöschte Operatoren, die im Allgemeinen dieselben Funktionen wie malloc () und free () ausführen. Sie unterliegen denselben Einschränkungen und Problemen.

Abschnitte des Gedächtnisses

Um ein Echtzeitsystem mit dynamisch zugänglichem Speicher bereitzustellen, kann ein Blockansatz für die Speicherverwaltung verwendet werden. Solche Blöcke werden üblicherweise "Partitionen" genannt; Partitionen können aus dem "Partitionspool" zugeordnet werden.

Der Partitionspool enthält eine bestimmte Anzahl von Blöcken, von denen jeder dieselbe Größe hat. Die Anzahl und Größe der Blöcke in einer Partition wird beim Erstellen des Partitionspools festgelegt. Dies kann dynamisch sein, wenn das System dies zulässt, oder statisch während der Montage. In der Regel kann eine Anwendung mehrere Partitionspools enthalten, die Blöcke unterschiedlicher Größe anbieten.

Wenn eine Aufgabe Speicher benötigt, ruft sie eine API auf, die einen Block aus einem bestimmten Pool anfordert. Wenn dieser Aufruf erfolgreich ist, erhält die Task einen Zeiger auf den ausgewählten Block. Wenn der Anruf fehlschlägt, weil Im angegebenen Pool sind keine Partitionen verfügbar. Die Aufgabe erhält möglicherweise eine Fehlerantwort. Alternativ kann die Aufgabe blockiert (angehalten) werden, bis eine andere Aufgabe den Block im Abschnitt freigibt.

In der Regel übergibt eine Task einfach einen Zeiger auf einen Speicherblock in einem Code, der den Block verwendet. Dies führt zu einem Problem, wenn der Block nicht mehr benötigt wird. Wenn der Code nur einen Zeiger auf einen Block hat, wie kann er dem RTOS über einen API-Aufruf mitteilen, aus welchem ​​Partitionspool Speicher freigegeben werden soll? Die Antwort ist, dass die meisten RTOS zusätzliche Daten in einem dedizierten Block unterstützen (normalerweise ein negativer Versatz vom Zeiger), die die erforderlichen Informationen liefern. Um die API aufzurufen, um einen Block freizugeben, ist daher nur seine Adresse erforderlich.

Der folgende Artikel enthält weitere Informationen zu Speicherpartitionen.

Zeit

Die mit der Verwendung und Steuerung der Zeit verbundene Funktionalität ist wahrscheinlich im Echtzeitbetriebssystem verfügbar. Die Möglichkeiten variieren je nach RTOS, wir werden jedoch öffentlich zugängliche berücksichtigen. In jedem Fall ist der Echtzeit-Timer ein unverzichtbares Element für das Funktionieren eines dieser Dienste.

Systemzeit

Eine einfache Systemzeit oder "Clock Timer" ist fast immer verfügbar. Dies ist nur ein Zähler (normalerweise 32 Bit), der mithilfe der Echtzeit-Interrupt-Serviceroutine inkrementiert wird und über API-Aufrufe gesetzt und gelesen werden kann.

Service Call Timeouts

In der Regel ermöglicht ein RTOS das Blockieren von API-Aufrufen, dh die aufrufende Task wird angehalten (blockiert), bis der angeforderte Dienst bereitgestellt wird. Normalerweise ist diese Sperre vage, aber einige RTOS bieten eine Zeitüberschreitung an, während der der Anruf zurückgegeben wird, wenn die Zeitüberschreitung abläuft, wenn der Dienst weiterhin nicht verfügbar ist. API-Aufrufzeitlimits werden nicht von allen RTOS unterstützt.

Task-Ruhezustand

In der Regel können sich Aufgaben für einen festgelegten Zeitraum pausieren. Dies wurde weiter oben im Abschnitt Aufgabenverwaltung erläutert.

Software-Timer

Damit Programmaufgaben Zeitzählfunktionen ausführen können, bieten die meisten RTOS Timer-Objekte an. Dies sind unabhängige Timer, die vom Echtzeit-Timer-Interrupt-Handler aktualisiert werden und durch API-Aufrufe gesteuert werden können. Solche Aufrufe konfigurieren, überwachen und überwachen den Betrieb des Timers. In der Regel können sie für eine einzelne Betätigung oder einen automatischen Neustart eingestellt werden. In der Regel wird auch eine Ablaufroutine unterstützt, eine Funktion, die jedes Mal ausgeführt wird, wenn ein Timer einen Zyklus abschließt. Der nächste Artikel enthält weitere Informationen zu Software-Timern und eine Beschreibung ihrer Implementierung.

Interrupts, Treiber und E / A.

Das Ausmaß, in dem RTOSs mit Interrupts und E / A verbunden sind, ist sehr unterschiedlich. Ebenso haben einige RTOSs eine sehr klare Struktur für Gerätetreiber, was zu Problemen bei der Auswahl eines bestimmten Produkts führen kann.

Unterbrechungen

Interrupts stellen aus zwei Gründen ein Problem für RTOS dar.

• Ohne Vorsichtsmaßnahmen „stiehlt“ der Interrupt-Handler (ISR) die Prozessorzeit und stört dadurch das Echtzeit-RTOS-Verhalten.
• Wenn der ISR API-Aufrufe ausführt, die sich auf die Aufgabenplanung auswirken, sollte dies überwacht werden, und das RTOS sollte in der Lage sein, seinen Planungsalgorithmus auszuführen.

Ein Beispiel für einen solchen API-Aufruf ist das Verfahren zum Aufwecken einer Aufgabe mit einer höheren Priorität als derjenigen, die zum Zeitpunkt des Interrupts gestartet wurde.

Einige RTOS steuern alle Interrupts vollständig. Eine Reihe von API-Aufrufen steht zur Verfügung, um ISR-Programme zu "registrieren". Dieser Ansatz ermöglicht es dem Scheduler, genau zu bestimmen, wann Interrupts aktiviert sind, und erleichtert die Verwendung der meisten API-Aufrufe vom ISR.

Zum Beispiel implementiert Nucleus RTOS das Konzept der Interrupt-Handler mit niedriger und hoher Priorität, die ein zuverlässiges Interrupt-Management ohne unnötigen Overhead (dh eine Erhöhung der Interrupt-Verzögerung) bieten.

Andere RTOS können den automatischen Hands-Off-Modus für Interrupts verwenden, der Entwicklern mehr Optionen bietet, um sicherzustellen, dass Interrupt-Handler ordnungsgemäß funktionieren. In der Regel werden zusätzliche ISR-Präfixe (Prolog) und Suffixe (Epilog) bereitgestellt, um darin ausgeführte API-Aufrufe zu schützen.
Nucleus SE verwendet eine einfache Interrupt-Routine, die in einem zukünftigen Artikel beschrieben wird.

Treiber

Die meisten RTOS bestimmen die Struktur des Gerätetreibers. Details können je nach RTOS variieren, aber der Treiber besteht normalerweise aus zwei interagierenden Komponenten: eingebettetem Code (API-Aufrufe) und ISR. In der Regel stehen andere API-Aufrufe zum Verwalten und Registrieren von Treibern zur Verfügung.

Eingabe / Ausgabe

Gegenwärtig interessieren sich die meisten RTOS auf dem Markt nicht für übergeordnete Ein- / Ausgabe, aber einige von ihnen definieren einen Eingabe- / Ausgabestream, der im Wesentlichen eine Verbindung zwischen den entsprechenden Gerätetreibern und Standardfunktionen der C-Sprache wie printf () herstellt.
In der Vergangenheit unterstützte das RTOS häufig die „Konsole“, die Benutzeroberfläche zum RTOS über einen seriellen Kanal. Dies wurde hauptsächlich für die Diagnose und das Debuggen verwendet. Durch die Verwendung moderner Debugger, die Debugging-Anwendungen mit RTOS unterstützen, sind solche Objekte nicht mehr erforderlich.

Diagnose

In der Regel erfordert RTOS maximale Leistung bei minimalem Speicherbedarf. Daher hat die Integritätsprüfung keine hohe Priorität. Mit Hilfe moderner Debugging-Technologien, die die Funktionen des RTOS berücksichtigen, können die meisten Überprüfungen außerhalb des RTOS selbst durchgeführt werden.

Überprüfen der API-Aufrufparameter

API-Aufrufe können viele komplexe Parameter haben. Dies kann zu Fehlern führen. Viele RTOS bieten eine Überprüfung der Laufzeitparameter mit der Rückgabe eines Fehlercodes im Falle eines falschen Parameters. Da dies zusätzlichen Code erfordert und die Überprüfungen selbst die Leistung beeinträchtigen, ist es besser, die Parameter während der Montage oder Konfiguration zu überprüfen.

Stapelprüfung

Für die meisten Arten von Schedulern (außer Run to Completion) verfügt jede Aufgabe über einen eigenen Stapel, dessen Größe individuell festgelegt wird. In einigen RTOSs verfügt der Kernel über einen separaten Stapel, in anderen wird der Taskstapel während eines API-Aufrufs „ausgeliehen“. Offensichtlich ist die Stapelintegrität für die Zuverlässigkeit des Gesamtsystems wichtig. Daher bieten RTOS häufig Tools zur Überprüfung der Stapelintegrität zur Laufzeit. Es gibt mehrere Möglichkeiten:

• Ein API-Aufruf, der den Stapelspeicherplatz für die aktuelle oder angegebene Aufgabe zurückgibt.
• Die Begrenzungsparameter des Stapels. Ihnen wird ein eindeutiger Wert (normalerweise ungerade und ungleich Null) zugewiesen, der regelmäßig auf Umschreiben überprüft wird.

Anwendungsdiagnose

Trotz der Tatsache, dass diese Funktion im RTOS nicht direkt unterstützt wird, kann eine Anwendungsaufgabe zur Überprüfung der Integrität des gesamten Systems zugewiesen werden. Eine solche Aufgabe kann für das Zurücksetzen des Watchdog-Timers verantwortlich sein. Eine Aufgabe kann periodische Eingabedaten (z. B. Signalparameter) von jeder kritischen Aufgabe empfangen. Das Zurücksetzen des Watchdog-Timers (wodurch ein Neustart des Systems verhindert wird) wird erst durchgeführt, nachdem Daten von allen Aufgaben eingegangen sind.

Nicht-Kernel-Dienste

Das RTOS ist mehr als nur der Kern, auf den wir uns bisher konzentriert haben. Dieses Desktop-Betriebssystem unterscheidet sich erheblich vom eingebetteten RTOS. In der Regel werden in einem Desktop-Betriebssystem alle zusätzlichen Komponenten gebündelt oder können installiert werden (alle Desktop-PCs verfügen über eine grafische Benutzeroberfläche, und nur wenige von ihnen haben keinen Netzwerkzugriff). Der Desktop-PC hat keine wirklichen Ressourcenbeschränkungen: Es gibt immer freien Speicher, Festplattenspeicher und nicht verwendete CPU-Ressourcen. In einer Welt eingebetteter Systeme mit begrenzten Ressourcen sind möglicherweise zusätzliche Komponenten wie Grafikkarten, Netzwerkkomponenten und Dateisysteme erforderlich, die jedoch trennbar und skalierbar sein müssen, um den Speicherbedarf zu minimieren.

Netzwerkfunktionen

Die meisten eingebetteten Systeme sind irgendwie mit Netzwerken verbunden. Es wird daher erwartet, dass ein erhebliches Interesse an Netzwerklösungen für eingebettete Systeme besteht, aufgrund derer eine große Anzahl von Produkten auf dem Markt ist.

TCP / IP ist ein weit verbreitetes Standardprotokoll, das für viele Anwendungen die offensichtliche Wahl ist. In der Regel wird TCP / IP für das Ethernet-Protokoll (IEEE802.3) verwendet, das eine durchschnittliche Geschwindigkeit von 10 Mbit / s bietet. Heutzutage sind 100 Mbit / s weit verbreitet und beim Ansatz 1 Gbit / s. Darüber hinaus kann TCP / IP für andere Protokolle verwendet werden. Beispielsweise ist PPP (Point-to-Point-Protokoll) eine TCP / IP-Implementierung für die serielle Datenübertragung, die für Breitband-Internetverbindungen angepasst wurde.

Bis vor kurzem wurde Version v4 des IP-Protokolls (IPv4) verwendet. Es wird jedoch veraltet, wenn freie Adressen ausgehen. Die Lösung ist IPv6, wodurch die Anzahl der möglichen Adressen erheblich erhöht und effizientere Tools für Wartung und Sicherheit bereitgestellt werden. IPv6 ist weit verbreitet und wird in Geräten vieler Länder sowie in militärischen Systemen auf der ganzen Welt verwendet.
Eine Alternative ist das User Datagram Protocol (UDP). Dieses Protokoll wird für maximale Leistung verwendet. UDP bietet nicht die gleiche Zuverlässigkeit und Konsistenz wie TCP, ist jedoch leicht und hocheffizient.

USB ist der Universal Serial Bus, der häufig in Geräten zum Anschließen an Desktop-Computer verwendet wird. Es bietet eine sehr einfach zu bedienende Plug-and-Play-Oberfläche, die ziemlich ausgefeilte Software verbirgt.Ein eingebettetes Gerät, das an einen PC angeschlossen werden muss, muss als USB-Funktion implementiert werden, für die ein bestimmter Satz von Softwarekomponenten erforderlich ist. Wenn das Gerät andere über USB angeschlossene Geräte (wie einen normalen PC) verwalten muss, benötigt es eine Reihe von Host-Software.

IEEE1394 ist ein weiterer Standard für serielle Schnittstellen, mit dem große Datenmengen schnell zwischen Geräten übertragen werden können (z. B. zum Übertragen von Videodaten), auch bekannt als FireWire und i.Link.

Drahtlose Protokolle - Die Bequemlichkeit und Verbreitung verschiedener drahtloser Technologien bei Verbrauchern hat zu einer hohen Nachfrage nach drahtlosen Funktionen in eingebetteten Geräten geführt. Wi-Fi (IEEE802.11-Standardsatz) bietet einen vollständigen Satz von Netzwerkfunktionen, mit denen Sie Peer- und Infrastruktur-Topologien in ausreichender Entfernung implementieren können. Das Interesse an Datensicherheit in solchen Netzwerken wächst, was bedeutet, dass dies Auswirkungen auf die Software haben sollte. Andere Funktechnologien, insbesondere Bluetooth und ZigBee, bieten Punkt-zu-Punkt-Funkkommunikation mit kurzer Reichweite.

Protokollüberprüfung

Da Networking-Möglichkeiten sehr gefragt sind, bieten viele Anbieter ihre Lösungen an. Kunden stehen vor der Herausforderung, die Qualität der verfügbaren Produkte zu überprüfen. Im Gegensatz zum RTOS-Kernel ist eine vollständige Überprüfung der Funktionalität und Leistung des Protokollstapels keine leichte Aufgabe. Glücklicherweise stehen Toolkits zur Überprüfung von Protokollen zur Verfügung (wenn auch zu einem erheblichen Preis), und ein potenzieller Käufer kann beim Lieferanten herausfinden, welches Set er zur Überprüfung verwendet hat.

Grafik

Eine grafische Oberfläche wird bei eingebetteten Geräten immer häufiger. Es kann sich um ein sehr einfaches, kleines monochromatisches LCD handeln (wie bei alten Telefonen, MP3-Playern, Alarmen usw.). Andererseits kann ein digitaler Fernsehempfänger einen eigenen hochauflösenden HDTV-Bildschirm haben. Ein solcher Bildschirm erfordert Softwareunterstützung, die vollständig in den RTOS-Kernel integriert ist.
Da der Bildschirm normalerweise über eine Art Eingabegerät verfügt, ist die Unterstützung für solche Geräte häufig im Grafikpaket enthalten. Ein solches Paket kann Zeigegeräte (z. B. eine Maus), Touchscreens, Tastaturen und vollständige Tastaturen unterstützen.
Grafiken können auf verschiedene Arten verwendet werden. Es kann einfach eine Informationsausgabe bereitstellen (z. B. wie eine elektronische Anzeigetafel). Oder die Anzeige kann zusammen mit Menüs, Fenstern, Symbolen und ähnlichen Elementen Teil einer grafischen Benutzeroberfläche sein. In jedem Fall ist ein ziemlich spezifischer Satz von Software erforderlich, und das mit dem RTOS gelieferte Grafikpaket sollte die erforderliche Flexibilität bieten, ohne die Menge des verwendeten Speichers wesentlich zu erhöhen.

Dateisysteme

Wenn eine eingebettete Anwendung erhebliche Datenmengen speichern und verarbeiten muss, ist es offensichtlich sinnvoll, diese Daten in einer Art Dateisystem zu organisieren. Daten können sich im RAM, im eingebauten Flash-Speicher, auf einem USB-Flash-Laufwerk, auf einer normalen Festplatte oder auf einer optischen Festplatte (CD-ROM oder DVD-ROM) befinden. Auch bei dieser Gelegenheit sollte die Softwareunterstützung vollständig in das RTOS integriert sein. Das Dateisystem muss sorgfältig entworfen werden, um die Wiedereintrittsanforderungen eines Multitasking-Systems zu erfüllen.

Compliance ist besonders wichtig für Dateisysteme. Die Verwendung des MS-DOS-kompatiblen Festplattenformats ermöglicht Entwicklern beispielsweise die Verwendung der etablierten Architektur und bietet einen umfassenden Datenaustausch mit Desktop-Systemen.