Ist es möglich, eine Darwin-Distribution aus dem Quellcode zu kompilieren, so wie Sie eine Linux-Distribution erstellen können?

Aktualisierung vom 19. April 2015:

Auch nach zwei Jahren scheint das Interesse an diesem Bereich noch sehr gering zu sein. Die Hackintosh-Community ist jedoch immer noch sehr aktiv, was bedeutet, dass einer der wenigen Open-Source-Nicht-Apple-Bootloader, der xnu (Chameleon und Forks) booten kann, immer noch gepflegt wird und Yosemite booten kann. Es gibt auch Erfolgsgeschichten zum Booten von OS X Yosemite innerhalb von QEMU. Außerdem dank eines (jetzt Apple-angestellten) Entwicklers, der sich des Handles winocm bedient , haben wir einen ARM-Port des xnu-Kernels. Sie ist die aktivste Entwicklerin auf diesem Gebiet, die ich kenne.

Es wird auch bald eine Fortsetzung von Amit Singhs Mac OS X Internals geben. Ich erwähne normalerweise nicht gerne die persönlichen Seiten von Leuten; allerdings scheint der blogserver mit all den infos etwas unzuverlässig zu sein, also siehe infobox auf ameaijous twitter-seite.

Ich habe es geschafft, die Entwicklungs-Toolchain von Apple zu bauen (ein Selbsthoster, aber das "Darwin SDK" wurde auch auf Linux portiert). Ich glaube, dass es noch möglich sein könnte, ein Darwin-Betriebssystem von Grund auf neu zu erstellen – alles, was uns vielleicht fehlt, sind einige Open-Source-Kexts. Beobachten Sie diesen Bereich, und wenn Sie wissen, wie man Interesse weckt, lassen Sie es mich wissen! :)

Kurze Antworten auf diese Frage:

Technisch: Ja

Praktisch: Nein*

Mit binären Cheats: Wahrscheinlich, aber auch nicht legal (ungetestet)

Mit binären Cheats für generische Hardware: Wie oben (ungetestet)

*es sei denn, Sie arbeiten bei Apple (*räuspert sich in Richtung Kalifornien*)

Längere Antwort:

Das wird ziemlich lang. Ich schlage Kaffee vor. Wenn Sie nicht die Zeit/Lust haben, alles zu lesen, können Sie zu "Abschließende Bemerkungen" springen.

Praktisch möglich (Nein):

Leider hat Apple den Quellcode für zu viele von Darwins notwendigen KEXTs und Binärdateien zurückgezogen, um die Kompilierung eines Darwin-Betriebssystems rein aus den Quellen zu ermöglichen. Es ist technisch immer noch möglich (Sie könnten die Quelle selbst schreiben, um es richtig zu reparieren), aber ich habe einfach nicht die Zeit, die Fähigkeiten oder die Neigung, dies zu tun (und ich bezweifle, dass die Crowdfunding-Community sehr interessiert wäre).

Wenig überraschend war der entscheidende Wendepunkt die Veröffentlichung von Darwin 10, das xnu ins x86_64-Land brachte. Die meisten der notwendigen Quellen gab es schon vorher, aber nur x86. Im Laufe der Zeit scheint sich die Bedeutung von Apples „Open Source“ zu „Open Source nur auf Apples Hardware“ verlagert zu haben, da Apples KEXTs jetzt im Großen und Ganzen hardwarespezifisch sind, also selbst wenn Sie alles bekommen könnten und ausgeführt (siehe unten), wären Sie immer noch auf Apple-Hardware beschränkt.

Technisch möglich (Ja):

Es ist jedoch nicht alles verloren. Der LFS-Leitfaden hat sich als nützlich erwiesen, und sicherlich können alle erforderlichen Einstellungen durchgeführt werden, ohne das Darwin-Betriebssystem tatsächlich zu erstellen. Darüber hinaus geben Ihnen die vorgestellten Schritte einen fast genauen Fahrplan für den weiteren Weg, abzüglich des Kernels, der KEXTs und des Bootloaders. Ich habe es jedoch geschafft, das Bootloader-Problem zu lösen (zumindest für Apple-Hardware).

Wenn Sie interessiert sind, finden Sie hier eine vollständige Übersicht darüber, was Sie tun müssen:

• Löschen Sie eine Partition (vorzugsweise 8 GB oder größer) auf einem Laufwerk (intern oder extern – spielt keine Rolle) und formatieren Sie sie als Mac OS Extended (Journaled) (HFS+).

