Ich bin eine alte Sun-Box — MCP

Solaris auf SPARC, in QEMU, in einem anderen Mac, verdrahtet mit einer KI, die uname ausführte, kurz in den Abgrund von 2002 starrte und sagte:

„Huh. Seltsam. Na ja, ich habe Bash. Auf geht’s, verdammt.“

Dies ist eine maßgeschneiderte MCP-Steuerungsebene für ein virtuelles Sun-Niagara-Labor.

Beginne mit der normativen Spezifikation. Die Arbeit ist in der kanonischen TODO-Liste organisiert, und der Leitfaden für Beitritt und Mitwirkung erklärt, wie aus einer Idee ein abgegrenzter Branch, eine getestete Änderung und ein sauber abgeschlossenes Arbeitspaket wird. Der Projektblog bewahrt die chronologische, respektlose Geschichte, ohne die normativen Dokumente in einen Freitagabend-Wortsalat zu verwandeln.

Es geht nicht darum, einem Agenten eine höfliche kleine Remote-Shell zu geben und so zu tun, als sei ein uralter Solaris-Gast eine normale Cloud-VM. Es geht darum, den Agenten die Maschine bewohnen zu lassen und ihm gleichzeitig die Art unmöglicher Röntgenblick zu verleihen, von der Hardware- und Kernel-Hacker träumen:

• eine Shell im Solaris/illumos-SPARC-Gast;

• gastnative DTrace: Proben, Aggregationen, Syscall-/Provider-Evidenz und das Betriebssystem, das sich in seiner eigenen Muttersprache erklärt;

• Out-of-band-Serien- und Wartungskanäle;

• QEMU-Monitor- und Maschinenzustandszugriff;

• ein SPARC-bewusstes GDB, das direkt auf die emulierte CPU blickt;

• hostseitige eBPF-, perf-, Syscall-, Scheduler- und I/O-Evidenz;

• VM-Festplatten, Snapshots, Logs, Firmware und Lauf-Manifeste; und

• ein Evidenzregister zum Trennen von Fakten und Vibes.

Das Gastnetzwerk ist eines der Dinge, die gerade debuggt werden. Es ist daher niemals die Voraussetzung dafür, es zu debuggen.

Wozu das dient

Der Lohn ist eine enge Reparaturschleife für Fehler, die historische und Virtualisierungsgrenzen überschreiten. Angenommen, Solaris ifconfig würgt bei einem unerwarteten ioctl. Der Bug könnte in Userland-Annahmen, im illumos-Netzwerkstack, in Ryans emuliertem Solaris-Gerätetreiber, im sun4v-/Gerätemodell von QEMU oder in der Labor-Konfiguration liegen, die sie verbindet.

Dieses MCP ist die Apparatur, die sich weigert zu raten. Reproduziere das Symptom, stelle konkurrierende schichtspezifische Hypothesen auf, beobachte den ioctl mit Gast-DTrace, inspiziere den Kernel-/Treiberzustand, korreliere ihn mit QEMU- und Host-Traces, patche den wahrscheinlichsten Besitzer, baue bewusst neu, starte neu oder lade neu und führe denselben unterscheidenden Test erneut aus. Diese iterative schichtübergreifende Schleife ist das Produkt.

Dasselbe gilt, wenn -smp 2 immer noch ein Ein-CPU-Solaris-System erzeugt. Wir können QEMUs vCPU-Inventar, OpenBoot- und sun4v-Maschinenbeschreibungsdaten, Solaris-CPU-Erkennungs-/Attach-Evidenz, debugger-sichtbaren CPU-Zustand und Host-Threads vergleichen, anstatt „andere Leute haben SMP zum Laufen gebracht“ als verwertbare Diagnose zu behandeln.

Das Weltbild

Der Gast ist der primäre Untersuchungsgegenstand:

Solaris processes and kernel
        ↕
SPARC CPU, memory, traps, and devices
        ↕
QEMU monitor, console, and GDB stub
        ↕
VM host tracing, networking, and storage

Der Agent beginnt auf der Schicht, die dem Symptom am nächsten liegt, und wechselt die Schichten, wann immer ein unterscheidender Test es verlangt. Eine Tatsache sagt immer, woher sie stammt. Eine Gast-Beobachtung ist keine QEMU-Beobachtung; eine QEMU-Beobachtung ist keine Host-Beobachtung; und ein heißer Host-Thread ist kein Beweis dafür, dass Solaris Fortschritte macht.

Das ist weniger „in einen Server einloggen“ und eher „Gedankenverschmelzung mit virtualisiertem, nacktem SPARC-Metall“.

Die Methode

Das Projekt folgt Ryans Gilfoyle-Hypothesenmethode:

1. Stelle konkurrierende, falsifizierbare Hypothesen auf.

2. Sage voraus, was wir laut jeder Hypothese beobachten sollten.

3. Führe den günstigsten Test aus, der sie unterscheidet.

4. Halte die Evidenz sofort fest, einschließlich ihrer Schicht und Herkunft.

5. Töte schlechte Hypothesen ohne Sentimentalität.

6. Ändere das System erst, wenn die Evidenz vor der Änderung sicher unter Dach und Fach ist.

