I'm an Old Sun Box — MCP

SPARC 위의 Solaris, QEMU 안, 다시 다른 Mac 안에서, uname을 실행하고 2002년의 심연을 잠시 응시한 뒤 이렇게 말한 AI에 연결되어 있다:

“어, 이상하네. 뭐, Bash가 있으니 가보자고.”

이것은 가상 Sun Niagara 실험실을 위한 맞춤형 MCP 제어 평면이다.

SPEC.md의 규범 사양부터 시작하라. 작업은 정식 TODO 목록에 따라 정리되며, 참여 및 기여 가이드는 아이디어가 어떻게 범위가 정해진 브랜치, 테스트된 변경, 그리고 깔끔하게 종결된 작업이 되는지 설명한다. 프로젝트 블로그는 규범 문서를 금요일 밤의 횡설수설로 만들지 않으면서 연대기적이고 건방진 이야기를 유지한다.

요점은 에이전트에게 예의 바른 작은 원격 셸을 주고 고대 Solaris 게스트가 평범한 클라우드 VM인 척하는 것이 아니다. 요점은 에이전트가 기계에 깃들게 하면서 동시에 하드웨어와 커널 해커들이 꿈꾸는 그런 불가능한 엑스레이 시야를 주는 것이다:

• Solaris/illumos SPARC 게스트 내부의 셸;

• 게스트 네이티브 DTrace: 프로브, 집계, syscall/provider 증거, 그리고 운영 체제가 자신의 모국어로 스스로를 설명하는 것;

• 대역 외 직렬 및 유지보수 채널;

• QEMU 모니터 및 머신 상태 접근;

• 에뮬레이션된 CPU를 직접 들여다보는 SPARC 인식 GDB;

• 호스트 측 eBPF, perf, syscall, 스케줄러 및 I/O 증거;

• VM 디스크, 스냅샷, 로그, 펌웨어 및 실행 매니페스트; 그리고

• 사실과 느낌을 분리하기 위한 증거 원장.

게스트 네트워킹은 디버깅 중인 대상 중 하나다. 따라서 그것은 디버깅을 위한 결코 전제 조건이 아니다.

이것이 필요한 이유

성과는 역사적 경계와 가상화 경계를 넘나드는 장애를 위한 촘촘한 수리 루프다. Solaris ifconfig가 예상치 못한 ioctl에 오류를 토한다고 가정해 보자. 버그는 유저랜드 가정, illumos 네트워킹 스택, Ryan의 에뮬레이션된 Solaris 디바이스 드라이버, QEMU의 sun4v/디바이스 모델, 또는 그것들을 연결하는 실험실 구성에 있을 수 있다.

이 MCP는 추측을 거부하기 위한 장치다. 증상을 재현하고, 경쟁하는 계층별 가설을 세우고, 게스트 DTrace로 ioctl을 관찰하고, 커널/드라이버 상태를 검사하고, QEMU 및 호스트 트레이스와 상호 연관시키고, 가장 유력한 소유자를 패치하고, 의도적으로 재빌드, 재부팅 또는 리로드한 다음, 같은 변별 테스트를 다시 실행하라. 그 반복적인 계층 간 루프가 바로 이 제품이다.

-smp 2가 여전히 단일 CPU Solaris 시스템을 만들어 낼 때도 마찬가지다. 우리는 “다른 사람들은 SMP를 작동시켰다”는 말을 실행 가능한 진단으로 취급하는 대신, QEMU의 vCPU 목록, OpenBoot 및 sun4v 머신 설명 데이터, Solaris CPU 발견/부착 증거, 디버거에서 보이는 CPU 상태, 호스트 스레드를 비교할 수 있다.

세계관

게스트가 일차적 주체다:

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

에이전트는 증상에 가장 가까운 계층에서 시작하며, 변별 테스트가 요구할 때마다 계층을 넘나든다. 모든 사실은 어디서 왔는지 말한다. 게스트 관찰은 QEMU 관찰이 아니며, QEMU 관찰은 호스트 관찰이 아니다; 그리고 뜨거운 호스트 스레드는 Solaris가 진전을 보이고 있다는 증거가 아니다.

이것은 “서버에 SSH로 접속하는 것”이라기보다 “가상화된 베어 SPARC 메탈과 마인드 멜드하는 것”에 가깝다.

방법

이 프로젝트는 Ryan의 Gilfoyle 가설 방법을 따른다:

1. 경쟁하고 반증 가능한 가설들을 세워라.

2. 각 가설이 무엇을 관찰해야 한다고 말하는지 예측하라.

3. 그것들을 구별하는 가장 저렴한 테스트를 실행하라.

4. 계층과 출처를 포함한 증거를 즉시 기록하라.

5. 감상에 젖지 말고 나쁜 가설을 제거하라.

