Sind Kernel Hardware spezifisch?

1

Nach meinem Verständnis stellt der Kernel die Verbindung zwischen Software und Hardware her, und daher muss der Kernel Systemaufrufe von Betriebssystemanwendungen leiten, richtig? Würden unterschiedliche E / A-Adresszuordnungen bedeuten, dass der Kernel anders programmiert werden muss? Lesen Sie weiter unten, da ich nicht glaube, dass ich diese Frage sehr genau formuliert habe.

Lassen Sie mich näher darauf eingehen, und korrigieren Sie mich bitte, wenn ich mich irre, da ich so verstanden habe, was in mehreren Artikeln angegeben wurde. Ich werde die x86-Familie als Basis für meine Beispiele verwenden. x86-Prozessoren verwenden den Befehl INT sowie einen Index namens Interrupt Vector Table, um eine INT-ID dem richtigen Speicherort der gewünschten Routine zuzuordnen (Routine und IVT im BIOS, richtig?). Die Routinen selbst sind so geschrieben, dass sie der für ein Computersystem spezifischen Hardware befehlen können, eine Aufgabe basierend auf dem Protokoll der verwendeten Hardware auszuführen. Auf diese Weise kann das Betriebssystem Systemaufrufe tätigen und mit der Hardware kommunizieren, ohne die systemspezifische Hardware oder E / A-Zuordnung zu kennen. Für die Kommunikation des Betriebssystems mit der Hardware ist lediglich die ID des gewünschten ISR erforderlich. Da der Kernel das Bindeglied zwischen Hardware und Software ist, müssen die Anwendungen, die vom Betriebssystem ausgeführt werden, nicht einmal die ISR-ID # kennen. Sie teilen dem Kernel einfach mit, dass sie beispielsweise Daten X auf die Festplatte schreiben möchten. Der Kernel leitet Daten X an den richtigen ISR weiter, der die Daten dann auf die Festplatte schreibt. Also würden zwei Systeme, die völlig identisch sind, außer dass sie unterschiedliche ISR-IDs für unterschiedliche Aufgaben verwenden, leicht unterschiedliche Kernel erfordern?

Und würde das auch bedeuten, dass der Bootsektor, der den Kernel lädt, auch von der Zuordnung der ISR-ID abhängt, da Systemaufrufe zum Lesen von der Festplatte erforderlich wären, um den Kernel zu laden?

Ich entschuldige mich, wenn dies am falschen Ort ist, aber ich habe gelesen, dass dies der richtige Ort für Hardware-bezogene Fragen ist. Vielen Dank!

Ki11akd0g
quelle
Noch in den neunziger Jahren wurden Unix-Kernel für jede Maschineninstallation konfiguriert und verknüpft. Der Trend bestand darin, entweder Plug-and-Play-Verfahren (selbstidentifizierende Hardware in Kombination mit selbstkonfigurierender Software) oder eine datengesteuerte Konfiguration (z. B. Gerätebaum) zu verwenden. Sie konzentrieren sich zu sehr auf Interrupts. Interrupts sind nur Leistungsverbesserer und für den Zugriff auf ein Gerät nicht unbedingt erforderlich. Um auf ein Gerät zuzugreifen, müssen Sie wissen Wie um darauf zuzugreifen (d. h. eine Methode), und woher dieses Gerät ist (d. h. seine Geräteadresse, die ein E / A-Port oder eine Speicheradresse sein kann).
sawdust
@sawdust Ich verstehe einfach nicht, wie sich ein Gerät ohne irgendeine Art von Hardware-Schnittstellenprotokoll selbst identifizieren kann. Wenn ich eine SD-Karte an einen Z80 anschließen würde und ich diejenige wäre, die sie verkabelt, könnte ich sie so einrichten, dass ein OUT 06h an io-Adresse 0002h den CS-Pin auf niedrig bringt und eine Übertragung initiiert, oder ich könnte es so konfigurieren dass ein OUT 03h an io Adresse 0002h eine Übertragung initiiert. Ja, das System kann einer SD-Karte eine Adresse von 0002h zuweisen, aber wie hätte es eine Idee zu wissen, dass ein OUT 06h oder 03h den Chipauswahl-Pin auf niedrig bringt und eine Übertragung initiiert?
Ki11akd0g
@sawdust Es sei denn, es werden Universalbusse verwendet, um alle Geräte zu verbinden, und die Busse haben alle die gleiche Pinbelegung. So werden beispielsweise die PCIe-Pins 0-31 den Pins 0-31 jedes angeschlossenen Gerätedatenbusses zugewiesen, unabhängig vom angeschlossenen Gerät. Wenn es tatsächlich so funktioniert, ist das durchaus sinnvoll.
Ki11akd0g
Sie haben ein schreckliches Beispiel ausgewählt. Eine SD-Karte identifiziert sich nicht selbst und ist eher ein Medium als ein Peripheriegerät. Das Gerät, mit dem die CPU kommunizieren würde, wäre ein MMC-Controller, nicht die SD-Karte selbst. Erfolgreiche Plug-n-Play-Schemata sind solche, die einen Peripheriebus wie PCI und USB verwenden. Das Verfahren zum Identifizieren von an den Bus angeschlossenen Peripheriegeräten ist Bestandteil des Busprotokolls. Also ja, da muss es sein "Eine Art Hardware-Schnittstellenprotokoll" .
sawdust
Ihr Fokus auf x86-PC-Hardware verzerrt Ihr Verständnis. Seit dem ersten Tag hat der IBM-PC seine Konfiguration standardisiert, und PC-Klone haben sich daran gemacht, das zu etablieren Wintel Standard von Computern. ARM-Prozessoren, die in mobilen Geräten und SBCs zu finden sind, weisen keinerlei Standardisierung der Systemkonfiguration auf und wurden von einem Kernel-Build für jede Board- / Maschinenvariante geplagt. Erst mit der Einführung von Device Trees für ARM Linux war Linux-Distribution für ARM-Boards möglich.
sawdust

