Ist die Hardware von Kernels spezifisch?

584
Ki11akd0g

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

Lassen Sie mich etwas näher erläutern, und korrigieren Sie mich bitte, wenn ich falsch liege, denn so habe ich verstanden, was in mehreren Artikeln erwähnt wurde. Ich werde die x86-Familie als Grundlage für meine Beispiele verwenden. x86-Prozessoren verwenden den INT-Befehl sowie einen Index, der als Interrupt-Vektortabelle bezeichnet wird, um eine INT-ID dem korrekten Ort der gewünschten Routine zuzuordnen (Routine und IVT im BIOS, richtig?). Die Routinen selbst sind so geschrieben, dass sie die für ein Computersystem spezifische Hardware anweisen können, eine Aufgabe basierend auf dem Protokoll der verwendeten Hardware auszuführen. Auf diese Weise kann das Betriebssystem Systemaufrufe durchführen und mit der Hardware kommunizieren, ohne Kenntnis der systemspezifischen Hardware- oder E / A-Zuordnung zu haben. Für die Kommunikation des Betriebssystems mit der Hardware ist lediglich die ID der gewünschten gewünschten ISR erforderlich. Da der Kernel das Bindeglied zwischen Hardware und Software ist, vermute ich, dass die Anwendungen, die vom Betriebssystem ausgeführt werden, nicht einmal die ISR-ID kennen müssen. Sie teilen dem Kernel lediglich mit, dass er beispielsweise Daten X auf die Festplatte schreiben möchte. Der Kernel leitet Daten X an die korrekte ISR weiter, die dann die Daten auf die Festplatte schreibt. Zwei Systeme, die völlig identisch sind, außer dass sie unterschiedliche ISR-IDs für unterschiedliche Aufgaben verwenden, würden etwas 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 der Festplatte erforderlich sind, um den Kernel zu laden?

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

1
Noch in den 1990er Jahren wurden Unix-Kernel für jede Maschineninstallation konfiguriert und verknüpft. Der Trend war, entweder Plug-and-Play-Schemata (selbstidentifizierende Hardware in Kombination mit selbstkonfigurierender Software) oder eine datengesteuerte Konfiguration (z. B. Gerätebaum) zu verwenden. Sie konzentrieren sich zu sehr auf Unterbrechungen. Interrupts sind nur Leistungsverbesserer und für den Zugriff auf ein Gerät nicht wesentlich. Um auf ein Gerät zuzugreifen, müssen Sie * wissen *, wie auf das Gerät zugegriffen werden soll (dh auf eine Methode), und * wo * dieses Gerät ist (dh seine Geräteadresse, die E / A-Ports oder Speicheradressen sein kann). ). sawdust vor 8 Jahren 0
Ich verstehe einfach nicht, wie ein Gerät ohne ein Hardware-Schnittstellenprotokoll selbst identifiziert werden kann. Wenn ich eine SD-Karte an eine Z80 anschließen würde und ich die Verkabelung war, könnte ich sie so einrichten, dass ein OUT 06h an die Adresse 0002h den CS-Pin auf einen niedrigen Wert bringt und eine Übertragung initiiert, oder ich könnte es so konfigurieren dass ein OUT 03h an die Adresse 0002h eine Übertragung einleitet. Ja, das System weist einer SD-Karte möglicherweise eine Adresse von 0002h zu. Wie kann es jedoch bekannt sein, dass ein OUT 06h oder 03h den Chip-Select-Pin auf einen niedrigen Wert bringt und eine Übertragung einleitet? Ki11akd0g vor 8 Jahren 0
@sawdust Wenn nicht Universalbusse zur Verbindung aller Geräte verwendet werden und die Busse alle die gleiche Pinbelegung haben. Die PCIe-Pins 0-31 werden also den Pins 0-31 jedes angeschlossenen Geräte-Datenbusses zugewiesen, unabhängig vom angeschlossenen Gerät. Wenn dies tatsächlich so ist, ist das völlig sinnvoll. Ki11akd0g vor 8 Jahren 0
Du hast ein schreckliches Beispiel gewählt. Eine SD-Karte identifiziert sich nicht selbst und ist eher ein Medium als ein Peripheriegerät. Das Gerät, mit dem sich die CPU verbinden würde, wäre ein MMC-Controller, nicht die SD-Karte selbst. Erfolgreiche Plug-and-Play-Schemata sind solche, die einen Peripheriebus wie PCI und USB verwenden. Das Verfahren zum Identifizieren von an den Bus angeschlossenen Peripheriegeräten ist ein integraler Bestandteil des Busprotokolls. Ja, es muss * ein "Hardware-Schnittstellenprotokoll" * geben. sawdust vor 8 Jahren 0
Ihr Fokus auf x86-PC-Hardware verzerrt Ihr Verständnis. Seit dem ersten Tag standardisierte der IBM PC seine Konfiguration, und PC-Klone folgten dem Beispiel, um den [Wintel] (https://en.wikipedia.org/wiki/Wintel) -Standard von Computern festzulegen. ARM-Prozessoren, die sich in mobilen Geräten und SBCs befinden, verfügen über keinerlei Standardisierung der Systemkonfiguration und wurden von einem Kernel-Build für jede Platinen- / Maschinenvariante geplagt. Erst mit der Einführung von Device Trees für ARM Linux waren Linux-Distributionen für ARM-Boards möglich. sawdust vor 8 Jahren 0
Lassen Sie uns [diese Diskussion im Chat fortsetzen] (http://chat.stackexchange.com/rooms/41786/discussion-between-ki11akd0g-and-sawdust). Ki11akd0g vor 8 Jahren 0

1 Antwort auf die Frage

1
Krunal Desai

Bezüglich der INTh-Befehle, auf die Sie sich beziehen (siehe: BIOS-Interrupt-Aufrufe ), ist es richtig, dass dies die Art war, auf die ein Betriebssystem auf Low-Level-Hardware zugreift. In einer modernen Maschine landen diese Aufrufe (sofern ausgeführt) häufig im CSM (Compatibiliy Support Module, zumindest in der AMI-Sprache), das diese Anforderungen verarbeiten kann. Bei einem Video-BIOS-Aufruf würde dies den Code im Video-BIOS ausführen, falls vorhanden. Ich habe mit Intel IGPs als BIOS-Entwickler gearbeitet, und als Teil des endgültigen Images hatten wir ein Tool von Intel, in dem wir das Video-BIOS als Blob backen.

Ebenso kann das BIOS "emulierte" Versionen von Aufrufen zum Lesen / Setzen des RTC implementieren. Ein modernes Betriebssystem führt einfach nicht alle diese veralteten Handler aus, da es für diese Unterstützung nicht auf das BIOS angewiesen ist. Beispielsweise gibt es möglicherweise einen Kernel-Treiber, der weiß, wie er mit Ihrem PCH direkt in Kontakt treten soll RTC-Einstellungen.

Wie Sie sich vorstellen können, ist das sehr, sehr langsam und wird von moderner Software nicht mehr verwendet. Stattdessen besitzt das Betriebssystem die erforderliche Hardware, um eine Abstraktionsschicht bereitzustellen, die es grafischen Anwendungen ermöglicht, die Treiber der GPU für diese Aufgaben zu verwenden. Dieses Gerät ist natürlich in der Regel PCIe aus einem SW-POV und ist speicherzugeordnet.

Wenn Sie sich den Linux-Speicherstapel unten ansehen, werden Sie ebenfalls feststellen, dass die zugrunde liegenden Kernellaufwerke sich mit der Hardware auskennen, ohne das BIOS zu verwenden. Der gesamte Code stammt von Ihrem Kernel.

In Bezug auf verschiedene E / A-Adresszuordnungen und dergleichen sei daran erinnert, 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 Booten den PCI-Gerätebaum, der für moderne Systeme im Wesentlichen alle Ihre Peripheriegeräte umfasst, zumindest von einem SW-POV (dh der DRAM-Controller ist eingeschaltet) PCIe-Bus 0, Ihre USB-Controller sind PCI-Geräte von einem SW-POV usw.). Mit den BARs (Base Address Registers) weiß das BIOS, wie viel Speicherplatz und welchen Typ das Zielgerät benötigt, und es tut sein Bestes, um die Anforderung zu erfüllen.

Das endgültige Mapping wird bei der Übergabe an das Betriebssystem übergeben, und es kann sich entscheiden, dies zu respektieren oder eine eigene Aufzählungsphase durchzuführen. Linux verfügt beispielsweise über 'Macken', die Sie vor dem Booten des Betriebssystems für bestimmte PCI-Geräte-IDs anwenden können, und Sie können die Kernel-Boot-Parameter zurückrufen, die sich darauf auswirken können, wie viel Speicher ihnen zugewiesen wird, welche IRQs sie verwenden, usw .

Ich versuche eigentlich nur Retro-Computersysteme zu verstehen, bevor ich versuche, die modernen Systeme zu verstehen. Also war ich auf BIOS ISR richtig? Wenn der Systemaufruf "Lesen" ausgeführt wurde, würde der Kernel beispielsweise auf einem System, auf dem Unix aus den 70er Jahren ausgeführt wird, die gewünschte Routine basierend auf der Systemaufruftabelle bestimmen, dann zu der Routine (von der Systemaufruftabelle) springen und diese ausführen, die die gewünschte Adresse, die von der Anwendung anhand der Interrupt-Vektortabelle in die richtige BIOS-Routine eingelesen werden soll? Das BIOS gibt dann die gelesenen Daten an den Kernel zurück, wodurch die gelesenen Daten an die App weitergeleitet werden. Ki11akd0g vor 8 Jahren 0