Plan 9 पर Tailscale पोर्टिंग का काम

 (tailscale.com)
1 पॉइंट द्वारा GN⁺ 2025-04-03 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • April Fools की घोषणा से शुरू हुआ Plan 9 सपोर्ट असली PR और kernel·Go संशोधनों तक पहुँचा, और 2 अप्रैल 2025 तक Tailscale Plan 9 पर चलने की स्थिति में आ गया
  • यह सिर्फ GOOS=plan9 GOARCH=386 बिल्ड की समस्या नहीं थी; Go के Plan 9 पोर्ट में पहले runtime crash और compiler special-casing की दिक्कतें सामने आईं
  • Russ Cox के Plan 9 kernel और Go runtime·compiler संशोधनों से SSE, floating-point context, monotonic time, DNS और development environment से जुड़ी समस्याएँ साथ में सुलझीं
  • Tailscale ने Plan 9 के /net file interface का उपयोग कर TUN-जैसा implementation, routing, Tailscale SSH, MagicDNS और service collection जोड़ा, लेकिन कुछ हिस्से अभी अस्थायी implementation हैं या अधूरे हैं
  • मौजूदा validation दायरा मुख्य रूप से 9legacy और GOARCH=386 तक सीमित है; 9front·amd64·exit node·Go net/netns सपोर्ट के लिए अतिरिक्त validation या redesign की ज़रूरत है

April Fools का मज़ाक असली पोर्टिंग में बदला

  • Tailscale ने 1 अप्रैल 2025 को Plan 9 सपोर्ट की घोषणा की, और अगले दिन बताया कि यह घोषणा वास्तव में काम करने वाली पोर्टिंग पर आधारित थी
  • यह काम Tailscale PR और Plan 9·Go के कई संशोधनों तक पहुँचा
  • शुरुआती सोच यह थी कि Tailscale की दो Go binaries को GOOS=plan9 GOARCH=386 go install ./cmd/tailscale{,d} से बिल्ड करना काफी होगा
  • अगस्त 2023 की पहली कोशिश में कुछ बिल्ड आगे बढ़े, लेकिन रनटाइम के दौरान असामान्य crash हुआ
    • Go का Plan 9 पोर्ट first-class port नहीं था, इसलिए regressions बिना ठीक हुए पड़े थे
    • यह भी संभव है कि Tailscale ने Plan 9 पर Go को पहले से अधिक कठिन तरीके से उपयोग किया हो
  • पोर्टिंग 2024 भर रुकी रही, फिर मार्च 2025 में April Fools आइडिया के साथ दोबारा शुरू हुई

SSE और Go का Plan 9 सपोर्ट व्यवस्थित करना

  • 1999 में Intel Pentium III में आया SSE instruction set इस काम की एक प्रमुख शुरुआती वजह बना
  • Go compiler Plan 9 target पर SSE के उपयोग से बचने की कोशिश करता था
    • क्योंकि Plan 9 kernel note handler में SSE registers को save·restore नहीं करता था
    • Go compiler यह नहीं जान सकता था कि कौन-सा code note handler के अंदर चलेगा, इसलिए वह SSE को globally disable करना चाहता था
    • यह special handling अक्सर टूट जाती थी और compiler में जगह-जगह plan9 exceptions बढ़ गए थे
  • Russ Cox ने Plan 9 kernel को note handler में floating-point·SIMD context संभालने लायक बदला
    • 386 पक्ष में sys/src/9: allow floating point in note handlers संशोधन जोड़ा गया
    • amd64 9k kernel में fork के बाद FP state aliasing, note handler में SIMD, noted(NCONT) register loss जैसी अतिरिक्त समस्याएँ मिलीं
  • Go की तरफ Plan 9 code generation special-casing हटाने का काम हुआ, जिससे tailscaled अधिक देर तक चल सका

IPC और development environment

  • इसके बाद tailscaled stack corruption की जगह out-of-memory के कारण crash होने लगा
  • Plan 9 पर पहले की पोर्टिंग कोशिश में Tailscale के safesocket IPC package में अनंत goroutines बनाने वाला bug था
  • फिलहाल localhost TCP इस्तेमाल करने से यह समस्या हल हुई
    • यह Plan 9 के “everything is a file” तरीके से कम मेल खाता है, लेकिन यह पुष्टि हुई कि अन्य Plan 9 services भी localhost TCP इस्तेमाल करती हैं
    • आगे चलकर Russ द्वारा Go में पोर्ट किया गया srv9p package उपयोग कर LocalAPI बनाना बेहतर हो सकता है
    • मौजूदा implementation अन्य platforms की तरह localhost authentication नहीं जोड़ पाता, इसलिए साझा Plan 9 मशीनों पर इसका उपयोग न करने की चेतावनी दी गई है
  • शुरुआती development 9legacy CD image आधारित VM में हुआ, और binaries को HTTP से डाउनलोड कर चलाने की दोहराव वाली प्रक्रिया धीमी थी
  • Russ Cox का rsc/plan9 Plan 9 source, precompiled binaries और ./boot/qemu script शामिल करता है
    • qemu VM बिना डिस्क के boot करता है, और localhost 9P server द्वारा दिए गए Git repository को root filesystem की तरह उपयोग करता है
    • development machine और Plan 9 filesystem साझा होने से iteration time मिनटों से घटकर सेकंडों में आ गया
    • qemu ने virtio भी इस्तेमाल किया, जिससे गति और बढ़ी