Antworten:

1

Bezüglich der INTh-Befehle, auf die Sie verweisen (siehe: BIOS-Interrupt-Aufrufe ), Sie haben Recht, dass dies die Art und Weise war, wie ein Betriebssystem auf Low-Level-Hardware zugreift. In einer modernen Maschine landen diese Aufrufe (sofern sie ausgeführt werden) häufig im CSM (Compatibiliy Support Module, zumindest in der AMI-Sprache), das diese Anforderungen verarbeiten kann. In dem Fall eines Video-BIOS-Aufrufs, der den Code im Video-BIOS ausführen würde, falls vorhanden. Ich habe mit Intel IGPs als BIOS-Entwickler zusammengearbeitet, und als Teil des endgültigen Images hatten wir ein Tool von Intel, mit dem wir das Video-BIOS als Blob einbrennen.

Ebenso kann das BIOS "emulierte" Versionen von Aufrufen zum Lesen / Setzen der RTC implementieren. Ein modernes Betriebssystem wird einfach nicht alle dieser älteren Handler ausführen, da es nicht erforderlich ist, sich für diese Unterstützung auf das BIOS zu stützen. Beispielsweise gibt es möglicherweise einen Kerneltreiber, der weiß, wie man direkt mit Ihrem PCH kommuniziert, um sich mit dem zu messen RTC-Einstellungen.

Wie Sie sich vorstellen können, ist dies sehr, sehr langsam und wird von moderner Software nicht mehr verwendet. Stattdessen verfügt das Betriebssystem über die erforderliche Hardware, um eine Abstraktionsschicht bereitzustellen, die es grafischen Anwendungen ermöglicht, die GPU-Treiber zum Ausführen dieser Aufgaben zu verwenden. Dieses Gerät ist natürlich normalerweise PCIe von einem SW-POV und ist speicherabgebildet.

Wenn Sie sich den Linux-Speicherstapel unten ansehen, werden Sie feststellen, dass die zugrunde liegenden Kernel-Laufwerke sich darum kümmern, mit der Hardware zu kommunizieren, ohne das BIOS zu verwenden - der gesamte ausgeführte Code stammt aus Ihrem Kernel.

enter image description here

Denken Sie nun in Bezug auf verschiedene E / A-Adresszuordnungen und dergleichen daran, dass x86 sowohl einen E / A-Adressraum als auch einen Speicheradressraum hat. Wenn Sie sich an Plug-and-Play erinnern, durchläuft Ihr BIOS beim Hochfahren den PCI-Gerätebaum, der bei modernen Systemen im Grunde alle Ihre Peripheriegeräte umfasst, zumindest von einem SW-POV aus (dh der DRAM-Controller sitzt darauf) PCIe Bus 0, Ihre USB-Controller sind PCI-Geräte von einem SW-POV usw.). Unter Verwendung der BARs (Base Address Register) weiß das BIOS, wie viel Speicher und welchen Typ das Zielgerät haben möchte, und es wird sein Bestes tun, um die Anforderung zu erfüllen.

Die endgültige Zuordnung wird bei Übergabe an das Betriebssystem übergeben, und es kann sich dafür entscheiden, dies zu respektieren oder eine eigene Aufzählungsphase durchzuführen. Linux hat beispielsweise "Macken", die Sie vor dem Booten des Betriebssystems auf bestimmte PCI - Geräte - IDs anwenden können, und Sie können sich an Kernel - Bootparameter erinnern, die sich auf die Speicherzuweisung, die IRQs usw. auswirken können .

Krunal Desai
quelle
Ich versuche eigentlich nur, Retro-Computersysteme zu verstehen, bevor ich versuche, die modernen Systeme zu verstehen. Also war ich auf BIOS ISR korrekt? Wenn beispielsweise auf einem System, auf dem Unix aus den 70er Jahren ausgeführt wird, der Systemaufruf "read" ausgeführt wird, bestimmt der Kern die gewünschte Routine auf der Grundlage der Systemaufruftabelle, springt dann zur Routine (aus der Systemaufruftabelle) und führt sie aus gewünschte Adresse, die von der Anwendung auf der Grundlage der Interrupt-Vektortabelle in die richtige BIOS-Routine eingelesen werden soll? Das BIOS würde dann die gelesenen Daten an den Kernel zurücksenden, der die gelesenen Daten an die App weiterleiten würde.
Ki11akd0g