Linux kernel का इतिहास: महत्वपूर्ण निर्णय और उनका प्रभाव

Linux kernel इतिहास का संक्षिप्त विवरण

Linux kernel का इतिहास सितंबर 1991 में version 0.01 से शुरू होकर आज सर्वर पर boot होने वाली 7.x series तक फैला है। release list इसका सबसे कम दिलचस्प हिस्सा है। कुछ चुनिंदा निर्णयों ने इसके स्वरूप को निर्धारित किया, और आज आप जो मशीन किराए पर लेते हैं, उन पर हर निर्णय का प्रभाव पड़ता है।

यहाँ दी गई तारीखें और version numbers kernel.org और उसके द्वारा प्रकाशित release history से लिए गए हैं। अगस्त 2026 तक की वर्तमान स्थिति यह है: 7.0 का आगमन 12 April 2026 को हुआ, 7.1 का 14 June 2026 को, और 7.2 अभी release candidates चरण में है।

1992 में GPL चुनने का महत्व आज भी क्यों है

Version 0.01 को 17 September 1991 को एक ऐसे लाइसेंस के तहत प्रकाशित किया गया था जिसे Torvalds ने स्वयं लिखा था। इसमें यह अनिवार्य था कि source code वितरित किया जाए, और इसमें एक ऐसी पंक्ति जोड़ी गई थी जो अधिक महत्वपूर्ण थी: "आप इसे शुल्क लेकर वितरित नहीं कर सकते, यहाँ तक कि 'हैंडलिंग' लागत के लिए भी नहीं।" 1991 में software floppy disks पर ship होता था, और floppy disks को copy करने और भेजने में खर्च आता था। उस clause ने एक commercial Linux distribution को असंभव बना दिया था।

उन्होंने इसे बदल दिया। GNU General Public License (GPL) पर जाने की घोषणा January 1992 में 0.12 release notes में की गई थी और यह 1 February 1992 से प्रभावी हुआ। March 1992 में Version 0.95, इसके तहत प्रकाशित होने वाला पहला release था। बाद में Linux पर बना हर व्यवसाय उसी बदलाव पर टिका है।

Kernel केवल GPL version 2 है, और यह कभी version 3 पर नहीं गया। Torvalds ने 2007 में इसे मना कर दिया था, जिसका मुख्य कारण GPLv3 में anti-tivoisation नियम था, जो यह अनिवार्य करता है कि GPL code के साथ ship होने वाला device उस code की modified copy को भी स्वीकार करे। उन्होंने locked hardware को निर्माता का निजी मामला माना। 2017 में kernel developers ने Kernel Enforcement Statement प्रकाशित किया, जो वैसे भी GPLv3 का एक हिस्सा उधार लेता है: यदि कोई व्यक्ति उल्लंघन के बारे में बताए जाने के बाद उसे ठीक कर देता है, तो उसका लाइसेंस बना रहता है, न कि पहली बार breach होने पर स्थायी रूप से समाप्त हो जाता है।

सर्वर पर इसके दो परिणाम होते हैं। जिस kernel binary को आप boot करते हैं, उसके साथ matching source का अधिकार जुड़ा होता है, इसलिए कोई भी आपको ऐसा Linux kernel नहीं दे सकता जिसे आप inspect या rebuild न कर सकें। और kernel पर मौजूद copyright notice यह कहता है कि लाइसेंस उन user programs को कवर नहीं करता जो सामान्य system calls के माध्यम से kernel services का उपयोग करते हैं, यही कारण है कि proprietary databases और monitoring agents बिना किसी नियम को तोड़े Linux के लिए ship होते हैं। एक permissive लाइसेंस विपरीत दबाव पैदा करता है, और किसी platform को चुनने से पहले उस अंतर को समझना आवश्यक है: देखें सर्वर प्लेटफॉर्म के रूप में Linux और FreeBSD।

व्यवहार में मोनोलिथिक कर्नेल क्यों सफल रहा