• Stellen Sie sicher, dass es eine GUID-Partitionstabelle (GPT) hat und dass es eine EFI-Partition hat, wenn Sie dies tun. Der einfachste Weg, dies zu tun, ist über das Festplattendienstprogramm von Apple, aber Sie können es auch über die Befehlszeile tun, wenn Sie möchten (es gibt an anderer Stelle Anleitungen, wie das geht). Der wichtige Punkt ist, dass wenn Sie distil list diskNsM ausführen , sollten die folgenden Informationen korrekt sein:

  Partitionstyp:Apple_HFS

  Betriebssystem kann installiert werden:Ja

  Schreibgeschützte Medien:Nein

  Schreibgeschütztes Volume:Nein

• Folgen Sie nun dem LFS-Leitfaden (mit Anpassungen).

• Fügen Sie DFS=/Volumes/DarwinOS ein (natürlich unter Verwendung des tatsächlichen Einhängepunkts) in .bashrc und .bash_profile

• Erstellen Sie das Benutzerverzeichnis (chown es ganz am Ende auf 0:0):

  sudo mkdir -v "$DFS"/usr
  

• Geben Sie root ein :

  sudo su -
  

• Erstellen Sie das Quellenverzeichnis und setzen Sie das Sticky-Bit:

  mkdir -v "$DFS"/sources     # Make sure you still have $DFS defined; if not, redefine it.
  chmod -v a+wt "$DFS"/sources
  

• Erstellen Sie das Tools-Verzeichnis und erstellen Sie einen symbolischen Link darauf, damit wir es später einfach zu $PATH hinzufügen können (immer noch in root übrigens):

  mkdir -v "$DFS"/tools
  ln -sv "$DFS"/tools /
  logout          # Leave root
  

• Laden Sie die Quelle aller gewünschten Pakete herunter. Hier bleibt man natürlich hängen. Alle notwendigen sind nicht da. (Übrigens bevorzuge ich GNUs binutils sowieso.)

Angenommen, Sie könnten tatsächlich alle benötigten herunterladen, fahren wir fort.

• Erstellen Sie einen unterprivilegierten Benutzer speziell für DFS (empfohlen von LFS):

  sudo dscl . -create /Users/lfs
  sudo dscl . -create /Users/lfs UserShell /bin/bash
  sudo dscl . -create /Users/lfs RealName "LFS DFS"
  sudo dscl . -create /Users/lfs UniqueID "2070"      # whatever you like
  sudo dscl . -create /Users/lfs PrimaryGroupID 20    # Default 'staff'
  sudo dscl . -create /Users/lfs NFSHomeDirectory /Users/lfs
  sudo dscl . -passwd /Users/lfs dfs          # Again to taste.
  

• Beachten Sie, dass Sie das Homedir des neuen Benutzers auf einem Mac manuell erstellen müssen:

  sudo mkdir /Users/lfs
  sudo chown -R lfs:staff /Users/lfs/
  

• Gewähren Sie nun dem neuen Benutzer Zugriff auf die Quellen und Tools

  sudo chown -v lfs $DFS/tools
  sudo chown -v lfs $DFS/sources
  

• Anmelden:

  su - lfs
  Password: dfs
  

• Führen Sie den folgenden Befehl aus, um die Umgebung zu bereinigen (von LFS):

  cat > ~/.bash_profile << "EOF"
  echo "Entering clean environment…"
  exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
  EOF
  

