25 साल पुराने kernel driver को Claude Code से आधुनिक बनाना
(dmitrybrant.com)- ftape driver 1990 के दशक के backup tape (QIC-80) से डेटा रिकवर करने के लिए Linux का एकमात्र open source kernel driver है
- लेकिन इस driver का maintenance 2000 के बाद बंद हो गया, इसलिए इसे केवल पुराने Linux environments में ही इस्तेमाल किया जा सकता था
- Claude Code का उपयोग करके पुराने source code को आधुनिक Linux kernel के अनुसार refactor किया गया और इसे एक standalone kernel module में सफलतापूर्वक बदला गया
- इस प्रक्रिया में Claude ने अपने आप पुराने functions और structs को modern API में बदला, जबकि user ने output results को manually analyze करके कुछ configuration errors ठीक किए
- AI coding agent के उपयोग के अनुभव से programmer की क्षमता बढ़ाने और नई technologies व frameworks में तेज़ी से onboarding करने के बारे में insight मिली
पृष्ठभूमि: पुराने backup tapes की recovery और ftape driver
- QIC-80 जैसे tape cartridges से डेटा रिकवर करना लेखक के शौकों में से एक है
- इन tapes के लिए आमतौर पर floppy controller से जुड़े special tape drives की ज़रूरत होती है
- इन drives का उपयोग मुख्यतः 1990 के दशक में छोटे व्यवसायों या व्यक्तिगत users ने backup के लिए किया था
- floppy controller का उपयोग करने वाला यह तरीका अलग SCSI adapter के बिना सस्ते में लागू किया जा सकता था, लेकिन इसमें speed limit (500Kbps) और non-standard protocol जैसी कई कमियां थीं
- इन tape devices से communicate करने के लिए Linux में ftape kernel driver अनिवार्य है
- क्योंकि केवल ftape के जरिए ही शुद्ध raw binary data पढ़ा जा सकता है, इसलिए recovery के लिए यह ज़रूरी है
- लेकिन ftape driver का लगभग 2000 के बाद maintenance नहीं हुआ, इसलिए यह आधुनिक Linux kernel पर इस्तेमाल नहीं किया जा सकता था
- इस वजह से हर बार डेटा रिकवर करते समय पुराने Linux (जैसे CentOS 3.5) को सीधे boot करना पड़ता था
Claude Code के साथ kernel driver का modernization शुरू करना
- Claude Code से repository का विवरण देकर कहा गया: "driver को modernize करो ताकि यह latest kernel पर build हो सके"
- Claude ने मौजूदा kernel API और structure के अनुसार पुराने functions और structs को ढूंढकर बदला
- कई बार feedback और manual correction के बाद, error के बिना compile होने वाला driver code तैयार हो गया
- शुरुआती code केवल पूरे kernel source tree के भीतर ही build हो सकता था, लेकिन अतिरिक्त request पर Claude ने standalone external module build system भी अपने आप बना दिया
- इससे kernel module को अलग .ko file के रूप में बनाया जा सका और असली hardware connection के साथ testing शुरू हुई
समस्या समाधान की प्रक्रिया
- kernel module सही तरह load हो गया, लेकिन drive detection और communication में समस्या आई
- क्योंकि कुछ कामों के लिए sudo permission चाहिए थी, Claude इन्हें खुद बार-बार चला नहीं सकता था; इसलिए dmesg logs manually देकर समस्या को trace किया गया
- Claude ने logs और पहले के सफल मामलों की तुलना करके default I/O port address के unset होने और parameter initialization से जुड़ा bug ढूंढ निकाला
- default value -1 से 0xffff में बदल जाने के कारण detection fail हो रही थी; सही address फिर से सेट करके समस्या हल हुई
- अंततः module सही तरह load हुआ और test tape का data dump सफलतापूर्वक किया गया
AI coding agent के साथ collaboration से मिले संकेत
- Claude Code के साथ interaction "junior developer के साथ collaboration" जैसा लगा, मानो किसी असली engineer के साथ काम हो रहा हो
- user को architecture decisions, problem discovery और direction को सक्रिय रूप से lead करना पड़ता है
- domain-specific keywords और ठोस requests देने पर यह और प्रभावी होता है
- AI agent की productivity सही प्रकार के काम मिलने पर बहुत तेजी से बढ़ती है, इसलिए इसकी सीमाओं और strengths को समझना ज़रूरी है
- AI ने लेखक की क्षमता को कई गुना बढ़ा दिया। जो काम हाथ से करने पर कई हफ्ते लेता, वह सामान्य बातचीत और feedback के जरिए कुछ ही दिनों में पूरा हो गया
- इस प्रक्रिया में modern kernel development practices, x86 architecture, नए command-line tools जैसी वास्तव में उपयोगी skills भी सीखने को मिलीं
- यह भी ज़ोर देकर कहा गया कि नए frameworks (Rust, Flutter आदि) के लिए initial onboarding और adaptation की प्रक्रिया को यह काफी तेज़ कर देता है
निष्कर्ष: ftape फिर से जीवित
- 25 साल बाद ftape अब फिर से modern Linux पर build और उपयोग किया जा सकता है
- लेखक अतिरिक्त feature improvements और testing जारी रखे हुए हैं, और floppy-based drives के अलावा parallel port आधारित devices का support भी confirm किया गया है
- physical devices लगभग पहले जैसे ही हैं, लेकिन operating system अब CentOS 3.5 की जगह Xubuntu 24.04 हो गया है
संदर्भ
- ftape project source code GitHub पर सार्वजनिक रूप से उपलब्ध है
- लेखक की collected equipment list आदि उनकी personal blog पर देखी जा सकती है
1 टिप्पणियां
Hacker News टिप्पणियाँ
मैंने खुद मॉड्यूल लोड किया,
dmesgआउटपुट बार-बार कॉपी करके Claude में मैन्युअली पेस्ट कियाClaude को मुख्य रूप से इस्तेमाल करने की एक वजह यह है कि यह लंबे समय तक चलने वाली process शुरू कर सकता है, उसका output पढ़ सकता है, और उसी आधार पर debug कर सकता है
यहाँ इस मैन्युअल स्टेप को छोड़ने के कई hacky तरीके थे—जैसे
dmesgको किसी local UDP port पर pipe करना और Claude से listener शुरू करवानामुझे यह एक अच्छा use case लगता है
ऐसे tools इस्तेमाल करते समय मुझे दो बड़े effects दिखते हैं
पहला, जिन frameworks से मैं पहले से परिचित हूँ, उनमें Claude repetitive हिस्सों को जल्दी pattern-match करके productivity बहुत बढ़ा देता है
दूसरा, किसी नए framework को सीखते समय भी onboarding कहीं तेज हो जाती है—यह खास तौर पर उन बड़ी कंपनियों में बहुत मददगार है जहाँ अलग-अलग stacks इस्तेमाल होते हैं
AI की capabilities को सही तरह समझने के लिए तेजी से बदलती technologies और frameworks पर काफ़ी समय लगाना पड़ता है
अगर आपने Claude Code या Claude 4.0 को 100 घंटे से ज़्यादा इस्तेमाल नहीं किया है, तो हो सकता है आप इसकी संभावनाओं को पूरी तरह न समझ पाए हों
“कोडर नहीं होने वाला व्यक्ति अंदाज़े से coding करके मुसीबत में पड़ जाता है” वाला scenario X (पहले Twitter) पर आम हो सकता है, लेकिन कोई अनुभवी developer अगर लगातार समय लगाए तो उसका अनुभव बिल्कुल अलग होगा
यही असली point है
मैं Claude Code को रोज़ाना existing codebase में बदलाव करने के लिए अपने main tool की तरह इस्तेमाल करता हूँ
trial and error के बाद मैंने अपना एक process बना लिया है, और इसकी वजह से productivity और बड़े experiments करने की इच्छा दोनों काफ़ी बढ़ी हैं
खासकर जब मैं पहले से data structures, schema, और internal APIs design कर देता हूँ, तब Claude Code internal tools का UI लगभग एक ही बार में अच्छी तरह बना देता है—यह बात मुझे सच में बहुत पसंद है
इससे repetitive काम और framework complexity से हटकर abstract thinking पर ध्यान देना संभव हुआ है, और मेरे 16 साल के career में यह एक बड़ा turning point रहा है
सही बात
लेखक ने मूल रूप से Claude से Linux 2.4 driver को 6.8 पर port करने को कहा था
ऑनलाइन इससे जुड़ा काफ़ी material मौजूद है, इसलिए ज़्यादातर काम Claude ने कर लिया, और सिर्फ़ सच में जटिल core हिस्सों में लेखक की expertise की ज़रूरत पड़ी
“AI को अपनी skills को विस्फोटक रूप से amplify करने वाले tool की तरह इस्तेमाल करना” वाली बात यहाँ सच में महसूस होती है
अगर यहाँ आपकी अपनी capability 0 है, तो AI से गुणा करने पर भी नतीजा 0 के आसपास ही रहेगा, या शायद negative productivity भी मिल सकती है
हमारी टीम में भी ऐसे लोग हैं जो LLM के जरिए नए क्षेत्रों में bold तरीके से हाथ आज़माते हैं, लेकिन Claude 4 thinking agent सबको दे देने पर भी अक्सर बहुत अजीब code निकल आता है
अगर किसी ने अपने coding career का ज़्यादातर हिस्सा pattern matching में बिताया है, तो LLM agent उसी के ऊपर एक और layer of pattern matching जोड़ देता है; लेकिन जिन teammates के पास यह अनुभव नहीं है, उनके लिए यह उल्टा सिरदर्द बन जाता है
LLM agents इंसान की pattern matching को बहुत तेज़ कर देते हैं, लेकिन general sense में वे इंसानों से खास बेहतर नहीं लगते
यह सिर्फ़ नए frameworks explore करने में ही नहीं, बल्कि नई languages में भी काम आता है
हमारी टीम Ruby इस्तेमाल करती है, और Ruby इतनी readable है कि syntax अलग से सीखे बिना भी हम LLM से code लिखवा सकते हैं और सिर्फ़ decisions खुद लेते हैं
Ruby न जानते हुए भी टीम के acceptable standard का code तुरंत लिख पाना संभव हो जाता है, इसलिए अनजान environment में भी सीधे productive हुआ जा सकता है
(संदर्भ के लिए: teammates Pull Request review करते हैं)
“अपनी skills को विस्फोटक रूप से amplify करने वाला tool” वाली बात इस हफ्ते मुझे छोटे project को 10 बार दोहराकर बनाते हुए सच में महसूस हुई
AI से बने बिखरे हुए हिस्सों को मैं guide देकर markup, style, JS आदि में साफ़-सुथरे consolidation में बदलता हूँ—वहीं इसकी असली ताकत दिखती है
startup जैसे environments में, जहाँ coding conventions ढीले होते हैं, pattern-matching requests लागू करना मुश्किल होता है; लेकिन मज़बूत और mature codebase में इसका असर बिल्कुल अलग हो सकता है
मेरा मानना है कि prompts को जितना हो सके उतना specific, domain-specific keywords के साथ लिखना चाहिए
अगर किसी खास language या framework की technical understanding कम हो, तो prompt में ambiguity आ जाती है, और LLM उस खाली जगह को अपने हिसाब से भर देता है, जिससे नतीजा अक्सर आपकी मंशा से अलग निकलता है
यही ambiguity bugs की वजह बनती है
यही “विस्फोटक amplification” का दूसरा पहलू है
ऐसी बातें पढ़कर मुझे लगता है कि LLM आने से पहले demand के मुकाबले वास्तव में पूरा होने वाला काम बहुत कम था
मुझे अब भी लगता है कि bottleneck ‘execution’ नहीं, बल्कि ‘marketable ideas’ हैं
ऐसी चीज़ों की संख्या बहुत ज़्यादा नहीं होती जिनके लिए लोग सच में पैसे देना चाहते हों
समस्या हमेशा काम की कमी नहीं होती, बल्कि अक्सर ऐसे लोगों की कमी होती है जिनके पास वह काम करने के लिए ज़रूरी prior skills और experience हो
अगर kernel development का अनुभव नहीं है, तो prompt कितना भी अच्छा हो, लेखक जैसी उपलब्धि पाना मुश्किल है
सिद्धांत रूप में यह लग सकता है कि LLM की ताकत से सारे पुराने drivers को नए kernel में “modernize” किया जा सकता है, लेकिन व्यवहार में इसके लिए इंसानी supervision—वह भी skilled व्यक्ति की—ज़रूर पड़ेगी, और ऐसे experts की संख्या असल में maintain किए जाने वाले drivers की तुलना में बहुत कम है
Alan Kay और Joe Armstrong की एक अच्छी चर्चा और interview है, जिसमें वे इस समस्या का ज़िक्र करते हैं कि ज़्यादातर code बिना specification के target बदलकर compile कर देने के अंदाज़ में develop नहीं किया जाता
अगर code के अलावा कोई औपचारिक spec मौजूद होती, तो driver को नए kernel target पर ले जाना “spec को फिर से compile” करने जैसा आसान काम हो सकता था
लेकिन अभी आधार spec नहीं बल्कि पुराना code है, इसलिए पुराने code को modern code में ले जाते समय LLM सिर्फ़ मिलते-जुलते code की pattern matching करता है; वह असली meaning को समझकर guarantee नहीं देता—इसीलिए इंसानी skill ज़रूरी है
मुझे पहले से एहसास था कि AI की वजह से kernel hacking में entry barrier कम होगा
हर बार यह और ज़्यादा सच लगता है
जल्द ही embedded/ARM hardware support और व्यापक हो सकता है, और नए lightweight smart devices के लिए OS भी सामने आ सकते हैं
लेकिन ज़्यादातर लोग AI से ‘पूरा घर बनाकर दो’ कहते हैं, जबकि असल में इसे ‘हथौड़ा चलाने में मदद करने वाले’ tool की तरह इस्तेमाल करना ज़्यादा असरदार है
मुझे यह AI की भूमिका और सीमाओं को समझकर उसका सही इस्तेमाल करने वाले developer का अच्छा उदाहरण लगता है
खास तौर पर यह बात प्रभावशाली लगी कि skepticism की वजह से driver को अलग module के रूप में बनाया गया
मैं उस ‘महत्वपूर्ण संकेत’ पर बात करना चाहता हूँ जिसका ज़िक्र किसी और ने नहीं किया
लेखक ने साफ़ कहा कि “मुझे kernel modules का कुछ अनुभव है और मैं C अच्छी तरह जानता हूँ, इसलिए Claude के नतीजों को बढ़ा-चढ़ाकर नहीं देखना चाहिए”
यानी सच यह नहीं है कि सिर्फ़ तीन बार पूछते ही kernel module तैयार हो गया; कई बार बातचीत हुई और code को कई बार हाथ से भी ठीक किया गया
लेखक का कहना है कि kernel module की बुनियादी internal structure को समझे बिना modernize करना संभव ही नहीं था—यह वह context है जिसे किसी भी code generation tool के साथ हमेशा ध्यान में रखना चाहिए
उन्होंने यह भी लिखा कि Claude Code के साथ काम करने का एहसास “एक junior engineer के साथ काम करने” जैसा है; जो कहो वह कर देता है, और गलती बताओ तो तुरंत माफ़ी और तारीफ़ पर उतर आता है—यानी असली engineer से ज़्यादा एक flattering style जैसा
और आख़िर में, लेखक ने कहा कि “अगर सच में चाहता तो यह काम अकेले भी कर सकता था, लेकिन तब मुझे 25 साल पुराने kernel development तरीकों को फिर से सीखना पड़ता”
इससे फिर वही बात सामने आती है कि “legacy solution को सही तरह समझना और यह पहचानना कि वास्तव में क्या चाहिए” ही modernization का सार है
और निर्णायक बात यह है कि बिना सीखे आगे बढ़ जाना भी एक फ़ायदे के रूप में सामने आया—यह भी दिलचस्प है
मुझे यह बहुत अच्छा लगता है कि agent उन projects को समझा देता है जिन्हें मैं नहीं जानता
हाल ही में मैंने Firefox source clone किया और
qwen-codeइस्तेमाल करके Firefox की AI features और उनके implementation के बारे में पूछा, और बहुत शानदार तरीके से सीखासीखने का तरीका अब काफ़ी बेहतर और दिलचस्प हो गया है
मुझे यह लोगों को ज़्यादा सक्षम बनाने वाला बदलाव लगता है
लेखक लंबे समय से passion के साथ side projects करते आए हैं, और tools का upgrade होना सच में अच्छी बात है
लेकिन जब कोई क्षेत्र बहुत niche हो, तो community support कम हो सकती है; वहाँ LLM मदद करके custom समस्याओं का समाधान कर सकता है
धीरे-धीरे entry barrier कम हो रहा है, और कम technical background वाले लोग भी ज़्यादा सरल special-case समस्याएँ खुद हल कर पाएँगे
यह एक सकारात्मक बदलाव है जो और ज़्यादा लोगों को कोशिश करने लायक बनाता है
मुझे जानना है कि upgrade के बाद speed में क्या बदलाव आया