Keine Séance per Logdatei. Keine Siegeserklärung, nur weil die Konsole zuckte. Kein Verwandeln von „Ich weiß es nicht“ in eine Seite voller selbstbewusster Fan-Fiction.

Hausregeln

• Out-of-band zuerst. Serielle Sockets, QEMU-Monitor und Debugger-Zugriff müssen ein kaputtes Gastnetzwerk überleben.

• Nur exakte Ziele. Kein pgrep qemu | head -1-Cowboy-Scheiß, wenn mehrere unersetzliche Experimente laufen könnten.

• Jede Mutation beichtet. Monitor-Steuerungen, Signale, Debugger-Schreibvorgänge, Register-Lesevorgänge mit quittierten Nebenwirkungen und Festplattenoperationen werden als zustandsändernd gekennzeichnet.

• Kopple den Debugger ab. Eine clevere Diagnose, die stillschweigend jede vCPU angehalten lässt, ist nicht clever.

• Ein Schreiber bedeutet ein Schreiber. Gemeinsame Kanäle werden nicht zuverlässiger, wenn drei veraltete Bridge-Prozesse darum kämpfen.

• Drücke niemals Ctrl-C in QEMUs steuerndem Terminal. Wir haben für diese Lektion bereits Lehrgeld bezahlt.

• Snapshots vor Verbrechen. Reproduzierbare Verbrechen sind Wissenschaft.

• Evidenz schlägt Selbstvertrauen. Besonders, wenn das Selbstvertrauen ein Sun-Microsystems-T-Shirt trägt.

Was dieses MCP bereitstellen sollte

Die vorgesehenen Werkzeugfamilien legen explizit offen, auf welcher Schicht sie arbeiten:

lab.*          run discovery, intent, health, and manifests
guest.*        bounded guest commands, console evidence, and DTrace
qemu.*         HMP/QMP queries and deliberate machine control
debugger.*     SPARC register, instruction, memory, and backtrace capture
host.trace.*   bounded eBPF/perf/process investigations
evidence.*     append-only observations and artifact references
hypothesis.*   predictions, discriminating tests, and falsification

Rohzugriff für Experten ist ein Feature, keine Peinlichkeit. Die Antwort auf gefährliche Macht sind präzise Zielauswahl, begrenzte Ausführung, sichtbare Effekte und wiederherstellbare Experimente—nicht, jedes Werkzeug so weit abzuschleifen, bis es nur noch hello world ausgeben kann.

DTrace im Gast und eBPF/perf außerhalb von QEMU sind komplementäre Röntgenperspektiven. Keine davon wird zu Evidenz aus der anderen Schicht erhoben: Eine DTrace-Sonde beschreibt Solaris; eine Host-Sonde beschreibt den Emulatorprozess. Wenn sie über die Virtualisierungsgrenze hinweg übereinstimmen, dann sind wir am Kochen.

Status

Der portable 0.1-Kern ist implementiert. Strikte Konfiguration, validierte Laufidentität, Gast-/HMP-/Host-Adapter, unveränderliche Evidenz- und Hypothesenhistorie, Debugger-Bereinigungs-Orchestrierung und der MCP-stdio-Server sind von einer Testsuite abgedeckt, die keine Live-VM, kein Root und kein Netzwerk benötigt. CI führt sie unter macOS und Linux aus.

Live-SPARC-GDB-Profile, Gast-DTrace-Rezepte, Host-eBPF/perf-Rezepte und das semantic-classifier-argv-Profil des Projekts bleiben ausdrücklich unvalidiert, anstatt als Magie angepriesen zu werden. Das Design der Steuerungsebene wurde aus einem funktionierenden QEMU-sun4v-Labor extrahiert, das bereits Gastkanäle, persistenten Speicher, semantische VM-Klassifikation, Live-GDB-Stub-Debugging und hostseitige Performance-Evidenz besitzt.

Die Kiste ist alt. Die Debugging-Ausrüstung nicht.

Wie vibe-coded ist das?

Ziemlich!

**Ich stelle mich bewusst auf den KI-Slop-Schreibstil ein, anstatt zu tun, als wäre ich ein Dichter. Erwartet mit Gedankenstrichen gespickte Juwelen wie „Der Geist ist eingefangen, aber niemand—auch der zukünftige Ryan nicht—kann auf die Schnelle sagen, was die Software verspricht oder was als Nächstes zu tun ist.“ in großen Portionen.**

Hier gibt es keine Illusionen, dass Ryan vollständig ausgebildet der Stirn von Bill Joy entsprungen ist, bereits sattelfest in sun4v-Interna. Dieses Projekt entsteht durch Neugier, Experimente, KI-Zusammenarbeit, alte Dokumentation, neue Evidenz und die gelegentliche äußerst produktive schlechte Idee.

Das macht Disziplin wichtiger, nicht weniger. Die SPEC sagt, was das System tun muss. Tests beweisen, was es tatsächlich tut. Das Evidenzregister hält fest, was wir tatsächlich beobachtet haben. Der Contributor-Workflow bewahrt einen vielversprechenden Hack davor, stillschweigend zu einer archäologischen Schicht zu werden.