hi, habe vor kurzem eine neue festplatte in meinen PC eingebaut und dann windows NT zusätzlich zu meinem RedHat 9 draufinstalliert. wollte dann auf die NTFS Platte zugreifen. ok, ich habe den NTFS treiber nicht in meinem kernel, also muss ich ihn neukompilieren. habe aber dummerweise mein .config - file nicht mehr. gibt es da eine Möglichkeit den ntfs treiber einzeln (als modul)zu kompilieren, anstatt gleich den ganzen kernel neu zu erstellen?(ps ich habe inzwischen das NTFS-Linux projekt gefunden und den treiber für meinen kernel single runtergeladen, aber wenn mir sowas nochmal passiert, wäre es gut zu wissen, wie ich da schnell und einfach rumkommen(habe nämlich zu hause im moment kein Internet, kann also nicht immer einfach so suchen)
thx schoma
Linux 15.070 Themen, 107.540 Beiträge
schau mal nach, ob eine datei
/proc/config.gz
existiert. die kannst du entpacken und verwenden.
ausserdem, wenn dein system sauber konfiguriert ist, müsste sowieso eine datei
/boot/config-kernelversion
existieren.
beide dateien sind korrekte config-files deines aktuellen kernels.
Ja , es sollte gehen, den NTFS Treiber als Modul zu compilieren.
die frage ist aber, ob es auch einzeln, d.h. ohne den rest des kernels zu kompilieren, auch geht? das glaube ich eigentlich eher weniger
Probieren geht über studieren ! Es gab irgendeine Option mit der der Kernel compiliert werden muss, so daß beim nachinstallieren/compilieren von Modulen der Kernel nicht nochmals selbst compiliert werden muss.
Es reicht dann ggf. ein make modules und make modules_install !
Man kann eigentlich bei vielen Treibern entscheiden ob man den Treiber monolitisch in den Betriebsystemkern vmlinuz (oder bZImage) oder als Treibermodule kompilieren kann. Alle Treiber die direkt beim Booten gebraucht werden müssen monolitisch in den Kern kompiliert werden. Die Treiber die man nur gelegentlich braucht, können als Treibermodul meistens kompiliert werden. Da aber das Treibermodul auch ein interner Treiber ist (z.B für NTFS), muß auch der Betriebsystemkern neu kompiliert werden. Das Treibermodul soll während der Laufzeit in den Kern (in den Speicherbereich des Kerns) geladen werden.
Ich weiß nicht genau wie das funktioniert. Ich denke mal das ein Treibermodul ein kompiliertes Objectmodule ist, das zum laufenden Kern hinzugelinkt wird (weiß ich nicht genau). Deshalb muß dem Betriebsystemkern das Treibermodul "bekannt" sein, damit der Programmcode des Kerns mit dem Programmcode des Modules zusammenarbeiten.
Bei suse ist das nicht schwer. Einfach in das Verzeichnis /usr/src/linux gehen und als root den Befehl "make menuconfig" eingeben. Danach wird menügeführt die Konfiguration des Kerns , der monolitischen Treiber und Treibermodule durchgeführt.
Bei Red Hat wird das auch irgendwie gehen.
Beim XServer von nVidia wird nur ein Kernelinterface kompiliert (Laut Readme-Datei). Da muß nicht der ganze Kern neu kompiliert werden. Ob das auch bei so einem Treiber für NTFS geht würde mich auch mal interessieren. Denn normalerweise müssen mehr Anpassungen vorgenommen werden um einen Treiber, der nicht zur Distribution gehört, in den Betriebsystemkern zu integrieren, ob nun als modularer oder monolitischer Treiber. Ich kenne mich leider mit dem Betriebsystemkern von Linux nicht richtig aus.
Fakt ist aber: zb bei meiner Soundkarte (und auch bei meiner WLAN karte) sind treiber mitgeliefert, die man zu beliebigen zeitpunkten kompilieren und mit insmod in den kernel laden kann. ps wie das mit den treibern funktioniert:
jeder treiber hat eine art API, er verhält sich also ungefähr so wie eine DLL unter windows. dabei ist es letztlich egal, was für ein gerät angesprochen wird, weil der kernel um daten an das gerät zu senden nur die Funktion zb write() anspricht, der treiber kümmert sich um den restes ist also egal ob man daten zu einer soundkarte, einer netzwerkkarte oder einer Festplatte schreiben will.(oder lesen). das problem dabei ist eben, dass die kernelmodule, die mitgeliefert werden nicht über ein eigenes Makefile verfügen, das dann auch beim kompletten neukompilieren einfach nur aus der hauptmakefile aufgerufen wird. theoretisch müsste es also auch gehen das makefile solange zu durchforsten bis man auf die Stelle kommt, an der in das Verzeichnis fs/ntfs gewechselt wird, den code separiert (bis das fs/ntfs verzeichnis verlassen wird). dann müsste es im prinzip auch funktionieren. ist halt ein extremes stück arbeit, weil das kernelmakefile extrem umfangreich ist.
Von einer Art API habe ich keine Ahnung. Mir ist nur bekannt das die Gerätedateien eine wichtige Rolle spielen. In den Gerätedateien im /dev - Verzeichnis stehen immer eine Haupt- und eine Nebengerätenummer. Mithilfe der Gerätenummern wird dann der entsprechende Treiber ausgewählt. Wie das funktioniert weiß ich nicht, aber nur die Makefiles anzupassen wird nicht reichen.
Die Hauptgerätenummer legt den Type des Gerätes fest ,z. B. Diskettenlaufwerk und die Nebengerätenummer spezifiziert das noch, z. B 3,5" - Laufwerk.
Ich habe echt keine Ahung von Systemprogrammierung.
Da gibt es vielleicht schon passende Schnittstellen. Wenn man ein Programm modular programmiert, dann werden auch nur die veränderten Programmmodule nochmal neukompiliert (Objectcode) und zum Schluß die neueren und die alten Objectmodule zu der neuen ausführbaren Programmdatei neu gelinkt. Es wird nicht immer das ganze Programm neu kompiliert.
Beim Betriebsystemkern stelle ich mir das auch so vor:
Wenn schon ein Treiber im Kern drinnen war, dann braucht nur der neue Treiber kompiliert werden und zum Schluß der ganze Betriebsystemkern neu gelinkt werden. Aber da müssen schon passende "Schnittstellen" oder "Symbole" für den "Linker" dagewesen sein.
Von Systemprogrammierung habe ich keine Ahnung.
