Plan 9'a Tailscale port etme çalışması

• 1 Nisan şakası olarak başlayan Plan 9 desteği, gerçek bir PR ve çekirdek·Go değişiklikleriyle devam etti; 2 Nisan 2025 itibarıyla Tailscale, Plan 9 üzerinde çalışır duruma ulaştı
• Bu, basit bir GOOS=plan9 GOARCH=386 derleme sorunu değildi; önce Go'nun Plan 9 portunda çalışma zamanı çökmesi ve derleyiciye özgü özel durumlar ortaya çıktı
• Russ Cox'un Plan 9 çekirdeği ile Go çalışma zamanı·derleyicisindeki düzeltmeleri sayesinde SSE, kayan nokta bağlamı, monoton zaman, DNS ve geliştirme ortamı sorunları birlikte toparlandı
• Tailscale, Plan 9'un /net dosya arayüzünü kullanarak TUN benzeri bir uygulama, yönlendirme, Tailscale SSH, MagicDNS ve servis toplama özelliklerini bağladı; ancak bazı kısımlar geçici uygulama ya da henüz tamamlanmamış durumda
• Mevcut doğrulama kapsamı ağırlıklı olarak 9legacy ve GOARCH=386 ile sınırlı; 9front·amd64·exit node·Go net/netns desteği için ek doğrulama veya yeniden tasarım gerekiyor

---

1 Nisan şakası gerçek bir porta dönüştü

• Tailscale, 1 Nisan 2025'te Plan 9 desteğini duyurdu ve ertesi gün bu duyurunun gerçekten çalışan bir port çalışmasına dayandığını açıkladı
• Çalışma, Tailscale PR ve çeşitli Plan 9·Go düzeltmeleriyle devam etti
• İlk yaklaşım, Tailscale'in iki Go ikilisinin GOOS=plan9 GOARCH=386 go install ./cmd/tailscale{,d} ile derlenmesinin yeterli olacağı beklentisiyle başladı
• Ağustos 2023'teki ilk denemede bazı derlemeler ilerledi ama çalışma sırasında anormal çökme yaşandı
  • Go'nun Plan 9 portu birinci sınıf bir port olmadığından, regresyonlar gözden kaçmış durumdaydı
  • Tailscale'in Plan 9 üzerinde Go'yu eskisine kıyasla daha zorlamış olması da mümkün
• Port çalışması 2024 boyunca durdu, ardından Mart 2025'te 1 Nisan fikriyle birlikte yeniden başladı

SSE ve Go'nun Plan 9 desteğini toparlamak

• 1999'da Intel Pentium III ile gelen SSE komutları, bu çalışmanın ana başlangıç noktalarından biriydi
• Go derleyicisi, Plan 9 hedefinde SSE kullanımından kaçınmaya çalışıyordu
  • Çünkü Plan 9 çekirdeği, note handler içinde SSE register'larını kaydetmiyor ve geri yüklemiyordu
  • Go derleyicisi hangi kodun note handler içinde çalışacağını bilemediği için SSE'yi küresel olarak devre dışı bırakmaya çalışıyordu
  • Bu özel durum işleme sık sık bozuldu ve derleyicinin farklı yerlerinde çok sayıda plan9 istisnası birikti
• Russ Cox, Plan 9 çekirdeğini note handler içinde kayan nokta·SIMD bağlamını ele alacak şekilde düzeltti
  • 386 tarafında sys/src/9: allow floating point in note handlers düzeltmesi eklendi
  • amd64 9k çekirdeğinde ise fork sonrası FP durumu aliasing'i, note handler içindeki SIMD ve noted(NCONT) register kaybı gibi ek sorunlar bulundu
• Go tarafında Plan 9 kod üretimi özel durumlarının kaldırılması ilerledikçe tailscaled daha uzun süre çalışabilir hale geldi

IPC ve geliştirme ortamı

• Sonrasında tailscaled, stack bozulması yerine bellek yetersizliği nedeniyle çökmeye başladı
• Önceki Plan 9 port denemesinde Tailscale'in safesocket IPC paketinde sonsuz sayıda goroutine oluşturan bir hata vardı
• Öncelikle localhost TCP kullanımına geçilerek sorun çözüldü
  • Bu yaklaşım Plan 9'un “her şey dosyadır” anlayışına daha az uyuyor, ancak diğer Plan 9 servislerinin de localhost TCP kullandığı görüldü
  • İleride Russ'ın Go'ya port ettiği srv9p package ile LocalAPI'yi bunun üzerine kurmak daha iyi olabilir
  • Mevcut uygulama diğer platformlardaki gibi localhost kimlik doğrulaması ekleyemediğinden, paylaşımlı Plan 9 makinelerde kullanılmaması özellikle belirtiliyor