29 जनवरी 1992 को, Andrew Tanenbaum ने comp.os.minix न्यूज़ग्रुप पर "LINUX is obsolete" शीर्षक से एक संदेश पोस्ट किया। उन्होंने दो दावे किए। मोनोलिथिक कर्नेल, जहाँ ड्राइवर और फाइलसिस्टम एक विशेषाधिकार प्राप्त एड्रेस स्पेस के भीतर चलते हैं, 1970 के दशक का डिज़ाइन था, जबकि माइक्रोकर्नेल, जहाँ वे हिस्से सामान्य प्रक्रियाओं के रूप में चलते हैं, भविष्य थे। और Linux को Intel 386 के साथ जोड़ दिया गया था, इसलिए यह कभी पोर्टेबल नहीं होगा।

पोर्टेबिलिटी के दावे का उत्तर पोर्टिंग द्वारा दिया गया। मार्च 1995 में संस्करण 1.2 में Alpha, SPARC और MIPS जोड़े गए। जून 1996 में संस्करण 2.0 में 64-bit Alpha पोर्ट जोड़ा गया।

डिज़ाइन के दावे का उत्तर एक समझौते द्वारा दिया गया। Linux कभी माइक्रोकर्नेल नहीं बना। इसमें लोड करने योग्य कर्नेल मॉड्यूल (loadable kernel modules) आ गए: ये ऑब्जेक्ट फाइलें होती हैं जिन्हें आप एक चलते हुए कर्नेल में डालते हैं और फिर हटा देते हैं, इसलिए ड्राइवर कर्नेल बाइनरी से अलग वितरित (ship) होता है।

lsmod | head
modinfo virtio_net | head -5

lsmod वर्तमान में लोड की गई चीजों की सूची देता है। modinfo उस फाइल को प्रिंट करता है जहाँ से मॉड्यूल आया था और उन पैरामीटर्स को दिखाता है जिन्हें वह स्वीकार करता है। एक वर्चुअल सर्वर पर अधिकांश डिस्क और नेटवर्क पाथ मॉड्यूल होते हैं, यही कारण है कि एक कर्नेल इमेज ऐसे हार्डवेयर पर भी बूट हो जाती है जिसे उसने पहले कभी नहीं देखा।

मॉड्यूल ने माइक्रोकर्नेल डिज़ाइन की लागत के बिना वह लचीलापन प्राप्त किया। एक ड्राइवर को उसकी अपनी प्रक्रिया में अलग करने का मतलब है हर कॉल पर कॉन्टेक्स्ट स्विच और मैसेज की कीमत चुकाना, और 1992 में यह लागत बहुत अधिक थी।

Linux ने जिस लागत को बनाए रखा, उसी के अनुसार योजना बनानी पड़ती है: एक मॉड्यूल पूर्ण कर्नेल विशेषाधिकारों के साथ चलता है, इसलिए एक खराब मॉड्यूल केवल एक प्रक्रिया के बजाय पूरे मशीन को क्रैश कर देता है। आउट-ऑफ-ट्री मॉड्यूल यहीं समस्या पैदा करते हैं। एक वेंडर ड्राइवर जो मेनलाइन में नहीं है, उसे हर नए कर्नेल के साथ फिर से बनाना (rebuild) पड़ता है, जो कि अपग्रेड के दौरान DKMS करता है, और जब वह बिल्ड विफल हो जाता है, तो रीबूट के बाद डिवाइस बस गायब हो जाता है।

SMP को पूरा होने में पंद्रह साल क्यों लगे

जून 1996 में Linux 2.0 पहला ऐसा kernel था जिसने symmetric multiprocessing (SMP) का समर्थन किया, जिसका अर्थ है कि एक से अधिक CPU एक ही kernel को चला सकते हैं। पहले implementation में एक single lock, यानी big kernel lock (BKL) का उपयोग किया गया था, इसलिए एक समय में केवल एक ही processor kernel code के अंदर रह सकता था। परिणामस्वरूप, दूसरा CPU केवल उन workloads में मदद करता था जो user space में compute करते थे, और system calls वाले workloads में बहुत कम मदद मिलती थी, क्योंकि वे सभी एक ही lock के पीछे कतार में लग जाते थे।

उस lock को हटाने में पंद्रह साल लग गए। बचे हुए users को fine-grained locking में परिवर्तित किया गया, जिसका अधिकांश श्रेय Arnd Bergmann को जाता है, और BKL को 18 मई 2011 को release हुए 2.6.39 में हटा दिया गया। Scheduler भी इसी धीमी गति से आगे बढ़ा: 2.6.0 में O(1) scheduler, 2007 में 2.6.23 से Completely Fair Scheduler (CFS), और अक्टूबर 2023 में 6.6 में EEVDF, जिसने CFS की जगह ली।

