SuSE 9.1 - wo finde ich den "Linux Kernel Source Code"
hallo miteinander meine Frage steht in Zusammenhang mit SuSE-9.1, dem (selbst kompilierten) Kernel 2.6.4-52-default und dem AntiVir-Programm, (darin "avguard" und insbesondere "dazuko"). In der FAQ#10 von "www.dazuko.org" wird u.a. aufgezeigt : - - - - s n i p p 10. How do I configure my Linux kernel source code? [ . . .] make menuconfig (or) make xconfig Both configuration utilities do exactly the same thing. First, they read the contents of the .config file that is in the kernel source directory. After you choose "Save and Exit" all configuration information is saved in .config file but also in the include/linux/autoconf.h file where the settings are actually used during compilation. This means that the important file for compiling Dazuko is autoconf.h. However, most distributions do not keep a copy of the autoconf.h used when the kernel was compiled. Rather, they keep a copy of the .config file and save it as /boot/config-x.x.x. By copying this file over the .config file in the kernel source directory, then running the configuration utility and saving changes, you will have generated the autoconf.h that matches your kernel. This is what is meant by configuring the source code. Now Dazuko can be compiled and should insert properly into the kernel. Note: It is assumed that you have the kernel source code that matches your running kernel. It is also assumed that you have a /boot/config-x.x.x file that matches your running kernel. Please pay attention to version numbers. - - - - s n i p p 1) Ich habe nun festgestellt, dass (bei mir) allen Zeilen in " ./include/linux/autoconf.h" ein '#' vorangestellt ist. Ein Link von "/usr/src/linux/.config" -> ./autoconf.h führte beim Kompilieren von Dazuko zu Fehlermeldungen für alle aktiven Zeilen. Außerdem ist m.W. in der ".config"-Datei der Name des Kernels nicht genannt (nur teilweise erwähnt) - oder ? Ist denn in der ".config"-Datei wirklich der Source-Code? 2) Beim Erstellen der Module für Dazuko mit "make" wird u.a. folgendes angezeigt (auszugsweise): - - - - - s n i p p ro999:/usr/src/antivir-workstation-2.1.0/src/dazuko-2.0.2 # make make -C /lib/modules/2.6.4-52-default/build SUBDIRS= \ /usr/src/antivir-workstation-2.1.0/src/dazuko-2.0.2 modules make[1]: Entering directory `/usr/src/linux-2.6.4-52' CHK include/linux/version.h [ . . . ] - - - - - s n i p p (Danach kümmert sich Dazuko doch um "./include/linux/version.h" und nicht um "./autoconf.h".) Aber auch in "./version.h" sind (bei mir) alle Zeilen mit einem '#' deaktiviert. Außerdem steht da nicht der Name des Kernels mit den Angaben drin, wie in "uname -r" oder "/proc/version" Etwaige manuelle Änderungen werden in "version.h" überschrieben. Nun zu meinen Fragen konkret: Hat sich mit Kernel 2.6* irgendetwas geändert hinsichtlich des "Linux Kernel Source Code" (Adresse, Name usw) Wie lautet der Code definitiv und wo ist er vor bzw. nach dem Kompilieren zu finden? (Mit dem Kernel 2.421* hatte ich mit Dazuko und dem Linux Kernel Source Code keine Probleme. Erst mit Kernel 2.6 * akzeptiert "Dazuko" nicht mehr meinen "Linux Kernel Source Code". Übrigens ich habe vorher nie etwas für den Code tun müssen, war immer ohne weitere OK) Für jede Hilfe - wie immer - besten Dank im voraus. Schöne Grüße Rolf
Rolf Hoff wrote:
[...] 1) Ich habe nun festgestellt, dass (bei mir) allen Zeilen in " ./include/linux/autoconf.h" ein '#' vorangestellt ist. [...] Aber auch in "./version.h" sind (bei mir) alle Zeilen mit einem '#' deaktiviert. Außerdem steht da nicht der Name des Kernels mit den Angaben drin, wie in "uname -r" oder "/proc/version"
Diese Zeilen sind nicht auskommentiert, das sind Anweisungen fuer den Praeprozessor! In version.h steht die Definition der Variablen UTS_RELEASE, die sollte genau einem "uname -r" entsprechen, wenn die Kernel-Quellen korrekt fuer den momentan laufenen Kernel konfiguriert sind.
[...] Etwaige manuelle Änderungen werden in "version.h" überschrieben.
Kernel-Header solltest Du _nie_ von Hand aendern!
[...] Nun zu meinen Fragen konkret:
Hat sich mit Kernel 2.6* irgendetwas geändert hinsichtlich des "Linux Kernel Source Code" (Adresse, Name usw)
Wie lautet der Code definitiv und wo ist er vor bzw. nach dem Kompilieren zu finden?
Installiere den zu Deinem Kernel passenden Quellcode. Wechsle in das Verzeichnis mit den Quellen und fuehre dort ein "make cloneconfig && make prepare" aus, wenn es sich um die Quellen eines SuSE-Kernels handelt. Fuer weitere Details und das Vorgehen bei Vanilla Kernelquellen, siehe mein kleines Kernel-Howto, Adresse sollte bekannt sein. Der Link /lib/modules/`uname -r`/build sollte auf das Verzeichnis mit den konfigurierten Kernelquellen zeigen. Falls Du zum Compilieren Deines eigenen Kernels ein Build-Directory verwendet hast, dann muss das auch beim Erstellen des Dazuko-Moduls mit angegeben werden. CU, Th.
Thomas Hertweck schrieb:
Rolf Hoff wrote:
[...] 1) Ich habe nun festgestellt, dass (bei mir) allen Zeilen in " ./include/linux/autoconf.h" ein '#' vorangestellt ist. [...] Aber auch in "./version.h" sind (bei mir) alle Zeilen mit einem '#' deaktiviert. Außerdem steht da nicht der Name des Kernels mit den Angaben drin, wie in "uname -r" oder "/proc/version"
Diese Zeilen sind nicht auskommentiert, das sind Anweisungen fuer den Praeprozessor! In version.h steht die Definition der Variablen UTS_RELEASE, die sollte genau einem "uname -r" entsprechen, wenn die Kernel-Quellen korrekt fuer den momentan laufenen Kernel konfiguriert sind.
Meine ./version.h sieht so aus: - - - s n i p p #define UTS_RELEASE "2.6.4-52-default" #define LINUX_VERSION_CODE 132612 #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) - - - - s n i p p Ändern sich die Angaben in version.h oder sind die immer gleich? Ändert sich der Versions-Code durch erneutes Kompilieren? Was bedeuten die Angaben in der unteren Zeile? uname -a sieht so aus: ro999:~ # uname -a Linux wieselsdachsbau 2.6.4-52-default #1 Sun May 23 21:19:15 \ CEST 2004 i686 i686 i386 GNU/Linux ro999:~ # uname -r lautet: ro999:~ # uname -r 2.6.4-52-default ro999:~ # Ist das so in Ordnung? Bisher habe ich das immer so für richtig angesehen. Nur durch Dazuko bin ich verunsichert worden. In autoconf.h beginnen alle Zeilen genauso wie in version.h. [ . . . ]
Wie lautet der Code definitiv und wo ist er vor bzw. nach dem Kompilieren zu finden?
Installiere den zu Deinem Kernel passenden Quellcode. Wechsle in das Verzeichnis mit den Quellen und fuehre dort ein "make cloneconfig && make prepare" aus, wenn es sich um die Quellen eines SuSE-Kernels
Anfangs habe ich k_deflt und die kernel-source installiert. Alsdann habe ich die /usr/src/linux/.config-Datei mit xconfig bearbeitet, danach gesichert und mit make bzImage, make modules und make modules_install compiliert. System.map und bzImage entsprechend als System.map-2.6.4-52-default und als vmlinuz nach /boot kopiert. Lilo ausgeführt. Muss ich dabei dann auch "make cloneconfig && make prepare" ausführen?
handelt. Fuer weitere Details und das Vorgehen bei Vanilla Kernelquellen, siehe mein kleines Kernel-Howto, Adresse sollte bekannt sein.
Ja, kenne ich, habe ich mir kopiert. Gefällt mir richtig gut.
Der Link /lib/modules/`uname -r`/build sollte auf das Verzeichnis mit den konfigurierten Kernelquellen zeigen.
Verstehe ich das richtig, dass das Verzeichnis mit den konfigurierten Kernelquellen /usr/src/linux bzw. /usr/src/linux-2.6.4-5 2 ist, also das Verzeichnis, in dem sich auch die .config-Datei befindet? Aber wenn es so ist, warum fragen die Leute von dazuko.org dann nach dem Inhalt von autoconf.h bzw. version.h? (Tut mir leid, wenn diese Frage eine dumme Frage ist. Aber wenn ich sie hier nicht stellen würde, dann bliebe ich unsicher.)
Falls Du zum Compilieren Deines eigenen Kernels ein Build-Directory verwendet hast, dann muss das auch beim Erstellen
habe ich nicht gemacht
des Dazuko-Moduls mit angegeben werden.
Das ist ja das sonderbare an Dazuko. Man kann nichts angeben. Dazuko bildet mit einem make-script seine Module, aber wenn man das zutreffende Modul (dazuko.ko) installieren will, dann klappt das nicht mehr. Dazuko sucht sich selbst, was er haben will und wenns ihm nicht gefällt, dann meckert er, ohne dass man (besser gesagt ich) sich (mich) dagegen wehren kann. Übrigens soll das Installieren des Kernel-Moduls mit "/sbin/insmod dazuko.ko " erfolgen. Gibt es das Kommando noch beim Kernel 2.6* Eine unendliche Geschichte. Ich glaub, ich vergesse einfach, dass es antivir und dazuko gibt. Vielen Dank für die umfangreichen Infos und Hilfen. Beste Grüße Rolf
Hallo, Am Thu, 27 May 2004, Rolf Hoff schrieb:
Eine unendliche Geschichte. Ich glaub, ich vergesse einfach, dass es antivir und dazuko gibt.
AntiVir braucht _KEIN_ dazuko. Nur AVGuard braucht das. -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
David Haller schrieb:
Hallo,
Am Thu, 27 May 2004, Rolf Hoff schrieb:
Eine unendliche Geschichte. Ich glaub, ich vergesse einfach, dass es antivir und dazuko gibt.
AntiVir braucht _KEIN_ dazuko. Nur AVGuard braucht das.
das sehe ich auch so. Ich wollte aber avguard haben, schon aus Prinzip Gruß Rolf
Rolf Hoff wrote:
Thomas Hertweck schrieb:
[....] Diese Zeilen sind nicht auskommentiert, das sind Anweisungen fuer den Praeprozessor! In version.h steht die Definition der Variablen UTS_RELEASE, die sollte genau einem "uname -r" entsprechen, wenn die Kernel-Quellen korrekt fuer den momentan laufenen Kernel konfiguriert sind.
Meine ./version.h sieht so aus: - - - s n i p p #define UTS_RELEASE "2.6.4-52-default" #define LINUX_VERSION_CODE 132612 #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) - - - - s n i p p [...] uname -r lautet:
ro999:~ # uname -r 2.6.4-52-default ro999:~ #
Ist das so in Ordnung?
Wie Du siehst, passt das doch genau zu der Angabe, die ich gemacht habe: Die Ausgabe von "uname -r" ist identisch mit der Angabe in UTS_RELEASE. Die Kernel-Quellen scheinen also korrekt fuer Deinen momentan laufenden Kernel konfiguriert zu sein. Zu Deinen restlichen Fragen: Du musst Dich wohl mal ein wenig mit Compilern, Praeprozessorn und Programmieren generell beschaeftigen, um derartige Konstrukte wie #define etc. zu verstehen - das fuehrt doch ein bissl zu weit fuer diese Liste und ueber das Thema kann man sich natuerlich die Finger wund schreiben.
[...] In autoconf.h beginnen alle Zeilen genauso wie in version.h.
Ja, das sind aber keine Kommentare, wie Du letztes Mal geglaubt hast.
[...] Anfangs habe ich k_deflt und die kernel-source installiert. Alsdann habe ich die /usr/src/linux/.config-Datei mit xconfig bearbeitet, danach gesichert und mit make bzImage, make modules und make modules_install compiliert. System.map und bzImage entsprechend als System.map-2.6.4-52-default und als vmlinuz nach /boot kopiert. Lilo ausgeführt.
Das ist so nicht besonders gut, denn 2.6.4-52-default ist vermutlich der SuSE Default-Kernel. Wenn Du einen eigenen Kernel baust, solltest Du _immer_ dafuer sorgen, dass dessen Ausgabe von "uname -r" nicht mit dem SuSE Default-Kernel kollidiert.
[...] Muss ich dabei dann auch "make cloneconfig && make prepare" ausführen?
Wenn Du einen eigenen Kernel gebaut hast, dann sind die Quellen natuerlich schon konfiguriert und die Headerdateien wie z.B. version.h sind auf dem neusten Stand und passen zu diesem neuen Kernel.
[...] Verstehe ich das richtig, dass das Verzeichnis mit den konfigurierten Kernelquellen /usr/src/linux bzw. /usr/src/linux-2.6.4-5 2 ist, also das Verzeichnis, in dem sich auch die .config-Datei befindet?
Ja.
[...] Aber wenn es so ist, warum fragen die Leute von dazuko.org dann nach dem Inhalt von autoconf.h bzw. version.h?
Diese Headerdateien werden beim Kompilieren von Kernelmodulen eingebunden, weswegen sie existieren und richtig konfiguriert sein muessen. Ansonsten wuerdest Du z.B. ein Modul mit falschen Versionsangaben produzieren...
[...] Das ist ja das sonderbare an Dazuko. Man kann nichts angeben. Dazuko bildet mit einem make-script seine Module, aber wenn man das zutreffende Modul (dazuko.ko) installieren will, dann klappt das nicht mehr. Dazuko sucht sich selbst, was er haben will und wenns ihm nicht gefällt, dann meckert er, ohne dass man (besser gesagt ich) sich (mich) dagegen wehren kann.
Das muss man genau analysieren - aus Deinen Angaben kann man nicht darauf schliessen, was schief geht.
[...] Übrigens soll das Installieren des Kernel-Moduls mit "/sbin/insmod dazuko.ko " erfolgen. Gibt es das Kommando noch beim Kernel 2.6*
Insmod laedt Kernel-Module zum laufenden Kernel hinzu. Installieren im System unter dem korrekten Module-Verzeichnis tut das Kommando nicht. CU, Th.
Thomas Hertweck schrieb:
Rolf Hoff wrote:
Thomas Hertweck schrieb:
[....]
Wie Du siehst, passt das doch genau zu der Angabe, die ich gemacht habe: Die Ausgabe von "uname -r" ist identisch mit der Angabe in UTS_RELEASE. Die Kernel-Quellen scheinen also korrekt fuer Deinen momentan laufenden Kernel konfiguriert zu sein. Zu Deinen restlichen Fragen: Du musst Dich wohl mal ein wenig mit Compilern, Praeprozessorn und Programmieren generell beschaeftigen, um derartige Konstrukte wie #define etc. zu verstehen - das fuehrt doch ein bissl zu weit fuer diese Liste und ueber das Thema kann man sich natuerlich die Finger wund schreiben.
Das ist wohl wahr. Trotzdem hier bitte noch letzte Fragen: 1) In /usr/src/linux-version/Makefile ist die Zeile EXTRAVERSION schon mit Angaben vorbelegt. Müssen die gelöscht werden, wenn man selbst eine Extraversion angibt? 2) Eigene Angaben im ./Makefile (z.B. Extraversion) haben bei mir nicht die Angaben unter xconfig/'Build options' beeinflusst/verändert . 3) In xconfig konnte ich die Angaben unter 'Build options' nicht verändern. Deshalb habe ich die Änderungen (für Extraversion) direkt unter /usr/src/kernel-version/.config vorgenommen. Ist das zu beanstanden? Für alle Unterstützung nochmals vielen Dank Grüße Rolf
Rolf Hoff wrote:
[...] Trotzdem hier bitte noch letzte Fragen:
1) In /usr/src/linux-version/Makefile ist die Zeile EXTRAVERSION schon mit Angaben vorbelegt. Müssen die gelöscht werden, wenn man selbst eine Extraversion angibt?
Wenn es sich um die Quellen eines SuSE-Kernels handelt, dann sollte im Makefile bei EXTRAVERSION eine Zeile wie die folgende stehen: EXTRAVERSION = -$(shell echo $(CONFIG_RELEASE)-$(CONFIG_CFGNAME)) Die Extraversion wird hier also mittels zweier Variablen gesetzt; diese Zeile sollte nicht geloescht werden. Bei SuSE sollte man die Extraversion _nur_ ueber "Build Options" -> "Configuration Name" bzw. "Build Options" -> "Release Number" bei der Kernelkonfiguration setzen. Bei einem Vanilla-Kernel muss man die Zeile EXTRAVERSION im Makefile direkt aendern. Durch evtl. Patches wird sie angepasst, so lautet diese Zeile bei meinem momentanen Kernel z.B. EXTRAVERSION = -rc1-mm1
2) Eigene Angaben im ./Makefile (z.B. Extraversion) haben bei mir nicht die Angaben unter xconfig/'Build options' beeinflusst/verändert .
Siehe oben.
3) In xconfig konnte ich die Angaben unter 'Build options' nicht verändern.
Warum? Ein Doppelklick auf die Angabe "Configuration Name" bzw. "Release Number" sollte eine Zeile oeffnen, in der man die Angaben aendern kann.
Deshalb habe ich die Änderungen (für Extraversion) direkt unter /usr/src/kernel-version/.config vorgenommen. Ist das zu beanstanden?
Nein. Wenn Du die Konfiguration abspeicherst, dann landet die genau in der Datei .config - theoretisch koenntest Du sogar den kompletten Kernel direkt in der Datei .config konfigurieren. Das ist aber sicherlich nicht sehr bequem :-) CU, Th.
Thomas Hertweck schrieb:
[ . . .] (Tut mir leid, wenn diese Frage eine dumme Frage ist. Aber wenn ich sie hier nicht stellen würde, dann bliebe ich unsicher.) [ . . . ] Vielen Dank für die umfangreichen Infos und Hilfen. hallo alle die hier von mir zuletzt gestellten (dummen) Fragen konnte ich mir inzwischen alle selbst beantworten anhand praktischer Übungen. Nochmals vielen Dank für alles Gruß Rolf
participants (3)
-
David Haller -
Rolf Hoff -
Thomas Hertweck