• İlk geliştirme, 9legacy CD imajı tabanlı bir VM üzerinde yapıldı ve ikilileri HTTP ile indirip çalıştırma döngüsü yavaştı
• Russ Cox'un hazırladığı rsc/plan9, Plan 9 kaynaklarını, önceden derlenmiş ikilileri ve ./boot/qemu betiğini içeriyor
  • qemu VM'i disksiz açılıyor ve localhost 9P sunucusunun sağladığı Git deposunu kök dosya sistemi olarak kullanıyor
  • Geliştirme makinesiyle Plan 9 dosya sistemi paylaşılabildiği için yineleme süresi dakikalardan saniyelere indi
  • qemu ayrıca virtio kullanarak daha da hızlandı

Ağ entegrasyonu: TUN, yönlendirme, MagicDNS

• İlk çalışan Tailscale, çekirdek ağ yığınını kullanmayan kullanıcı alanı ağ iletişimi modundaydı
  • TCP, UDP, ICMP vb. gVisor'un netstack bileşeni üzerinden işleniyordu
  • Plan 9 makinesinden tailnet'e erişmek için tailscaled HTTP/SOCKS5 proxy'si kullanılmak zorundaydı
  • HTTP_PROXY veya ALL_PROXY ortam değişkenlerini tanıyan Plan 9 programı çok az olduğundan bu ideal değildi
• Plan 9'un TUN benzeri uygulaması oldukça basitti
  • /net/ipifc/clone açılıyor ve yeni arayüz numarası okunuyordu
  • Control fd'ye "bind pkt\n" yazıldığında /net/ipifc/2/* gibi yeni bir arayüz oluşuyordu
  • /net/ipifc/2/data açılarak IP paketleri doğrudan okunup yazılabiliyordu
  • Ayrı bir ioctl ya da uzunluk çerçevelemesi gerekmiyordu
• Yönlendirme tablosu işlemleri de /net/iproute dosyası üzerinden yapıldı
  • Sonradan eklenecek route'lara tail etiketi vermek için "tag tail\n" yazılıyordu
  • "add 100.64.0.0 /106 100.102.103.104" gibi iletilerle route ekleniyordu
  • Plan 9'un içinde IPv6 merkezde olduğu ve IPv4'ü IPv4-mapped IPv6 adresleri olarak ele aldığı için CGNAT 100.64.0.0/10, /106 gibi ifade ediliyordu
• MagicDNS, Plan 9 üzerinde peer'lere foo ya da foo.tailnet-name.ts.net gibi adlarla erişilebilmesini sağlamayı amaçladı
  • /net/dns veya /net/cs sorgularını yakalama seçenekleri de tartışıldı
  • Sonunda Russ, belirli DNS suffix'leri için alternatif DNS sunucusu belirtilebilmesi amacıyla Plan 9'u değiştirdi
  • DNS sorgularının hatalı biçimde negative cache'e alınması sorunu da düzeltildi

Tailscale SSH ve servis toplama

• Tailscale SSH, tailscaled içine gömülü SSH sunucusudur ve paketle ilişkilendirilmiş WireGuard anahtarları üzerinden bilinen Tailscale kimliğiyle kimlik doğrulaması yapar
• Başta Plan 9 kabuğu /bin/rc, os/exec.Command ile çalıştırılıp stdin/stdout bağlandı
  • Kabuk çalıştı ancak echo, gezinme ve process interrupt gibi işlevler düzgün çalışmadı
• Russ, netshell example'ı 9fans/go'ya ekledi
  • Bu örnek, oldukça güvensiz bir telnet sunucusuna daha yakındı ama Tailscale SSH arkasına koymak için yeterliydi
  • Sonrasında SSH ile Plan 9'un /dev/snarf içeriğini almak veya dizüstünden Go testlerini cross-compile edip SSH ile çalıştırmak kolaylaştı
• Tailscale'in isteğe bağlı özelliği olan servis toplama da Plan 9'a uyarlanacak şekilde incelendi
  • /proc/NNN/fd taranarak /net/tcp/clone açmış process'ler bulundu
  • fd'nin QID'si /net/tcp/NNN/{status,local} ile eşleştirilerek listening durumu ve port tespit edildi
  • QID'den TCP numarası hesaplama yöntemi, çekirdek uygulamasındaki değişikliklere hassas olduğu için zayıf bir nokta olarak kaldı

Zaman, web demosu, v86

• gVisor netstack, monoton zamanın geriye gittiğini raporladığında tailscaled bazen çöküyordu
  • Go'nun Plan 9 zaman uygulaması, monoton zaman olarak wall time kullanıyordu
  • ntpd saati geri aldığında netstack'in monoton zaman varsayımı bozuluyordu