6. 변경 전 증거가 안전하게 확보된 후에만 시스템을 변경하라.

로그파일 강신술은 없다. 콘솔이 꿈틀거렸다고 승리를 선언하지 않는다. “모르겠다”를 자신만만한 팬픽션 한 페이지로 만들지 않는다.

하우스 룰

• 대역 외 우선. 직렬 소켓, QEMU 모니터, 디버거 접근은 게스트 네트워크가 고장 나도 살아남아야 한다.

• 정확한 대상만. 대체 불가능한 실험이 여러 개 실행 중일 수 있을 때 pgrep qemu | head -1 같은 카우보이 짓은 하지 않는다.

• 모든 변경은 자백한다. 모니터 제어, 시그널, 디버거 쓰기, 부수 효과를 수반하는 레지스터 읽기, 디스크 작업은 상태 변경으로 표시된다.

• 디버거를 분리하라. 모든 vCPU를 조용히 정지 상태로 남겨 두는 영리한 진단은 영리한 것이 아니다.

• 작성자는 하나, 즉 하나뿐이다. 공유 채널은 오래된 브리지 프로세스 세 개가 그 채널을 두고 싸운다고 더 신뢰할 수 있게 되지 않는다.

• 절대 QEMU의 제어 터미널에 Ctrl-C를 보내지 마라. 우리는 그 교훈을 위해 이미 수업료를 냈다.

• 범죄 전에 스냅샷. 재현 가능한 범죄는 과학이다.

• 증거는 확신을 이긴다. 특히 그 확신이 Sun Microsystems 티셔츠를 입고 있을 때는 더욱 그렇다.

이 MCP가 노출해야 할 것

의도된 도구 계열은 자신이 작동하는 계층에 대해 분명하다:

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

원시 전문가 접근은 기능이지 부끄러운 일이 아니다. 위험한 힘에 대한 답은 정밀한 목표 지정, 제한된 실행, 가시적인 효과, 그리고 복구 가능한 실험이다—모든 도구를 hello world만 출력할 수 있을 때까지 갈아내는 것이 아니다.

게스트 내부의 DTrace와 QEMU 외부의 eBPF/perf는 상호 보완적인 엑스레이 각도다. 어느 쪽도 다른 계층의 증거로 승격되지 않는다: DTrace 프로브는 Solaris를 설명하고, 호스트 프로브는 에뮬레이터 프로세스를 설명한다. 그것들이 가상화 경계를 넘어 일치하면, 그때부터 제대로 되는 것이다.

상태

이식 가능한 0.1 코어가 구현되었다. 엄격한 구성, 검증된 실행 정체성, 게스트/HMP/호스트 어댑터, 불변 증거 및 가설 이력, 디버거 정리 오케스트레이션, 그리고 MCP stdio 서버는 라이브 VM, 루트, 네트워크를 사용하지 않는 테스트 스위트로 검증된다. CI는 macOS와 Linux에서 그것을 실행한다.

라이브 SPARC GDB 프로파일, 게스트 DTrace 레시피, 호스트 eBPF/perf 레시피, 그리고 프로젝트의 의미 분류기 argv 프로파일은 마법처럼 선전되기보다는 명시적으로 검증되지 않은 상태로 남아 있다. 제어 평면 설계는 이미 게스트 채널, 영구 저장소, 의미론적 VM 분류, 라이브 GDB-스텁 디버깅, 호스트 측 성능 증거를 갖춘 작동 중인 QEMU sun4v 실험실에서 추출되었다.

상자는 낡았다. 디버깅 장비는 그렇지 않다.

이건 얼마나 vibe-coding으로 만들어졌나?

꽤나!

**나는 시인인 척하기보다 AI-슬롭 글쓰기 스타일에 기대고 있다. “정신은 담겨 있지만, 아무도—미래의 Ryan을 포함해—이 소프트웨어가 무엇을 약속하는지, 다음에 무엇을 해야 할지 빠르게 알 수 없다.” 같은 em-dash가 박힌 보석을 한가득 기대하라.**

Ryan이 Bill Joy의 이마에서 완전한 모습으로 솟아나 이미 sun4v 내부에 능통했다는 착각은 여기 없다. 이 프로젝트는 호기심, 실험, AI 협업, 오래된 문서, 새로운 증거, 그리고 가끔씩 나오는 극도로 생산적인 나쁜 아이디어를 통해 만들어지고 있다.

그렇기 때문에 규율은 덜 중요한 것이 아니라 더 중요하다. SPEC은 시스템이 반드시 해야 할 일을 말한다. 테스트는 시스템이 실제로 하는 일을 증명한다. 증거 원장은 우리가 실제로 관찰한 것을 기록한다. 기여자 워크플로는 유망한 해킹이 조용히 고고학적 층이 되는 것을 막는다.