नेटवर्क integration: TUN, routing, MagicDNS

  • शुरुआत में चलने वाला Tailscale userspace networking मोड में था, जो kernel network stack का उपयोग नहीं करता था
    • TCP, UDP, ICMP आदि gVisor के netstack से संभाले जाते थे
    • Plan 9 मशीन से tailnet तक पहुँचने के लिए tailscaled के HTTP/SOCKS5 proxy का उपयोग करना पड़ता था
    • Plan 9 के बहुत कम programs HTTP_PROXY या ALL_PROXY environment variables समझते हैं, इसलिए यह आदर्श नहीं था
  • Plan 9 का TUN-जैसा implementation बेहद सरल था
    • /net/ipifc/clone खोलकर नया interface number पढ़ा जाता है
    • control fd पर "bind pkt\n" लिखने से /net/ipifc/2/* जैसा नया interface बनता है
    • /net/ipifc/2/data खोलकर IP packets को सीधे पढ़ा और लिखा जाता है
    • अलग ioctl या length framing की ज़रूरत नहीं पड़ती
  • routing table manipulation भी /net/iproute file के माध्यम से होती है
    • "tag tail\n" लिखकर बाद में जोड़े जाने वाले routes पर tail tag लगाया जाता है
    • "add 100.64.0.0 /106 100.102.103.104" जैसे संदेश से route जोड़ा जाता है
    • क्योंकि Plan 9 अंदरूनी तौर पर IPv6-केंद्रित है और IPv4 को IPv4-mapped IPv6 address की तरह संभालता है, इसलिए CGNAT 100.64.0.0/10 को /106 की तरह दिखाया जाता है
  • MagicDNS का मकसद Plan 9 में peers को foo या foo.tailnet-name.ts.net जैसे नामों से एक्सेस योग्य बनाना था
    • /net/dns या /net/cs queries intercept करने के विकल्प पर भी चर्चा हुई
    • अंततः Russ ने Plan 9 में संशोधन किया ताकि खास DNS suffix के लिए वैकल्पिक DNS server निर्दिष्ट किया जा सके
    • DNS queries के गलत negative cache होने की समस्या भी ठीक की गई

Tailscale SSH और service collection

  • Tailscale SSH, tailscaled में built-in SSH server है, जो packet से जुड़ी WireGuard key के आधार पर ज्ञात Tailscale identity से authentication करता है
  • शुरुआत में Plan 9 shell /bin/rc को os/exec.Command से चलाकर stdin/stdout जोड़ा गया
    • shell चल गया, लेकिन echo, navigation और process interrupt जैसी चीज़ें ठीक से काम नहीं कर रही थीं
  • Russ ने netshell example को 9fans/go में जोड़ा
    • यह example एक बहुत असुरक्षित telnet server के काफ़ी करीब था, लेकिन Tailscale SSH के पीछे उपयोग के लिए पर्याप्त था
    • इसके बाद SSH से Plan 9 के /dev/snarf की सामग्री लाना, या laptop पर Go tests cross-compile करके SSH से चलाना आसान हो गया
  • Tailscale की optional service collection सुविधा की भी Plan 9 के हिसाब से समीक्षा की गई
    • /proc/NNN/fd को traverse करके /net/tcp/clone खोलने वाली processes खोजी गईं
    • fd के QID को /net/tcp/NNN/{status,local} से मिलाकर listening स्थिति और port की पहचान की गई
    • QID से TCP number निकालने का तरीका kernel implementation बदलने पर टूट सकता है, इसलिए यह एक कमज़ोर हिस्सा बना हुआ है

समय, वेब डेमो, v86

  • कुछ मामलों में gVisor netstack ने report किया कि monotonic time पीछे चला गया है, जिसके कारण tailscaled crash हुआ
    • Go के Plan 9 time implementation में monotonic time के रूप में wall time का उपयोग हो रहा था
    • जब ntpd घड़ी को पीछे समायोजित करता, तो netstack की monotonic time संबंधी धारणा टूट जाती
  • Russ ने Plan 9 के /dev/bintime में monotonic time जोड़ा और Go को उसका उपयोग करने के लिए संशोधित किया
  • वेब पर Plan 9 चलाने के लिए v86 का उपयोग किया गया
    • v86 WASM के जरिए 32-bit operating systems चलाता है और कई networking तरीके उपलब्ध कराता है
    • यही GOARCH=386 पर ध्यान देने की एक वजह भी थी
  • शुरुआत में Ethernet frames को websocket relay के जरिए भेजने के लिए Tailscale के network simulation environment में wsproxy protocol support जोड़ा गया
    • यह ARP, DHCP, DNS, NAT, control plane, DERP आदि को gVisor netstack के साथ emulate करने वाले integration test environment में काम करता था
    • लेकिन DHCP round-trip के कारण relay दूर होने पर Plan 9 GUI rio की शुरुआत धीमी हो जाती थी
  • बाद में WISP server भी implement किया गया, लेकिन production-ready बनाने से पहले समय कम पड़ गया, इसलिए copy.sh/v86 की default network relay setting के साथ रिलीज़ किया गया
  • Tailscale और Plan 9 वाला disk image 16MB का था, जबकि Tailscale binary unzip होने के बाद 23MB की थी
    • boot के समय “gunzip…” चरण दिखने का कारण यही है
    • example image copy.sh/v86 की 9legacy profile में शामिल है

बचे हुए काम और वास्तविक उपलब्धियाँ

  • फिलहाल Tailscale का Plan 9 पोर्ट केवल 9legacy पर टेस्ट किया गया है
    • Plan 9 के प्रमुख forks में न्यूनतम बदलाव वाला 9legacy और अधिक संशोधित 9front शामिल हैं
    • Russ ने 9legacy के लिए जो कुछ patches लिखे, उन्हें 9front पर पोर्ट करने की ज़रूरत पड़ सकती है
  • GOARCH=amd64 64-bit सपोर्ट को भी अभी validate करना बाकी है
  • exit node सपोर्ट और Go net/netns package सपोर्ट अभी implement नहीं किए गए हैं
    • इसके लिए Plan 9 पर Tailscale को अलग /net के रूप में प्रस्तुत करने जैसी दिशा में दोबारा सोचने की ज़रूरत हो सकती है
  • इस काम से Go का Plan 9 सपोर्ट भी बेहतर हुआ
  • खास तौर पर Go compiler से Plan 9 special-casing हटने से compiler अधिक सरल और maintain करना आसान हो गया
  • v86 demo जारी होने के समय v86 लेखक के April Fools मज़ाक के कारण VGA text output नकली Dutch जैसी दिख रही थी, लेकिन &nojoke query argument से इससे बचा जा सकता था

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-04-03
Hacker News की राय

  • अगर कुछ पूछना हो तो मैं जवाब दे सकता हूँ
    अभी कुछ लोग https://meet.google.com/qre-gydb-mkv पर इसी बारे में बात कर रहे हैं
    एडिट: एक घंटा बीतने के बाद सब जा चुके हैं
    पिछली 1 अप्रैल की ब्लॉग पोस्ट https://tailscale.com/blog/tailscale-enterprise-plan-9-suppo... थी

    • मैंने कभी कोई Plan 9 सिस्टम सेटअप नहीं किया है, लेकिन क्या इसे इस्तेमाल करके distributed system communication को अपने Tailnet के जरिए गुजार सकता हूँ?

  • Russ Cox ने इस मजाक को आखिर तक निभाया, यह सच में legendary है

    • काश कोई Russ को मना ले कि Plan 9 में एक पूरा web browser डालना बहुत मजेदार होगा

  • 9fans सूची में April Fools के लिए ऐसा कुछ पोस्ट हुआ था
    उसमें कहा गया था कि mips, 386, arm, arm64, amd64 जैसी अपरिपक्व computer architectures को maintain करने की लागत बहुत ज्यादा है, इसलिए वे ज्यादा परिपक्व और स्थिर architectures पर ध्यान केंद्रित करेंगे
    वे हैं power64 और itanium, और इसलिए power64 और itanium को छोड़कर बाकी सभी architectures को freeze और preserve किया जाएगा और end-of-life में promote कर दिया जाएगा

  • मजाक नहीं, सच में काश Plan 9 enterprise version होता
    इन दिनों मैं अपनी ज्यादातर scripts rc में लिख रहा हूँ, और क्योंकि हम nix इस्तेमाल करते हैं और dirnev से इसे अपने आप खींच सकते हैं, सहकर्मी इसे सहन कर रहे हैं; अनुभव काफी अच्छा रहा

    • मुझे इस बात से ज्यादा चिंता होगी कि दूसरे लोग rc scripts चला पाएंगे या नहीं, बल्कि यह कि क्या वे उन्हें पढ़ और modify कर पाएंगे
    • rc का एक फायदा यह है[1]:
      “rc के design में सबसे महत्वपूर्ण सिद्धांत यह है कि यह macro processor नहीं है। input को lexical और syntactic analysis code में कभी भी एक बार से ज्यादा scan नहीं किया जाता”
      पहले जिस Unix कंपनी में काम करता था, वहाँ running shell script modify हो जाने के कारण working disk का ज्यादातर हिस्सा मिट गया था। शुक्र है कि daily backups tape पर रखे थे, और यह करीब 17 साल पहले की बात है
      [1] https://www.scs.stanford.edu/nyu/04fa/sched/readings/rc.pdf
    • “enterprise Plan 9” से आप खास तौर पर क्या उम्मीद रखते हैं, थोड़ा और बता सकते हैं?

  • अगर पहली पोस्ट छूट गई हो और बस खुद test करके देखना चाहते हों, तो यह v86 image में चलता है:
    https://copy.sh/v86/?profile=custom&m=768&vram=16&hda.url=ht...
    VM के अंदर tailscaled और tailscale शुरू कर सकते हैं। proxy availability सीमित है, इसलिए online होने में थोड़ा समय लग सकता है
    एडिट: alt तीसरे button की तरह काम करता है। terminal शुरू करने के लिए alt दबाए रखते हुए right click करें, new चुनें, alt छोड़ें और right-click drag करके terminal window का size adjust करें

  • webinar चल रहा है (Google Meet) https://ftp.plan9.ts.net/webinar

    • जिन्हें दिलचस्पी रही होगी, उनके लिए बता दूँ कि अभी-अभी खत्म हुआ

  • मजाक का premise पसंद आया था, लेकिन explanation जितनी लंबी होती गई, अचानक उदासी-सी होने लगी
    बहुत कुछ टूटा हुआ है और complexity भी बहुत ज्यादा है। आखिर किसलिए—एक network tunnel बनाने के लिए? अगर यह extra work ही मजाक होता तो मजा आता

    • नया काम करने के लिए Plan 9 side पर थोड़ा काम जरूरी था, लेकिन actual Tailscale implementation में दूसरे Unix systems की तुलना में काफी कम मेहनत लगी
    • सुनने में लगता है कि इस काम से Go compiler भी बेहतर हुआ है, क्योंकि code में Plan 9 special handling कम हो गई

  • rsc, rob pike, bradfitz के साथ खासकर Plan 9 पर घंटों बैठकर बात कर सकता हूँ। बेशक इससे उनका समय पूरी तरह बर्बाद होगा
    वह operating system सच में fascinating है
    career की शुरुआत में एक expert साथ काम करते थे; वे मेरे पास बैठकर धैर्य से तरीका दिखाते और सवालों के जवाब देते, जब तक मैं ठीक से समझ न जाऊँ। यह ऐसा था जैसे गहरे पानी में डालकर भी तैरना सिखा दिया जाए, और तीन घंटे में किसी खास विषय में bachelor’s degree मिल गई हो—मेरे career की सबसे तेज growth में से एक
    मुझे C भी नहीं आती और Plan 9 को productively इस्तेमाल करने जितना भी नहीं जानता, लेकिन इसमें कुछ शानदार और उपयोगी features हैं जिन्हें और जानना-सीखना चाहता हूँ, कम से कम इसलिए कि आज के मुख्य तीन operating systems में उनकी कमी महसूस कर सकूँ
    अगर पैसे होते, तो Go की समझ बढ़ाने के लिए उन तीनों से सीधे बात करने का समय खरीदता, और Plan 9 को समझने के लिए—जिसकी हमेशा इच्छा रही पर खुद हासिल नहीं कर पाया—rsc और rob pike का समय भी खरीदना चाहता

  • Plan 9 मुझे सच में बहुत पसंद है। उसके कई principles लेकर अपना operating system बनाना मेरा retirement project और जीवन का लक्ष्य है
    एडिट: इस project का नाम “chaos10” reserve कर लिया है। SerenityOS की तरह कोई plan नहीं होगा

  • मुझे बिल्कुल उम्मीद नहीं थी कि इसे चलाने के लिए Plan 9 kernel तक patch करना पड़ेगा

    • क्यों नहीं? साफ है कि किसी ने भी ऐसी चीज को गंभीरता से पहले नहीं किया था, इसलिए जो missing work था वह तुलनात्मक रूप से कम ही दिखता है :)