यही कारण है कि आज 4 vCPU वाला plan सामान्य बात है। यह एक ऐसी सीमा को भी दर्शाता है जिसे जानना आवश्यक है। एक shared virtual server पर आपका kernel आपके threads को schedule करता है, और hypervisor आपके kernel को schedule करता है। top चलाएं और %st field को पढ़ें। Steal time वह CPU समय है जिसे आपका kernel उपयोग करने के लिए तैयार था लेकिन host ने उसे किसी अन्य guest को दे दिया, इसलिए आपके kernel के अंदर की कोई भी tuning इसे वापस नहीं ला सकती।

2.6 सीरीज ने कर्नल बिल्ड करने के तरीके को क्यों बदला

2.6 से पहले, वर्जन नंबर जोड़ों में आते थे। सम (even) दूसरा नंबर एक स्टेबल सीरीज (2.4) को दर्शाता था, और विषम (odd) नंबर डेवलपमेंट (2.5) को। 2.4 को 4 जनवरी 2001 को रिलीज किया गया था और 2.6 को 17 दिसंबर 2003 को, इसलिए उपयोगकर्ताओं को अगली स्टेबल सीरीज के लिए लगभग तीन साल इंतजार करना पड़ा। डिस्ट्रिब्यूशन इतना इंतजार नहीं कर सकते थे, इसलिए उन्होंने बैकपोर्टिंग की। दो वेंडर जो "2.4" शिप कर रहे थे, उनके कर्नल में हजारों पैच का अंतर था।

2.6 के बाद इस विभाजन को समाप्त कर दिया गया। मेनलाइन अब लगभग दो सप्ताह की एक मर्ज विंडो खोलती है, नया काम लेती है, फिर रिलीज कैंडिडेट्स चलाती है जब तक कि सब शांत न हो जाए, और हर 9 से 10 सप्ताह में शिप करती है, जो कि वह गति है जिसे kernel.org आज भी डॉक्यूमेंट करता है। इस मॉडल का दूसरा हिस्सा 4 मार्च 2005 को स्टेबल ट्री की पहली रिलीज के साथ आया, जो 2.6.11 का केवल फिक्स-ओनली अपडेट था, जिसे Greg Kroah-Hartman और Chris Wright द्वारा मेंटेन किया गया था। स्टेबल ट्री केवल फिक्स स्वीकार करता है और फीचर्स को मना कर देता है।

एक साइड इफेक्ट यह हुआ: वर्जन नंबर एक वादा नहीं रहा। 3.0, 4.0, 5.0 और 7.0 पूरी तरह से नए सिरे से लिखे गए वर्जन नहीं हैं। Torvalds पहले नंबर को तब बढ़ाते हैं जब दूसरा नंबर इतना बड़ा हो जाता है कि उन्हें परेशान करने लगे, यही कारण है कि अप्रैल 2026 में 6.19 के बाद 7.0 आया। सर्वर के लिए जो मायने रखता है वह यह है कि आपका डिस्ट्रिब्यूशन किस ब्रांच को ट्रैक करता है, और क्या उस ब्रांच को अभी भी फिक्स मिल रहे हैं।

अप्रैल 2005 में BitKeeper विवाद से git का जन्म कैसे हुआ

फरवरी 2002 से, 2.5 सीरीज की शुरुआत के साथ, kernel को Larry McVoy की कंपनी BitMover के proprietary distributed version control system, BitKeeper में विकसित किया गया था। BitMover ने kernel डेवलपर्स को कुछ शर्तों के साथ एक मुफ्त लाइसेंस दिया था: आप किसी प्रतिस्पर्धी version control टूल पर काम नहीं कर सकते थे, और आप BitKeeper को reverse engineer नहीं कर सकते थे। कई डेवलपर्स को एक ऐसे टूल के साथ मुफ्त kernel बनाना पसंद नहीं था जिसे पढ़ने की उन्हें अनुमति नहीं थी।

यह अप्रैल 2005 में टूट गया, जब Andrew Tridgell ने एक ऐसा प्रोग्राम प्रदर्शित किया जो BitKeeper repositories के साथ संवाद करता था। BitMover ने इसे reverse engineering कहा और मुफ्त लाइसेंस वापस ले लिया। विकास चक्र के बीच में ही kernel ने अपना version control system खो दिया।