• Russ, Plan 9'un /dev/bintime arayüzüne monoton zaman ekledi ve Go'nun bunu kullanmasını sağladı
• Plan 9'u web'de çalıştırmak için v86 kullanıldı
  • v86, WASM ile 32 bit işletim sistemleri çalıştırıyor ve çeşitli ağ yöntemleri sunuyor
  • Bu da GOARCH=386 üzerine odaklanılmasının nedenlerinden biriydi
• Başlangıçta Ethernet çerçevelerini websocket relay üzerinden taşımak için Tailscale'in ağ simülasyon ortamına wsproxy protocol support eklendi
  • Bu ortam, ARP, DHCP, DNS, NAT, control plane, DERP vb. bileşenleri gVisor netstack ile taklit eden bir entegrasyon test ortamında çalışıyordu
  • Ancak DHCP gidiş-dönüşü nedeniyle relay uzaktaysa Plan 9 GUI'si rio yavaş başlıyordu
• Daha sonra WISP sunucusu da uygulandı, ancak üretime alınmadan önce zaman yetmediği için copy.sh/v86'in varsayılan ağ relay ayarıyla yayınlandı
• Tailscale ve Plan 9 içeren disk imajı 16MB, Tailscale ikilisi ise açıldığında 23MB boyutundaydı
  • Açılışta “gunzip…” adımının görünmesinin nedeni buydu
  • Örnek imaj, copy.sh/v86 içindeki 9legacy profilinde yer alıyor

Kalan işler ve somut kazanımlar

• Şu anki Tailscale Plan 9 portu yalnızca 9legacy üzerinde test edildi
  • Plan 9'un başlıca fork'ları arasında en az değiştirilmiş 9legacy ile daha fazla değişiklik içeren 9front bulunuyor
  • Russ'ın 9legacy için yazdığı bazı yamaların 9front'a port edilmesi gerekebilir
• GOARCH=amd64 64 bit desteğinin de hâlâ doğrulanması gerekiyor
• exit node desteği ve Go net/netns paketi desteği uygulanmış değil
  • Bunun için Tailscale'in Plan 9 üzerinde kendisini ayrı bir /net olarak göstermesi gibi yaklaşımlar yeniden değerlendirilebilir
• Bu çalışma sayesinde Go'nun Plan 9 desteği de iyileşti
  • cmd/compile: use FMA on plan9, and drop UseFMA
  • runtime: remove nextSampleNoFP from plan9
  • cmd/compile, runtime: remove plan9 special case avoiding SSE
  • net: fix parsing of interfaces on plan9 without associated devices
  • os: guarantee min buffer size for ReadFile reads on /proc-like files
  • net: unblock UDP Reads upon Close on plan9, add test
  • runtime: fix plan9 monotonic time, crypto randomness
• Özellikle Go derleyicisindeki Plan 9 özel durumlarının kaldırılması, derleyiciyi daha basit ve düzenlemesi daha kolay hale getirdi
• v86 demosunun yayınlandığı sırada, v86 yazarının 1 Nisan şakası nedeniyle VGA metin çıktısının sahte Hollandaca gibi görünmesi sorunu vardı; ancak bu durum &nojoke query argument ile aşılabiliyordu

[GN⁺]

Hacker News yorumları

• Merak ettiğiniz bir şey varsa yanıtlayabilirim
  Şu anda birkaç kişi https://meet.google.com/qre-gydb-mkv adresinde bunu konuşuyor
  Düzenleme: Bir saat geçti ve herkes ayrıldı
  Önceki 1 Nisan blog yazısı https://tailscale.com/blog/tailscale-enterprise-plan-9-suppo... idi

  • Daha önce hiç Plan 9 sistemi kurmadım; bunu kullanırsam dağıtık sistem iletişiminin Tailnet'im üzerinden geçmesini sağlayabilir miyim?

• Russ Cox'un bu şakayı sonuna kadar götürmesi gerçekten efsanevi

  • Keşke biri Russ'ı Plan 9'a tam teşekküllü bir web tarayıcısı eklemenin çok komik olacağına ikna etse

• 9fans listesine 1 Nisan için şöyle bir şey düşmüştü
  mips, 386, arm, arm64, amd64 gibi olgunlaşmamış bilgisayar mimarilerinin bakım maliyetinin çok yüksek olduğu, bu yüzden daha olgun ve kararlı mimarilere odaklanmaya karar verildiği yazıyordu
  Bunlar da power64 ve itanium; dolayısıyla power64 ve itanium dışındaki tüm mimarilerin dondurulup korunacağı ve kullanım ömrü sonuna yükseltileceği söyleniyordu