• Führen Sie nun den folgenden Befehl aus (siehe LFS, wenn Sie sich nicht sicher sind):

  cat > ~/.bashrc << "EOF"
  set +h
  umask 022
  DFS=/Volumes/*DarwinOS*     # As previously
  LC_ALL=POSIX
  LFS_TGT=$(uname -m)-dfs-darwin1242  # Look inside gcc/configure for possibilities!
  PATH=/tools/bin:/bin:/usr/bin       # Note symlink from before
  export LFS LC_ALL LFS_TGT PATH
  echo ".bashrc script complete. Environment is ready."
  EOF
  

• /configure von GCC ist recht flexibel. Versuchen Sie, *- zu gruppieren oder führen Sie einfach gcc -v aus um zu sehen, wie Ihr Host-Rechner konfiguriert wurde, und kopieren Sie das.

• Melden Sie sich jetzt vom lfs-Benutzer ab und wieder an. Sie sollten jetzt eine saubere Umgebung haben.
• Von nun an findet alles innerhalb des lfs-Benutzers statt. Sie werden feststellen, dass ich etwas faul war, nur die Hälfte der 'LFS'-Symbole in 'DFS'-Symbole umzuwandeln. Tut mir leid, aber Sie verstehen schon.

Okay, jetzt zum hypothetischen Abschnitt.

Von hier aus wird es ziemlich gut eine Standard-LFS-Prozedur sein:Quellen extrahieren, bauen, installieren, testen, Quellen löschen. Beachten Sie, dass die 2 Durchgänge von binutils, GCC und Glibc immer noch notwendig sind, ABER Sie müssen AUCH eine funktionierende Kopie von libc++.1.dylib haben – und das müssen Sie auch in 2 Durchgängen machen. Auf der libcxx-Seite des LLVM-Projekts finden Sie einige weitere Details. Einmal kompiliert, können Sie es in /usr/lib einfügen . Sie müssen den xnu-Kernel kompilieren und installieren (es gibt einige Tutorials im Internet, wie das geht) und dann die KEXTs installieren. Selbst wenn alle erforderlichen KEXTs verfügbar wären, müssten Sie sie immer noch manuell in das .kext-Paket einfügen. Auch hier gibt es Tutorials, wie man einen KEXT auf der Kommandozeile von Hand erstellt.

Das letzte Bit macht das System bootfähig. Führen Sie dazu den folgenden Befehl aus:

 "$DFS/usr/sbin/bless" --folder "$MOUNT/System/Library/CoreServices" --bootefi --verbose

Eigentlich macht der zu segnende Ort keinen wirklichen Unterschied. Dieser Ordner entspricht lediglich dem Apple-Standard.

Unter der Annahme, dass der Kernel und die KEXTs an den richtigen Stellen waren, hatten Sie auf jeden Fall korrekte Kopien von dyld , launchd , etc an Ort und Stelle und boot.efi ordnungsgemäß funktioniert hat, sollte das System funktionieren und bootfähig sein!

Beachten Sie, dass Sie, wenn Sie wirklich wollten, einen faux-launchd ausführen könnten das ist nur ein Skript zum Ausführen einer Bash-Eingabeaufforderung – genau das macht PureDarwin Nano.

Schreiben Sie auf jeden Fall die KEXTs und Binärdateien selbst, wenn Sie möchten – es ist technisch möglich. Rufen Sie mich einfach an, wenn Sie fertig sind.

Bei binären Cheats:Wahrscheinlich, aber auch nicht legal (ungetestet)

Warum können Sie also nicht einfach die Binärdateien, KEXTs und erforderlichen Dateien aus Mountain Lion rippen, das Volume segnen und loslegen? Nun, das kannst du wahrscheinlich. Dafür braucht man aber auch eine Lizenz. Wenn Sie dies tun, haben Sie im Grunde nur eine Kopie von Mountain Lion erstellt. Ist das nicht nebensächlich?

Mit binären Cheats für generische Hardware:Wie oben (ungetestet)

Das ist so ziemlich ist das OSx86-Projekt. Auch hier stoßen Sie so ziemlich sofort auf rechtliche Probleme. Es steht außer Frage, dass diese letzten beiden Methoden definitiv möglich sind – die Tatsache, dass Sie Mountain Lion auf generischer Hardware ausführen können, ist ein Beweis dafür – aber der springende Punkt dabei war, in der Lage zu sein, Ihr eigenes Darwin-Betriebssystem legitim aus dem Quellcode zu kompilieren. P>

Nebenbemerkung

Sie haben vielleicht bemerkt, dass ich absichtlich alles 32-Bit vermieden habe. In einer Welt, in der jedes wichtige Betriebssystem in 64-Bit verfügbar ist, macht es nicht viel Sinn, ein 32-Bit-Betriebssystem zu kompilieren. Apple hat hier tatsächlich Disk-Images von Darwin (bis Darwin 9) bereitgestellt. Sie funktionierten perfekt auf meiner Windows-Box.

Abschließende Bemerkungen

Ich denke, am Ende des Tages kaufen die Leute den Mac nicht für Darwin, sie kaufen den Mac für Aqua. Infolgedessen ist die Unterstützung für Darwin als eigenständiges Open-Source-Produkt allmählich so weit zurückgegangen, dass es nur noch eine symbolische Geste an die Open-Source-Community ist. Die andere leicht ironische Tatsache ist, dass Sie, um viel darüber zu lernen, direkt in das OSx86-Projekt springen müssen, das nicht gerade sanktioniert ist (um es milde auszudrücken). Selbst dann gibt es nicht viele Informationen. PureDarwin ist ein ausgezeichneter Ausgangspunkt, und das Buch von Jonathan Levin ist eine unschätzbare Referenz für alle Dinge, die mit xnu zu tun haben.

Dies war ein äußerst lehrreiches Arbeitsjahr, und ich bin fast so glücklich darüber, zu wissen, wie es geht, als würde ich es tatsächlich tun. Irgendwann muss ich aber mit der Arbeit aufhören, und jetzt ist es soweit. Als letzten vergeblichen Gruß an Apple, wäre es zu viel verlangt, nur noch einen Build von Darwin zu haben, wenn Sie Mavericks veröffentlichen?