git पर काम 3 अप्रैल 2005 को शुरू हुआ। Torvalds ने 6 अप्रैल को इसकी घोषणा की। 7 अप्रैल तक git self-hosting करने लगा था, जिसका अर्थ है कि git का अपना इतिहास पहले से ही git में रखा जा रहा था। कई branches का पहला merge 18 अप्रैल को चला। जून 2005 में, git ने 2.6.12 के release को manage किया। Torvalds ने जल्द ही रखरखाव का काम Junio Hamano को सौंप दिया और वापस kernel पर लौट गए।

इसका design सीधे समस्या से निकला: हजारों contributors, और ऐसे maintainers जो एक ऐसे नेटवर्क पर एक-दूसरे से कोड pull करते हैं जिस पर कोई भरोसा नहीं करता। प्रत्येक object का नाम उसकी सामग्री के hash द्वारा रखा जाता है, इसलिए पुराने इतिहास के एक byte को बदलने से उसके बाद के हर commit का नाम बदल जाता है। इसीलिए एक clone केवल एक दावा नहीं, बल्कि प्रमाण है। हर deploy pipeline, हर configuration repository, वह code host जहाँ अधिकांश टीमें push करती हैं और वह git server जिसे आप स्वयं चला सकते हैं, एक kernel के लाइसेंसिंग विवाद से ही विकसित हुए हैं।

LTS मॉडल क्या वादा करता है, और क्या नहीं

Mainline वह नहीं है जिसे आप run करते हैं। एक mainline release 9 से 10 सप्ताह बाद बदल दिया जाता है। Stable tree में प्रत्येक release के बाद कुछ सप्ताह तक fixes आते हैं। Longterm branches, जिन्हें आमतौर पर LTS लिखा जाता है, वर्षों तक fixes प्रदान करती हैं, और इन्हीं पर distributions आधारित होती हैं।

2.6.32, जिसे December 2009 में release किया गया था, वह version है जहाँ इस मॉडल ने खुद को साबित किया। RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 और Ubuntu 10.04 LTS सभी ने इसे ship किया था, और इस branch को February 2016 तक maintain किया गया, जो इसके आने के छह साल से अधिक समय बाद तक था।

यह वादा एक से अधिक बार बदला गया है। पहले यह दो साल था, फिर कुछ branches के लिए छह साल हो गया। 2023 में stable maintainers ने default अवधि को घटाकर वापस दो साल कर दिया, क्योंकि पुराने trees में backporting करने में maintainer का समय अधिक लगता है और पुरानी branches की वास्तविक testing बहुत कम होती है। 25 February 2026 को Greg Kroah-Hartman ने उन कंपनियों के साथ चर्चा के बाद, जो इन branches पर निर्भर हैं, फिर से लंबी projections प्रकाशित कीं, और वर्तमान framework तीन से छह साल तक चलता है।

[
  {
    "kernel": "5.10",
    "released": "2020-12-13",
    "eol_projected": "Dec 2026",
    "maintained_for": 6.0
  },
  {
    "kernel": "5.15",
    "released": "2021-10-31",
    "eol_projected": "Dec 2026",
    "maintained_for": 5.1
  },
  {
    "kernel": "6.1",
    "released": "2022-12-11",
    "eol_projected": "Dec 2027",
    "maintained_for": 5.0
  },
  {
    "kernel": "6.6",
    "released": "2023-10-29",
    "eol_projected": "Dec 2027",
    "maintained_for": 4.2
  },
  {
    "kernel": "6.12",
    "released": "2024-11-17",
    "eol_projected": "Dec 2028",
    "maintained_for": 4.1
  },
  {
    "kernel": "6.18",
    "released": "2025-11-30",
    "eol_projected": "Dec 2028",
    "maintained_for": 3.1
  }
]

kernel.org August 2026 तक 6 longterm branches को सूचीबद्ध करता है। सबसे पुरानी, 5.10, जब Dec 2026 में समाप्त होगी, तब तक इसमें 6.0 वर्षों तक fixes शामिल रहे होंगे। सबसे नई, 6.18, के Dec 2028 तक चलने का अनुमान है, जो कि 3.1 वर्षों के fixes हैं।

