Re: 64-Bit-Kernel und 32-Bit-Userland: Pros und Kontras
Dieter Rohlfing <dr-erc@gmx.net> wrote:
> Hallo Sven,
>> Bitte beachten: Im Kernel-Source sind auch Build-Tools enthalten, die
>> _natürlich_ für die jeweilige Plattform kompiliert werden müssen, auf
>> der der Compiler läuft.
> Die hatte ich bereits außer Acht gelassen. Zum Beispiel die Datei csr1212.c im
> Verzeichnis ./drivers/ieee1394, die - soweit ich das erkennen kann - eine
> reguläre Kernel-Datei ist, enthält die Anweisung "#include <string.h>".
/usr/src/linux-2.6.25.10/include/linux/string.h
QED
Der Kernel ist self contained, es werden _keine_ externen Header für
Kernel-Code benutzt.
Oder wie könnte ich sonst auf meinem i386-System für MIPS oder ARM ein
Cross-Compilat erzeugen?
Bitte beachte auch: #include <header.h> heißt _nicht_ "suche im
System-Include-Pfad", sondern suche in allen mit -I angegebenen Pfaden
und erst *dann* im System-Include-Pfad.
>> Im Kernel-Code aber selbst sind _KEINE_ Referenzen zu externen Headern in
>> irgendeiner Form vorhanden und dürfen auch gar nicht vorhanden sein.
> Siehe mein obiges Gegen-Beispiel.
Sie meinen Pfad. Nächstes Gegen-Beispiel bitte, dieses taugt nicht.
>> Bitte Message-ID der Aussage angeben, ich kann das so nicht glauben, da
>> es der Wirklichkeit widerspricht.
> Mit einer Message-ID kann ich im Moment nicht dienen. Der Thread heißt "amd64
> kernel + 32-bit userland: compiling a new amd64 kernel" und wurde etwa Mitte
> letzter Woche von mir gestartet. Der Verkehr auf der amd64-Liste ist bei weitem
> nicht so rege wie hier, also müßte es einfach sein, die Aussagen zu finden.
Der Thread tut mir richtig weh.
Vor allem gibt es im ganzen Thread nicht _eine_ Aussage, die dem
entspricht, was du sagst.
Mal davon abgesehen, dass man ein AMD64-chroot auf einem 32bit-Kernel
nicht zum Laufen bekommt und es daher für die Kompilation des Kernels
(oder überhaupt für irgendwas) untauglich ist.
Der Rest des Threads diskutiert dann über RAM-Mengen, ab denen man 64bit
braucht, Probleme mit Flash und Java, etc.
Aber um die Cross-Kompilation geht es nicht mehr.
>> > Bauen geht natürlich immer. Die Frage ist nur, ob er auch läuft.
>>
>> Er läuft. Insoweit steht mein funktionierender Rechner deinen Aussagen
>> gegenüber und daher glaube ich eher meinem funktionierenden Rechner als
>> deinen Aussagen.
> Das sehe ich nicht so. Dazu schrieb ich aber bereits das folgende:
>> Wenn Du natürlich einen Kernel backst, der keine von diese
>> Kernel-Dateien einschließt, dann hast Du natürlich ein ast-reines
>> 64-bit-Programm. Wenn aber nur eine dieser Kernel-Dateien mit dabei
>> hast, dann ergibt das ein Misch-Masch von 32- und 64-bit-Code.
> Dein funktionierender Rechner belegt eben nur, daß Du Dir einen Kernel gebacken
> hast, der keine der Dateien enthält, die string.h, stdio.h, stdlib.h oder andere
> architektur-spezifische Header inkludieren. Oder der enthaltene 32-bit-Code
> kommt nie zur Ausführung.
Nein, es ist keiner enthalten. Sonst würde der Kernel nicht korrekt
linken und die Module würden auch nicht korrekt erzeugt.
>> AMD64-CPUs können 32bit und 64bit Code ausführen, das ist richtig. Aber
>> nicht im selben Prozess.
> Jetzt, wo Du es sagst, erinnere ich mich, das schon einmal gelesen zu haben.
> Beim Schreiben meiner Beiträge war mir das aber nicht mehr bewußt.
>> Und da der Kernel _immer_ ein monolithischer Prozess ist, kann er
>> entweder nur rein 64bittig oder rein 32bittig sein, Mischungen gehen
>> definitiv nicht.
> Das hieße also, ein Kernel mit gemischtem 32- und 64-bit-Code dürfte
> nicht laufen. Spätestens an der Stelle, wo er beim Abarbeiten der
> Befehle auf 32-bit-Code stößt, müßte er Probleme bekommen.
Schon der Linker fällt auf die Nase, wenn du ihm gemischen 32bit und
64bit Code vorwirfst.
S°
--
Sven Hartge -- professioneller Unix-Geek
Meine Gedanken im Netz: http://www.svenhartge.de/
Reply to: