hi Leute,
bedingt durch einen Raspberry pi bin ich etwas mit Linux konfrontiert.
Ich habe das auch etwas als Teil des Abenteuers eingeplant, aber auch
unterschätzt wie viele Fragen und Probleme da bei den Basics auftauchen.
Tut mir bitte den Gefallen, macht den Thread nicht kaputt durch
Vergleiche mit andereen OS oder euren persönlichen Linux Traumata...oder
euren Windows Erfahrungen oder Haßfiguren.
Es wird auch noch vielleicht einen thread geben über das ominöse
x-server, hier aber generell Treiber.
Was mir auffiel: in /dev kann ich mir alle mögliche Hardware angucken.
z.B. zig Uarts oder Usb Ports. Wenn ich den befehl lsmod ausführe, kann
ich mir angucken, welche Treiber eigentlich geladen wurden. Meine Frage
ist: woher kommt die Hardware die in /dev gelistet ist. ALLES was
denkbar ist foindet sich dort ja nicht. Wenn ich aber z.B. ein Display
am Display Cponnektor des pi anschließe erscheint dort ein /dev/FB.
Richtig?
Und woher weiß der Computer eigentlich was für ein Treiber zu einer
aktuell gefundenen Hardware gehört.
Das ist kurz gefragt und möglicherweise peinlich - ist aber nicht zu
ändern ich verstehe es nicht, auch wenn es generell ein Thema ist.
Gruß und bis bald
Linux-Einsteiger schrieb:> Und woher weiß der Computer eigentlich was für ein Treiber zu einer> aktuell gefundenen Hardware gehört.
Ich interpretiere das jetzt mal als Frage.
Jede Komponente im PC ist standardisiert. Und sowohl PCI als auch USB
haben eine eindeutige Kennung vorgeschrieben. Auch bekannt als Vendor ID
und Product ID (VID&PID).
Diese kennung steht auch im Treiber, damit ist der eindeutig einem Gerät
zuordenbar.
Moin, -
Linux-Einsteiger schrieb:
Willkommen in der wunderbaren Welt von Linux. Linux ist
benutzerfreundlich, aber selektiv was Freunde sind.
Treiberlinge sind (m.E.) das komplexeste Problem in einem
Betriebssystem: Verbindet die Probleme der Hardware mit der Hardware des
Systemes. Auch die Unterscheidung von Block/Char-Devices ist auch nicht
offensichtlich.
Allerdings ist das alles gut dokumentiert, unter
https://www.kernel.org/doc/html/latest/driver-api/driver-model/index.html
findest Du alles.
Auf Deutsch findest Du:
Quada, Kunst: Linux Treiber entwickeln, 4.Auflage, 2016, d.punkt Verlag,
Heidelberg
Viele Gruesse
Th.
> Und woher weiß der Computer eigentlich was für ein Treiber zu einer> aktuell gefundenen Hardware gehört.> Das ist kurz gefragt und möglicherweise peinlich - ist aber nicht zu> ändern ich verstehe es nicht, auch wenn es generell ein Thema ist.
Da gibt es verschiedene Ansätze.
Grundsätzlich muss in der SW (das OS u. Gerätetreiber) eine Art
Teilabbild der Verdrahtung unter den Peripheriekomponenten
(Schaltungsschema des Computers, auch im Innern der Chips) zustande
kommen.
In einfachsten Fällen geschieht dies durch direktes eincodieren von
Registeradressen in die
SW. Das funktioniert aber nur (oder nur eingeschränkt) solange die
Verdrahtung fix unveränderbar bleibt (keine Steckkarten, kein USB) und
dieselbe SW nicht auf diversen Chips (SOCs, uC-Familie) laufen soll.
Eine weitere Variante ist dass beim Start des OS-Kerns dieser ein
Datenfile (oder etwas Vergleichbares) einliest, darin ist dann
'beschrieben' was für HW tatsächlich vorliegt, resp. der OS-Kern wird
dann nur jene Peripherie-HW in betrieb nehmen können (die passenden
Treiber laden) welche auch beschrieben ist.
Diese Beschreibung kann auch von der Computerfirmware dem OS-Kern
weitergereicht werden.
Altes, traditionelles PC-BIOS (s. 286, 386, ...) kann das nur minimal:
dazu hatte es Jumpers auf den Platinen und etwas musste per BIOS-Setup
eingestellt werden.
Zu Zeiten von 486 U. Pentium geschah dies üblicherweise durch
zurechtkonfigurieren und kompilieren (oder mindestens linken) der *nix
Kernels (Linux, *BSDs, ...). Das macht man heute allenfalls noch für
Embedded-Systeme um Festwert-&RAM-Speicher zu knausern UND Bootzeit
möglichst kurz zu halten.
Alte raffinierte Workstation-FW (Open Firmware IEEE-1275 auf DEC-Alphas,
Suns, PowerMacs ...) sah vor dass auf jeder Steckkarte ein (Flash-)ROM
die Steckkarten-HW-info in FORTH vorhielt, sodass die FW des Motherbords
dies unabhängig von CPU-Architektur Nutzen konnte.
Die Info zur Peripherie lässt sich auch mit etwas Vorwissen "erraten"
(neudeutsch: probing): an üblich verdächtigen Registeradressen wird
versucht mit der Peripherie zu sprechen und die Antwort wird
ausgewertet, passt die Antwort ist die Peripherie als vorhanden gemerkt
und der zugehörige Treiber wird geladen.
Solches Probing ist tlw. in den Treibern selbst enthalten: ein Treiber
wird geladen und allenfalls
antwortet er sinngemäss mit "HW antwortet nicht oder ist nicht
vorhanden".
Die ganze Info will natürlich im OS ordentlich verwaltet werden durch
entsprechende dynamische Datenstrukturen. Damit von "Plug'n'Play" nicht
nur das erste "Plug" funzt sonder auch abstöpseln und anderswo
einstöpseln ordentlich funktioniert, gerne auch währendem der Computer
zwischenzeitlich in den Ruhemodus versetzt wurde.
Wie oben bereits erwähnt: bei USB ist von Anfang an ein Vorgehen
standarisiert wonach jede Peripherie sich per VID:PID (+ggfs.
individuelle Seriennr. um mehrere Geräte vom selben Typ auseinander zu
halten und auch wenn sie umgestöpselt werden)
Halten sich USB-Gerätehersteller an standarisierte Geräteklassen, ist
nichtmal ein spezifischer Treiber nötig: der generische Gerätetreiber
dieser Geräteklasse kann das.
Ist die (USB-)Peripherie zu speziell / eine Sonderlocke, muss das OS
natürlich auf eine (riesige?) Bibliothek mit exakt passenden Treibern
zurückgreifen. Bringt das das OS nicht selbst mit, muss der
Gerätehersteller dies zum OS passend nachliefern. (will oder kann der
Hersteller nicht mehr, wird funktionierende HW obselet und hilft den
Müllberg zu vergrössern...)
Histerische Ergänzung: früher, als die /dev/* Dateien nicht dynamisch
erzeugt wurden, war deren Erstellung ein wesentlicher Teil der
OS-installation[1], resp. Aufgabe des Sytemadministrator solche Dateien
von Hand anzulegen wenn das Computersystem um Peripherie-HW erweitert
wurde.
[1] je cleverer die Installationsprogramme waren, geschah viel vom
o.erw. Probing zum Installationszeitpunkt, nicht bei jedem Systemstart.
Knoppix war eine der ersten (PC-)Linux-Distributionen welche das
(dynamische) Peripherieprobing auf die Spitzen trieb, gar bei Boot ab
CDROM (ohne Schreibzugriff!) und der Entwicklung von Linux und udev eine
ordentlichen Schub verpasste.
Man kann übrigens auch Treiber in den Kernel kompilieren, was natürlich
sehr sinnvoll ist, solange ein Zugriff auf Module noch nicht geht
(Massenspeicher, RAM, Konsole usw.) Der Kernel muss also zumindest die
Treiber enthalten, um ein Grundsystem 'aus dem Sumpf' zu ziehen.
Linux-Einsteiger schrieb:> Und woher weiß der Computer eigentlich was für ein Treiber zu einer> aktuell gefundenen Hardware gehört.
1. ACPI (nur PC) - ist Teil des BIOS.
2. PCI(e) - jedes Gerät hat einer Hersteller- und Typennummer. Man muss
nur alle PCIe Busse durchscannen und schauen, was man da findet.
3. USB-Geräte: Ähnlicher Mechanismus. Die USB-Controller selber sind
PCI(e) Geräte, werden also darüber gefunden
4. Device Tree (nicht PC). Das ist eine Textdatei, die ein System mit
seiner Hardware beschreibt. Die wird beim Booten mitgeladen und dann
ausgelesen.
Früher ab es noch so Sachen wie OpenFirmware bei Unix-Computern und
Macs, aber das ist inzwischen Geschichte und wäre oben nehben ACPI
einzuordnen.
fchk
Matthias S. schrieb:> Man kann übrigens auch Treiber in den Kernel kompilieren, was natürlich> sehr sinnvoll ist, solange ein Zugriff auf Module noch nicht geht> (Massenspeicher, RAM, Konsole usw.) Der Kernel muss also zumindest die> Treiber enthalten, um ein Grundsystem 'aus dem Sumpf' zu ziehen.
Das wird heute per initrd (initiale Ramdisk) erledigt, so können selbst
die Treiber für das root-filesystem per Modul geladen werden.
Matthias S. schrieb:> Man kann übrigens auch Treiber in den Kernel kompilieren, was natürlich> sehr sinnvoll ist, solange ein Zugriff auf Module noch nicht geht> (Massenspeicher, RAM, Konsole usw.) Der Kernel muss also zumindest die> Treiber enthalten, um ein Grundsystem 'aus dem Sumpf' zu ziehen.
Dafür gibt es initrd. Das ist eine RAM-Disk, die bereits vom Bootloader
in den RAM kopiert wird, bevor dann der Kernel gestartet wird. Da drin
sind dann die Treiber, die benötigt werden, damit der Kernel selbst auch
auf Laufwerke zugreifen kann, um den Rest des System laden zu können.
Das hat den Vorteil, dass im Linux-Kernel nicht gleich sämtliche Treiber
für alle erdenklichen Laufwerksschnittstellen und -typen sowie für
sämtliche Filesysteme, von denen es booten können soll, mit
einkompiliert sein müssen. Außerdem kann man in das initrd-Image noch
eine busybox mit einbauen, die gestartet wird, falls der Kernel kein
Bootlaufwerk findet. So hat man dann zumindest eine minimalistische
Umgebung, um nach den Problem zu suchen.
Das initrd-Image findet man üblicherweise im /boot-Verzeichnis zusammen
mit dem Kernel-Image.