इन तारीखों को एक अनुबंध के बजाय एक न्यूनतम सीमा (floor) के रूप में पढ़ें। 6.6 और 6.12 की projections दोनों February 2026 में आगे बढ़ गईं, और जिस branch का उपयोग कोई नहीं करता उसे बंद भी किया जा सकता है। आपका distribution आमतौर पर आपके लिए यह चुनाव करता है: Debian 13 में 6.12 ship होता है, और Ubuntu 26.04 LTS में 7.0 ship होता है। वह अंतर ही सर्वर पर LTS बनाम interim release के प्रश्न का व्यावहारिक सार है, और जब आप Ubuntu 24.04 को 26.04 में upgrade करते हैं तो वास्तव में आपके नीचे यही बदलता है।

इससे एक समस्या उत्पन्न होती है। Ubuntu 24.04 पर uname -r कुछ इस तरह print करता है: 6.8.0-51-generic। यह एक upstream base है जिसमें distribution के अपने backports शामिल होते हैं, इसलिए यह संख्या आपको यह बताती है कि branch कहाँ से शुरू हुई थी, न कि यह कि इसमें कौन से fixes शामिल हैं। जो scanners kernel को उसके version string से परखते हैं, वे ठीक इसी कारण से distribution kernels के खिलाफ गलत alarms (false alarms) उत्पन्न करते हैं।

कर्नेल अभी किस विषय पर बहस कर रहा है

दो तर्क चल रहे हैं, और दोनों ही इस बारे में हैं कि काम किसे करना चाहिए।

Rust ने दिसंबर 2022 में 6.1 में इंफ्रास्ट्रक्चर के रूप में जगह बनाई। 7.0 में experimental लेबल हटा दिया गया, इसलिए कर्नेल की मुख्य भाषाएं C, assembly और Rust हैं, और बिल्ड के लिए अब nightly compiler की आवश्यकता नहीं है। विवाद रखरखाव (maintenance) को लेकर है। एक C मेंटेनर जो किसी इंटरफेस को बदलता है, वह उन Rust बाइंडिंग्स को तोड़ सकता है जिन्हें वह नहीं पढ़ता है, और बहस इस बात पर है कि उन्हें ठीक करने का काम किसका है।

दूसरा तर्क AI योगदान है। Sasha Levin ने जुलाई 2025 में एक नीति प्रस्तावित की, जब मशीन-सहायता प्राप्त पैच की बढ़ती मात्रा मेलिंग लिस्ट तक पहुँच गई। यह दस्तावेज़ 23 दिसंबर 2025 को कमिट किया गया था और अब यह कर्नेल के अपने प्रोसेस दस्तावेज़ में docs.kernel.org/process/coding-assistants.html पर उपलब्ध है। एक AI एजेंट को Signed-off-by टैग नहीं जोड़ना चाहिए, क्योंकि वह पंक्ति Developer Certificate of Origin (DCO) को प्रमाणित करती है और केवल एक व्यक्ति ही इसे प्रमाणित कर सकता है। सहायता की घोषणा Assisted-by: टैग के साथ की जाती है, जिसे समीक्षा के दौरान Co-developed-by: से बदल दिया गया था क्योंकि एक टूल लेखक नहीं होता है। जेनरेट किया गया कोड GPL-2.0-only के साथ संगत होना चाहिए। पैच भेजने वाला व्यक्ति इसकी समीक्षा करता है और इसके लिए जिम्मेदारी उठाता है।

नीति के पीछे का दबाव समीक्षा का समय है। पैच जेनरेट करने में सेकंड लगते हैं, और एक की समीक्षा करने में मेंटेनर की पूरी दोपहर लग जाती है। एक टैग उस असंतुलन को ठीक नहीं करता है। जो यह सुरक्षित रखता है वह है प्रोवेनेंस (provenance): इतिहास यह रिकॉर्ड करना जारी रखता है कि प्रत्येक बदलाव के लिए किसने हस्ताक्षर किए, जो कि वह संपत्ति है जिसे DCO 2004 में सुरक्षित करने के लिए पेश किया गया था।

किराए पर लिए गए सर्वर के लिए इस इतिहास का क्या अर्थ है