• Şaka bir yana, gerçekten bir Plan 9 kurumsal sürümü olsaydı keşke
  Bu aralar script'lerimin çoğunu rc ile yazıyorum; nix kullandığımız ve dirnev ile otomatik olarak çekebildiğimiz için iş arkadaşlarım buna katlanıyor, oldukça iyi oldu

  • Başkalarının rc script'lerini çalıştırabilmesinden çok, onları okuyup değiştirebilmelerinden endişe ederdim
  • rcnin avantajlarından biri şu[1]:
    “rc tasarımındaki en önemli ilke, onun bir makro işlemcisi olmamasıdır. Girdi, sözcüksel ve sözdizimsel analiz kodu tarafından asla birden fazla kez taranmaz”
    Eskiden çalıştığım bir Unix şirketinde, çalışan bir shell script'i değiştirildiği için çalışma disklerinin çoğunu silmiştik. Neyse ki günlük yedekleri teybe alıyorduk; bu da yaklaşık 17 yıl önceydi
    [1] https://www.scs.stanford.edu/nyu/04fa/sched/readings/rc.pdf
  • “Kurumsal Plan 9” derken tam olarak ne beklediğini biraz daha açıklayabilir misin?

• İlk yazıda kaçırdıysan ve doğrudan denemek istiyorsan, bu v86 imajında çalışıyor:
  https://copy.sh/v86/?profile=custom&m=768&vram=16&hda.url=ht...
  VM içinde tailscaled ve tailscalei başlatabilirsin. Proxy kullanılabilirliği sınırlı olduğundan çevrimiçi duruma geçmesi biraz zaman alabilir
  Düzenleme: alt üçüncü düğme işlevi görüyor. Terminal başlatmak için alt'a basılı tutup sağ tıkla, new'i seç, alt'ı bırak ve sağ tıkla sürükleyerek terminal penceresinin boyutunu ayarla

• Webinar devam ediyor (Google Meet) https://ftp.plan9.ts.net/webinar

  • İlgilenenler için söyleyeyim, az önce bitti

• Şakanın öncülünü sevdim ama açıklama uzadıkça bir anda içim karardı
  Bozuk olan çok şey var ve karmaşıklık da çok fazla. Sonuçta ne için, bir ağ tüneli yapmak için mi? Bu ek işin kendisi şaka olsaydı gülerdim

  • Yeni işi yapmak için Plan 9 tarafında biraz çalışma gerekti ama gerçek Tailscale uygulaması diğer Unix'lere kıyasla çok daha az emek istedi
  • Bu çalışma sayesinde Go derleyicisi de daha iyi hâle gelmiş gibi duruyor. Çünkü koddaki Plan 9'a özel işlem azalmış

• rsc, rob pike ve bradfitz'i özellikle Plan 9 üzerine saatlerce konuşmak için tutabilirmişim gibi geliyor. Tabii bu onların zamanını tamamen boşa harcamak olurdu
  O işletim sistemi gerçekten büyüleyici
  Kariyerimin başlarında birlikte çalıştığım bir uzmanın yanımda oturup ben yeterince anlayana kadar sabırla yöntemleri gösterdiği ve sorularımı yanıtladığı zamanı hatırlıyorum. Derin suya atılsam bile yüzebilecek hâle getiriyordu; üç saat içinde belirli bir bilgi alanında lisans derecesi almışım gibi, kariyerimdeki en hızlı gelişimlerden biriydi
  C bilmiyorum ve Plan 9'u üretken biçimde kullanacak kadar da bilmiyorum; ama yine de bugünün başlıca üç işletim sisteminde eksikliğini hissetmek için bile daha fazla bilmek ve öğrenmek istediğim harika ve kullanışlı özellikleri var
  Param olsaydı Go bilgimi genişletmek için üçünün de zamanını bire bir satın almak, ayrıca hep istediğim ama kendi başıma edinemediğim Plan 9 anlayışı için rsc ve rob pike'ın zamanını almak isterdim

• Plan 9'u gerçekten seviyorum. Onun ilkelerinin çoğunu alıp kendi işletim sistemimi yapmak emeklilik projem ve hayat hedefim
  Düzenleme: Bu proje için “chaos10” adını ayırdım. SerenityOS gibi, muhtemelen bir planı olmayacak

• Bunun çalışması için Plan 9 çekirdeğini bile yamalayacaklarını hiç beklemiyordum

  • Neden olmasın? Belli ki kimse daha önce böyle bir şeyi ciddi ciddi denememişti; eksik kalan iş miktarı nispeten az görünüyor :)