PPCNUX wünscht allen Leser ein frohe Weihnacht
Di, 2007-12-25 12:11 – goetz
Die Geschenke sind verteilt, leider war nichts für die PowerPC-Gemeinde dabei (Aber wer hätte das schon erwartet). Das PPCNUX-Team wünscht trotzdem allen seinen Lesern eine frohe Weihnacht und schöne Festtage.
- Anmelden oder Registrieren um Kommentare zu schreiben
Kommentare
Leselektüre für das neue Jahr 2008
Inside the Mac OS X Kernel: http://events.ccc.de/congress/2007/Fahrplan/events/2303.en.html
Ich habe bisher noch keine Antwort auf meine Frage erhalten:
http://www.ppcnux.de/?q=node/7105#comment-12613
http://www.ppcnux.de/?q=node/7105#comment-12612
Wo werden "intern Saltos gemacht" bzw. wo läuft der Kernel "entgegen Intel's Spezifikationen - in einem obskuren 32-bit-Modus"?
Versuch einer Antwort
Hallo,
Eines vorweg, ich habe gerade erst begonnen mich in diese Materie einzuarbeiten. Allerdings erscheinen mir die Aussagen von ut und benuzterplutzer glaubwürdig, da sie dies mit einigen Details untermauern konnten. Soviel vorweg.
Nun hab ich aber doch ein wenig selbst recherchiert:
Das pdf am CCC-Link schreibt:
It (der kernel) is loaded as a 32 bit process in 32 bit protected mode on both kinds of machines, and if 64 bit support is detected, the kernel switches into long mode compatibility mode - a mode that supports running 32 bit code, but also allows easy switching to 64 bit code. (Seite 4 rechte Splate, 2 Absatz).
Zu dem erwähnten long mode compatibility mode findet sich wenig im Netz. Es gibt bei AMD64 aber einen long mode mit zwei Unter Modi: 64bit-mode und compatibility mode. Vermutlich ist letzterer gemeint. Zu diesem Mode schreibt AMD in diesem pdf im Abschnitt 2.1:
Compatibility Mode. Compatibility mode allows 64-bit operating systems to implement binary compatibility with existing 16-bit and 32-bit x86 applications. It allows these applications to run, without recompilation, under control of a 64-bit operating system in long mode. The architectural enhancements introduced by the AMD64 architecture that support compatibility mode are summarized throughout this chapter.
D.h. ein 64bit-Kernel darf 32bit-Apps starten (wie es z.B. Linux macht). Aber davon, dass ein 32bit-Kernel 64bit-Apps starten darf steht dort nichts. Im Gegenteil: Die Tabelle 1.1 im Abschnitt 1.3 sagt, dass die System Software 64bit sein muss, damit man den long mode nutzen kann.
Insofern scheint es erst mal merkwürdig, wie Apple es schafft, eine 32bit-Kernel im long-mode (compatibility-mode) lauf zu lassen. Dies widerspricht (zumindest auf den ersten Blick) den Spezifikationen von AMD64 (aka EMT64 aka x86_64 aka x64).
Ein mögliche Antwort zu diesem Widerspruch könnte sein, dass hier Vorteile des ursprünglichen Mikrokernel-Designs nutzt, sprich es läuft nur ein kleiner Teil als "eigentlicher" Kernel im 'long mode (64bit mode)'. Der Rest ist als "Server" (im Sinne des Mikro-kernel-Konzeptes) angelegt und läuft als 32bit-Prozess unterhalb des 64bit-"Mikrokernels". (Mir ist bewusst, das Xnu kein echter Mikrokernel mehr ist, daher auch die Anführungszeichen). Leider gibt auch das CCC-Dokument dazu wenig her. Hier mässte man wohl noch tiefer in die Materie einteigen.
Zu deinen Fragen: Zu dem Zeitpunkt, da du sie stelltest, war die News und deren Kommentare schon recht alt. Daher kann es gut sein, dass die "Befragten" die noch nicht mitbekommen. Schliesslich scannt man ja nicht alle alten Kommentare, ob dort irgendwo etwas neues auftaucht.
Bis dann
R"udiger
Lies nochmal den Artikel in
Lies nochmal den Artikel in Ruhe oder besser noch schau Dir gleich den Vortrag an: http://ftp.uni-kl.de/24C3/mp4/24c3-2303-en-inside_the_macosx_kernel-COMP...
Für andere Formate hier schauen und nach "2303" suchen: http://events.ccc.de/congress/2007/Conference_Recordings
Und nu?
Hallo,
Und nu?
Zum hier in Frage stehenden Punkt wurde nur wenig gesagt und im pdf finde ich auch nicht mehr. Einen neuen Anhaltspunkt gibt aber im Vortrag (ca. bei 30 -32min):
Der Kernel ist nicht komplett 32bit! Ein kleiner Teil des Kernels (im Vortrag auf der Folie mit 'intr_handler' bezeichnet ist 64bit-Code. Und dieser soll für Interrupts aber auch für switches zwischen Tasks (dem Mach-Unterbau der BSD-Prozesse) und Threads zuständig sein. Demzufolge ist dies sowas wie ein "nano-Kernel", der im 64bit-Mode läuft, während der Rest des Kernel ein Tasks (im Mach-Sinne) ist, und dieser eben im compatibility-Mode läuft.
Das ganze ergibt auch insofern mit der AMD-Doku Sinn. Dann würder der 'intr_handler' im privilege-Level 0 (aka Ring 0) laufen. Der Rest des Xnu (inkl. kext) in 1 und/oder 2 und die Anwendungen in 3.
Das ganze passt dann auch damit zusammen, dass Switches ziwschen 64bit-mode und compatibility mode nur im Kernel-Mode (Ring0?) möglich seien. Wobei ich letzteres direkt nicht bei AMD finden konnte (Aber ich habe mir nicht alle 538 Seiten im Details durchgelesen. Gut möglich, das bestimmt Register, die beim Mode-Switch verändert werden müssen nur im Ring 0 geändert werden können).
Fazit: Auch wenn große Teile von Xnu 32bit sind, ein kleiner Teil ist es nicht. Dieser ermöglicht einen sauberen Wechsel zwischen den Modi soweit es den User-Space angeht.
Was den Rest des Kernel betrifft bleiben Fragen offen:
Wieviel von Xnu steckt im 64bit-Teil? Der ganze Mach Micro-Kernel?
Sind der 64bit und der 32bit Teil ein Task (im Sinne der Prozessorregister) oder sind es zwei. Ich bin immer davon ausgegangen, das man bei x86 IA32 und AMD64 Code in einem Task nicht mischen kann (beim PowerPC ging dies). Demnach müssten es zwei Tasks sein. Kann ein (CPU)-Task den Priviligue-Ring wechseln?
Letzlich ist das Problem nicht gelöst nur verschoben, nämlich dahin: Wie kann der Kernel 32bit udn 64bit-Code in sich mischen?
Bis dann
R"udiger
Und nu? Nun, ich wollte
Und nu?
Nun, ich wollte genau darauf hinaus:
Der Kernel ist nicht komplett 32bit! Ein kleiner Teil des Kernels
=> So muss es auch sein, damit die CPU in Long Mode überhaupt schalten kann. Daher gibt es keine "kruden Hacks".
Das verschiebt das "Problem" nur.
Hallo,
Nämlich: Wie kann man innterhalb eines (CPU-) Tasks zwischen compatibility mode und 32bit mode switchen? Laut dem Vortrag liegt es zumindest nahe, dass der gesammte Xnu ein Task ist. Wenn es aber zwei Tasks sind, wie kommunizieren diese dann?
BTW: Die Frage dürfte sich bereits beim reinen 32bit-Kernel stellen. Bei dem 4/4-Switching gibt es nämlich auch einen "permanenten" Part, den switcher, der einerseitz im Kernel-Mode laufen muss, andererseits aber wohl ein eigener Task ist.
Ausserdem, wenn dies so straight forward ist, wie der Vortrag andeutet, warum ist Microsoft diesen Weg bei Windows Vista nicht gegangen?
Die Nebel lichten sich, aber klar seh ich auch noch nicht.
Bis dann
R"udiger
Läuft alles so wie es von Intel vorgesehen ist.
Ich behaupte mal, dass die ganze Geschichte um den Kernel und 64Bit usw. auf PowerPC weitestgehend identisch realisiert ist. Es ist in dem Fall einfach der Kernel (bzw. OSX), der sich abhebt und nicht eine bestimmte CPU-Architektur, wie es hier gerne manch einer sehen würde.
Nur weil unter anderen Betriebsystemen (die auf der x86-Plattform dominieren) manches anders realisiert ist, gelten die Bedingungen und Einschränkungen anderer Betriebsysteme noch lange nicht für Mac OS X und vor allem für Intel. In dem Beitrag sieht man schön, dass sich OSX doch in einigen Punkten von "anderen" Betriebsystemen erheblich unterscheidet.
Und wenn es in OSX für Intel bzw, dem Kernel wirklich mit "kruden Hacks" zugehen würde, dann wäre das doch spätestens jetzt bei einem Vortrag beim CCC aufgefallen oder nicht?
Warum MS das OSX-Konzept nicht aufgegriffen hat? MS hätte ja ihr komplettes System umbauen müssen. Ausserdem hat der Apple-Ansatz ja auch seine Nachteile (auch wenn in meinen Augen zumindest momentan die Vorteile überwiegen).