• लाइसेंस के कारण ही आप उस kernel को पढ़ और फिर से बना (rebuild) सकते हैं जिसे आपका प्रदाता (provider) बूट करता है, और इसी कारण इस पर proprietary software भी चलते हैं।
• monolithic डिज़ाइन के कारण ही एक driver bug पूरी मशीन को reboot कर देता है, और इसी कारण out-of-tree module को हर kernel upgrade पर फिर से बनाना पड़ता है।
• release model के कारण ही version number से आपको बहुत कम जानकारी मिलती है, जबकि branch और उसकी end-of-life तिथि आपको लगभग सब कुछ बता देती है।
• virtualisation का प्रकार यह तय करता है कि आप क्या कर सकते हैं: KVM पर आप अपना kernel बूट कर सकते हैं और modules लोड कर सकते हैं, जबकि container virtualisation में जो host kernel साझा करता है, uname -r host का version दिखाता है, modprobe विफल (fail) हो जाता है, और कई sysctls केवल read-only होते हैं।

FAQ

Linux kernel अभी भी GPLv2 पर क्यों है, GPLv3 पर क्यों नहीं?

Torvalds ने 2007 में GPLv3 के खिलाफ निर्णय लिया था, जिसका मुख्य कारण इसकी anti-tivoisation आवश्यकता थी। यह आवश्यकता किसी भी ऐसे डिवाइस को, जिसमें GPL कोड हो, उस कोड के संशोधित संस्करण को स्वीकार करने के लिए बाध्य करती है। वे locked hardware को निर्माता का निजी मामला मानते हैं। व्यवहार में relicensing लगभग असंभव है, क्योंकि kernel का copyright हजारों contributors के पास है और इसके लिए कोई assignment agreement मौजूद नहीं है। kernel केवल GPL-2.0-only है, इसलिए केवल GPLv3 के तहत पेश किए गए कोड को merge नहीं किया जा सकता।

क्या Linux kernel एक monolithic kernel है या microkernel?

यह loadable modules के साथ एक monolithic kernel है। Drivers और filesystems kernel के address space के भीतर चलते हैं, और lsmod वर्तमान में load किए गए modules को दिखाता है। इसका प्रभाव एक तरफ गति है और दूसरी तरफ blast radius: एक दोषपूर्ण module पूरी मशीन को panic कर सकता है, जबकि microkernel में केवल एक process प्रभावित होती है। 1992 के बाद से स्थिति में सुधार आया है, जिसमें user space में FUSE filesystems और eBPF programs शामिल हैं, जिन्हें kernel चलाने से पहले verify करता है।

Mainline, stable और longterm kernels में क्या अंतर है?

Mainline, Torvalds का tree है, जो हर 9 से 10 सप्ताह में release होता है, और नई सुविधाएँ सबसे पहले यहीं आती हैं। Stable, सबसे हालिया mainline release को लेता है और कुछ सप्ताह तक bug fixes प्राप्त करता है। Longterm branches वर्षों तक fixes प्राप्त करती रहती हैं, और इन्हीं पर distributions अपने kernels का निर्माण करती हैं। kernel.org प्रत्येक longterm branch की projected end-of-life तिथि के साथ सूची प्रदान करता है।

क्या Linux kernel AI द्वारा लिखे गए कोड को स्वीकार करता है?

हाँ, दिसंबर 2025 में लागू की गई एक नीति के तहत। tool का नाम Assisted-by: tag में होना चाहिए, AI agent को Signed-off-by line नहीं जोड़नी चाहिए, और उत्पन्न कोड GPL-2.0-only के साथ संगत होना चाहिए। मानव submitter sign off करता है, जिसका अर्थ है कि उन्होंने patch की समीक्षा की है और Developer Certificate of Origin के तहत इसकी जिम्मेदारी ली है।

मुझे सर्वर पर कौन सा kernel version चलाना चाहिए?

लगभग हर मामले में, वह version जिसे आपका distribution maintain करता है। एक distribution kernel एक longterm branch होता है जिसमें backported fixes और vendor की testing शामिल होती है, और आपके provider की images और support व्यवस्था इसी पर आधारित होती है। जब आपको किसी विशिष्ट driver या feature की आवश्यकता हो, तभी नया mainline kernel build करें, और जिस branch पर आप जा रहे हैं, उसकी end-of-life तिथि की जाँच अवश्य करें।