Welche Rolle spielt genau der "Kernel", wenn Anwendungsprogramme auf die Hardware zugreifen wollen?

2 Antworten

der Zugriff auf Hardware erfolgt ausschließlich über "Geräte" (device). Hinter einem Device (Gerät) verbirgt sich ein Programm, das mit Modul bezeichnet wird. (unter Windows sind das Treiber). Die Schnittstelle zwischen Anwenderprogramm und Hardware sind die Gerätedateien (normalerweise im Verzeichnis /dev ). Ein Anwenderprogramm schreibt oder liest Daten auf bzw. vom "Gerät". In Wirklichkeit erkennt der Kernel aber nur aus 3 Werten, die in so einer Gerätedatei (besser in deren Metadaten) enthalten sind, was und wie es zu tun ist. Diese 3 Werte sind die major- und die minor- Nummer und der Type . Diese Werte sind ausreichend, um genau das Programm aufzurufen, dass für die Ausführung des Auftrags notwendig ist.

Eine Ausnahme sind die CPIO-Schnittstellen. aber auch dort erfolgt der Datenaustausch über Dateien, also ohne direkten Zugriff auf CPU-Register oder andere Ding der Hardware.

Woher ich das weiß:Berufserfahrung – openSuSE seit 1995

Du hast quasi schon alles gesagt.

Ein Kernel ist der Kernteil des Betriebsystems.

Auf ihm laufen die Treiber.

Ein Anwendungsprogramm kann methoden aus diesem Kernel aufrufen...Der Kernel wandelt die Daten entsprechend um und schickt sie an die Hardware.

Außerdem kann auch Informationen von der Hardware eingelesen werden. Das funktioniert ähnlich...

Gibt es etwas spezifisches, das du wissen willst?


Sniprino 
Fragesteller
 16.03.2018, 14:00

Danke für deine schnelle Antwort!

Stimmt es das für die Kommunikation zwischen Hardware u. Applikation Linux vorgefertigte u. ausgetestete "System-Call"-Routinen bereit stellt, die bestimmten Restriktionen unterworfen sind, aber durch den Programmierer nach Bedarf individuell konfiguriert werden kann? Sprich, das es die Aufgabe eines "Kernels" ist wenn Anwendungsprogramme auf die Hardware zugreifen möchten?

0
KarlRanseierIII  16.03.2018, 17:07
@Sniprino

Ja, im Prinzip schon.

Ich nehme mal ein dummes BEispiel, eine Soundkarte. Für diese gibt es eine Pseudofile (eine spezielle Inode) im Dateisystem, ich kann diese Datei öffnen udn wenn ich den richtig formatierten Datenstrom in die Datei schreibe, kommt Klang aus der Soundkarte, zum Sampeln würde ich aus der Datei lesen.

Grundlegend lässt sich das bei jedem Gerät so ähnlich machen.

Du merkst aber schon, wo der Haken liegt: Wie mache ich das denn nun, daß z.B. meine Soundkarte das von mir gewünschte Format (Quantisierung und Samplerate) akzeptiert?

Hierfür gibt es spezielle Systemaufrufe, ioctls, die eben die Parametrisierung des Gerätes übernehmen.

Möchte ich zum Beispiel die Anzahl der Sektoren einer Festplatte (/dev/sda) ermitteln, dann öffne ich /dev/sda. Anschließend führe ich den entsprechenden IOCTL auf dem Filedescriptor aus und bekomme die Rückgabe. Die Kommunikation mit dem Geräte wird also durch eien definierte und überwachte Schnittstelle vollzogen.

Beispiel:

ioctl(3, BLKGETSIZE64, [1000204886016]) = 0

Der IOCTL BLKGETSIZE64 liefert die Anzahl der Sektoren des zugehörigen Blockdevice.

0