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.
Die device nodes werden von Kernel Modulen registriert & bereitgestellt, und dann von udev dafür eine Datei in dev angelegt: https://stackoverflow.com/questions/5970595/how-to-create-a-device-node-from-the-init-module-code-of-a-linux-kernel-module#answer-5973426 Wie genau die Module der Kernel udev entscheidet, wann / ob sie geladen werden müssen, weiss ich nicht, da dürfte es mehrere Mechanismen geben. Es ist auch nicht jedes Modul ein Treiber für eine reale Hardware.
> 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.
Um die Verwirrung komplett zu machen: Nicht jedes laufende HW-Device mit Treiber muss in /dev auftauchen, zB. Netzwerk-Devices.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.