लिनक्स कर्नेल कोड की 15+ मिलियन लाइनें क्यों है? [बन्द है]

Question

इस अखंड कोड आधार की सामग्री क्या है?

मैं प्रोसेसर आर्किटेक्चर समर्थन, सुरक्षा और वर्चुअलाइजेशन को समझता हूं, लेकिन मैं कल्पना नहीं कर सकता कि 600,000 से अधिक लाइनें या ऐसा है।

ड्राइवर कोड में ऐतिहासिक और वर्तमान कारण क्या हैं?

क्या उन 15+ मिलियन लाइनों में हार्डवेयर के हर टुकड़े के लिए हर एक ड्राइवर शामिल है? यदि ऐसा है, तो फिर यह सवाल उठता है कि ड्राइवर कर्नेल में क्यों लगाए गए हैं और अलग-अलग पैकेज नहीं हैं जो ऑटो-डिटेक्ट किए गए हैं और हार्डवेयर से स्थापित हैं?

क्या कोड आधार का आकार भंडारण-बाधित या मेमोरी-विवश उपकरणों के लिए एक मुद्दा है?

ऐसा लगता है कि यह अंतरिक्ष-विवश एआरएम उपकरणों के लिए कर्नेल आकार को फूला होगा यदि यह सब एम्बेडेड था। क्या प्रीप्रोसेसर द्वारा बहुत सी लाइनें खींची गई हैं? मुझे पागल कहो, लेकिन मैं एक मशीन की कल्पना नहीं कर सकता जो मुझे समझने के लिए बहुत तर्क की जरूरत है कि मैं एक कर्नेल की भूमिकाएं हूं।

क्या यह प्रमाण है कि आकार 50+ वर्षों में एक मुद्दा होगा क्योंकि यह लगातार बढ़ती प्रकृति है?

ड्राइवरों को शामिल करने का मतलब है कि यह बढ़ेगा क्योंकि हार्डवेयर बनाया गया है।

संपादित करें : उन लोगों के लिए यह गुठली की प्रकृति है, कुछ शोध के बाद मुझे एहसास हुआ कि यह हमेशा नहीं है। कर्नेल को इस बड़े होने की आवश्यकता नहीं है, क्योंकि कार्नेगी मेलन के माइक्रो कर्नेल मैक को एक उदाहरण के रूप में सूचीबद्ध किया गया था 'आमतौर पर कोड के 10,000 लाइनों के तहत'।

Comments

2012 में वापस ड्राइवरों के लिए सिर्फ 5 मिलियन से अधिक लाइनें थीं। विभिन्न प्रोसेसर आर्किटेक्चर का समर्थन करने के लिए 1.9 मिलियन लाइनें। अधिक जानकारी h-online.com/open/features/...

— स्टीव

हां, मैंने एक भाषा के लिए एक कंपाइलर, लेक्सिकल एनालाइजर और बाइट कोड जनरेटर को कोडित किया है, और यह पूरी तरह से पुनरावृत्ति का इलाज कर रहा था और इसमें 10,000 लाइनें नहीं लगी थीं।

— जोनाथन

(अब इसे देखा, यह लगभग 2,700 लाइनें थी)

— जोनाथन

आपको यह make menuconfigदेखने और डाउनलोड करने के लिए कॉन्फ़िगर करना चाहिए कि बिल्डिंग से पहले कोड को कितना सक्षम / अक्षम किया जा सकता है।

— केसी

@JonathanLeaders: मैंने LISP के लिए 100 से कम लाइनों में भाषाओं की तरह पूर्ण संकलक का ट्यूरिंग किया है, जिसमें मांडेलब्रेट्स के परीक्षण कार्यक्रम प्रस्तुत किए गए हैं। हमेशा निर्भर करता है।

— आग्नेयास्त्र

Answer 1

ड्राइवर को कर्नेल में बनाए रखा जाता है, इसलिए जब किसी कर्नेल परिवर्तन के लिए किसी फ़ंक्शन के सभी उपयोगकर्ताओं के लिए वैश्विक खोज-और-(या खोज-और-हैंड-संशोधित) की आवश्यकता होती है, तो यह परिवर्तन करने वाले व्यक्ति द्वारा किया जाता है। एपीआई परिवर्तन करने वाले लोगों द्वारा आपके ड्राइवर को अपडेट किया जाना एक बहुत अच्छा लाभ है, इसके बजाय इसे स्वयं करें जब यह अधिक हाल के कर्नेल पर संकलन नहीं करता है।

विकल्प (जो कि आउट-ऑफ-ट्री बनाए गए ड्राइवरों के लिए होता है), यह है कि पैच को किसी भी परिवर्तन के साथ बनाए रखने के लिए इसके अनुरक्षकों द्वारा फिर से समन्वयित करना पड़ता है।

एक त्वरित खोज ने ट्री-इन-आउट-ऑफ-ट्री ड्राइवर विकास पर एक बहस छेड़ दी ।

जिस तरह से लिनक्स को बनाए रखा जाता है वह ज्यादातर मेनलाइन रेपो में सब कुछ रखकर होता है। छोटी स्ट्रिप्ड-डाउन गुठली का निर्माण #ifdefएस को नियंत्रित करने के लिए कॉन्फ़िगर विकल्प द्वारा समर्थित है । तो आप पूरी तरह से छोटे छीन-नीचे गुठली का निर्माण कर सकते हैं जो पूरे रेपो में कोड का केवल एक छोटा हिस्सा संकलित करते हैं।

एम्बेडेड सिस्टम में लिनक्स के व्यापक उपयोग से कर्नेल स्रोत का पेड़ छोटा होने पर सालों पहले लिनक्स की तुलना में सामान छोड़ने के लिए बेहतर समर्थन मिला है। एक सुपर-मिनिमम 4.0 कर्नेल संभवतः सुपर-मिनिमल 2.4.0 कर्नेल से छोटा होता है।

Comments

अब यह मुझे समझ में आता है कि सभी कोड को एक साथ रखना तर्कसंगत क्यों है, यह कंप्यूटर संसाधनों और अत्यधिक निर्भरता की कीमत पर मानव-घंटे बचाता है।

— जोनाथन

@JonathanLeaders: हाँ, यह बहुत सक्रिय रखरखाव के साथ ड्राइवरों के लिए बिट-रोट से बचा जाता है। मुख्य परिवर्तनों पर विचार करते समय संभवतः सभी ड्राइवर कोड के लिए भी उपयोगी है। कुछ आंतरिक एपीआई के सभी कॉलर्स पर खोज करने से एक ड्राइवर को इसे एक तरह से उपयोग करना बंद हो सकता है, जिसके बारे में आप नहीं सोचते थे, संभवतः आप जिस बदलाव के बारे में सोच रहे थे उसे प्रभावित कर रहे हैं।

— पीटर कॉर्ड्स

@JonathanLeaders xd पर आते हैं, जैसे कि अतिरिक्त लाइनें एक पीसी पर इसे स्थापित करने के आधुनिक माप में, अतिरिक्त जगह लेती हैं।

— जूनाग

@ जून: आपको एहसास है कि लिनक्स बहुत पोर्टेबल और स्केलेबल है, है ना? 32MB एम्बेडेड सिस्टम पर स्थायी रूप से उपयोग किए गए कर्नेल मेमोरी का 1MB बर्बाद करना एक बड़ी बात है। स्रोत कोड आकार महत्वपूर्ण नहीं है, लेकिन संकलित बाइनरी आकार अभी भी महत्वपूर्ण है। कर्नेल मेमोरी को पृष्ठांकित नहीं किया गया है, इसलिए स्वैप स्थान के साथ भी आप इसे वापस नहीं पा सकते हैं।

— पीटर कॉर्ड्स

@ रॉल्फ: यह बड़ा है, लेकिन यह स्पेगेटी नहीं है । वर्तमान में यह कोर कोड और ड्राइवरों के बीच 2-तरह की निर्भरता के बिना काफी अच्छी तरह से तैयार है। कोर कर्नेल को तोड़े बिना ड्राइवर को छोड़ा जा सकता है। जब एक आंतरिक फ़ंक्शन या एपीआई को फिर से चालू किया जाता है, तो ड्राइवरों को इसे अलग तरह से उपयोग करने की आवश्यकता होती है, ड्राइवरों को बदलने की आवश्यकता हो सकती है, लेकिन यह फिर से तैयार करने के लिए सामान्य है।

— पीटर कॉर्ड्स

Answer 2

3.13 के खिलाफ क्लॉक रन के अनुसार , लिनक्स कोड की लगभग 12 मिलियन लाइनें है।

• ड्राइवरों में 7 मिलियन LOC /
• आर्क में 2 मिलियन LOC /
• कर्नेल में केवल 139 हजार LOC /

lsmod | wc मेरे डेबियन लैपटॉप पर 158 मॉड्यूल रनटाइम पर लोड होते हैं, इसलिए गतिशील रूप से लोडिंग मॉड्यूल सहायक हार्डवेयर का एक अच्छा तरीका है।

मजबूत कॉन्फ़िगरेशन सिस्टम (जैसे make menuconfig) का उपयोग किस कोड को चुनने के लिए किया जाता है (और आपकी बात के लिए अधिक, कौन सा कोड संकलित नहीं करना है)। एंबेडेड सिस्टम अपनी स्वयं की .configफ़ाइल को केवल उन हार्डवेयर समर्थन के साथ परिभाषित करते हैं जिनकी वे देखभाल करते हैं (हार्डवेयर निर्मित में कर्नेल या लोड करने योग्य मॉड्यूल के रूप में समर्थन सहित)।

Comments

find /lib/modules/$(uname -r)/ -name '*.ko' | wc3,000 से थोड़ा अधिक कहते हैं। और एफडब्ल्यूआईडब्ल्यू, यह डेबियन है , "सार्वभौमिक ऑपरेटिंग सिस्टम," जो एक पूर्ण ऑपरेटिंग सिस्टम प्रदान करता है जिसे लिनक्स कर्नेल के आसपास निर्मित किसी भी आधुनिक कंप्यूटर पर काम करना चाहिए।

— ड्रयूबेंन

गिनती मॉड्यूल पर्याप्त नहीं है, शायद विन्यास द्वारा निर्मित बहुत कुछ है

— एलेक्स

मुझे लगता है कि इससे हम निष्कर्ष निकाल सकते हैं कि लिनक्स कर्नेल बड़े पैमाने पर है क्योंकि यह सभी प्रकार के डिवाइस कॉन्फ़िगरेशन का समर्थन करता है, इसलिए नहीं कि यह अपमानजनक रूप से जटिल है। हम यहां देखते हैं कि 15 मीटर लाइनों में से बहुत कम वास्तव में उपयोग में हैं। यद्यपि, लगभग सभी चीजें हैं, यह अत्यधिक जटिल हो सकता है, कम से कम हम रात में सो सकते हैं यह जानते हुए कि यह कारण है

— योनातान

@JonathanLeaders: Yes - और साथ ही साथ अजीब उपकरणों के लिए मॉड्यूल, अस्पष्ट फाइल सिस्टम, नेटवर्किंग प्रोटोकॉल, आदि के लिए मॉड्यूल हैं ...

— psmears

@JonathanLeader मुझे याद है जब लिनक्स शुरू हो रहा था - यहां तक ​​कि इंस्टॉलर को काम करने के लिए (यदि इसमें इंस्टॉलर भी था!) ​​एक बड़े पैमाने पर दर्द था - अभी भी कुछ विकृतियां हैं जहां आपको अपने माउस ड्राइवर को मैन्युअल रूप से चुनना होगा । नेटवर्किंग या ईश्वर की मनाही, एक्स-विंडो, काम जैसी चीजों को बनाना एक संस्कार था। मेरे पहले Red Hat इंस्टालेशन पर, मुझे अपने ग्राफिक्स ड्राइवर लिखना था, क्योंकि वहाँ केवल तीन (!) ड्राइवर उपलब्ध थे। मूलभूत रूप से मूल काम करना परिपक्वता का संकेत है - और जाहिर है, आप एक एम्बेडेड सिस्टम पर बहुत अधिक ट्विकिंग का खर्च उठा सकते हैं, जहां केवल कुछ एचडब्ल्यू संयोजन हैं।

— लुआं

Answer 3

किसी के लिए उत्सुक, यहाँ GitHub दर्पण के लिए linecount टूटने है:

=============================================
    Item           Lines             %
=============================================
  ./usr                 845        0.0042
  ./init              5,739        0.0283
  ./samples           8,758        0.0432
  ./ipc               8,926        0.0440
  ./virt             10,701        0.0527
  ./block            37,845        0.1865
  ./security         74,844        0.3688
  ./crypto           90,327        0.4451
  ./scripts          91,474        0.4507
  ./lib             109,466        0.5394
  ./mm              110,035        0.5422
  ./firmware        129,084        0.6361
  ./tools           232,123        1.1438
  ./kernel          246,369        1.2140
  ./Documentation   569,944        2.8085
  ./include         715,349        3.5250
  ./sound           886,892        4.3703
  ./net             899,167        4.4307
  ./fs            1,179,220        5.8107
  ./arch          3,398,176       16.7449
  ./drivers      11,488,536       56.6110
=============================================

driversलाइनकाउंट में बहुत योगदान देता है ।

Comments

यह तो दिलचस्प है। और भी दिलचस्प कोड में संभावित रूप से कमजोर बिंदु हैं, जहां प्रोग्रामर नाराज थे:grep -Pir "\x66\x75\x63\x6b" /usr/src/linux/ | wc -l

— jijij

@jimmij '\ x73 \ x68 \ x69 \ x74' इस ग्राउंडब्रेकिंग (यदि थोड़ा दिनांकित) शोध के अनुसार अधिक सामान्य हो सकता है ।

— निक टी

रैंडम तथ्य: वह फ़ोल्डर जो ओपी द्वारा अनुमानित 600 000 LOC के करीब है, दस्तावेज है।

— डेविड एमएच

./documentationकोड की 500,000 से अधिक लाइनें हैं? ....क्या?

— C_B

@C_B @ दाविद्म मुझे लगता है कि एक सीधी wcगिनती है, जिसे "कोड की पंक्तियों" की तुलना में सरल होने का लाभ मिला है :)

— drewbenn

Answer 4

अब तक के उत्तर "हां कोड बहुत है" प्रतीत हो रहे हैं और कोई भी सबसे तार्किक उत्तर के साथ प्रश्न का सामना नहीं कर रहा है: 15M +? तो क्या? मछली की कीमत के साथ स्रोत कोड की 15M लाइनों का क्या करना है? यह इतना अकल्पनीय क्या है?

लिनक्स स्पष्ट रूप से बहुत कुछ करता है। किसी भी चीज़ से बहुत अधिक ... लेकिन आपके कुछ बिंदु यह दर्शाते हैं कि जब इसका निर्माण और उपयोग किया जाता है तो आप इसका सम्मान नहीं करते हैं।

• सब कुछ संकलित नहीं है। कर्नेल बिल्ड सिस्टम आपको कॉन्फ़िगरेशन को जल्दी से परिभाषित करने की अनुमति देता है जो स्रोत कोड के सेट का चयन करता है। कुछ प्रायोगिक है, कुछ पुरानी है, कुछ की आवश्यकता हर प्रणाली के लिए नहीं है। को देखो /boot/config-$(uname -r)में (Ubuntu पर) make menuconfigऔर तुम सिर्फ कितना बाहर रखा गया है देखेंगे।

  और यह एक चर-लक्ष्य डेस्कटॉप वितरण है। एक एम्बेडेड सिस्टम के लिए विन्यास केवल उन चीजों में खींचेगा जिनकी उसे आवश्यकता है।

• सब कुछ बिल्ट-इन नहीं है। मेरे विन्यास में, कर्नेल की अधिकांश विशेषताएँ मॉड्यूल के रूप में निर्मित की गई हैं:

  grep -c '=m' /boot/config-`uname -r`  # 4078
  grep -c '=y' /boot/config-`uname -r`  # 1944
  

  स्पष्ट होने के लिए, इन सभी का निर्माण किया जा सकता है ... जिस तरह से उन्हें प्रिंट किया जा सकता है और एक विशाल पेपर सैंडविच में बनाया जा सकता है। जब तक आप असतत हार्डवेयर जॉब के लिए कस्टम बिल्ड नहीं कर रहे हैं (जिस स्थिति में आप इन वस्तुओं की संख्या पहले ही सीमित कर चुके हैं) तब तक इसका कोई मतलब नहीं होगा।

• मॉड्यूल गतिशील रूप से भरी हुई हैं। यहां तक ​​कि जब एक सिस्टम में हजारों मॉड्यूल उपलब्ध होते हैं, तो सिस्टम आपको केवल उन चीजों को लोड करने की अनुमति देगा जिनकी आपको आवश्यकता है। के आउटपुट की तुलना करें:

  find /lib/modules/$(uname -r)/ -iname '*.ko' | wc -l  # 4291
  lsmod | wc -l                                         # 99
  

  लगभग कुछ भी नहीं भरा हुआ है।

• Microkernels एक ही बात नहीं है। आपके द्वारा लिंक किए गए विकिपीडिया पृष्ठ पर अग्रणी छवि को देखने से सिर्फ 10 सेकंड में वे पूरी तरह से अलग तरीके से डिज़ाइन किए गए हैं।

  

  लिनक्स ड्राइवर आंतरिक रूप से (ज्यादातर गतिशील रूप से लोड किए गए मॉड्यूल के रूप में) होते हैं, उपयोगकर्तास्पेस नहीं, और फाइल सिस्टम समान रूप से आंतरिक होते हैं। बाहरी ड्राइवरों के उपयोग से क्यों बदतर है? सामान्य प्रयोजन कंप्यूटिंग के लिए माइक्रो बेहतर क्यों है?

---

टिप्पणियां फिर से उजागर करती हैं कि आप इसे प्राप्त नहीं कर रहे हैं। यदि आप असतत हार्डवेयर (जैसे एयरोस्पेस, एक TiVo, टैबलेट, आदि) पर लिनक्स को तैनात करना चाहते हैं, तो आप इसे केवल उन ड्राइवरों को बनाने के लिए कॉन्फ़िगर करते हैं, जिनकी आपको आवश्यकता है । आप अपने डेस्कटॉप पर भी ऐसा कर सकते हैं make localmodconfig। आप शून्य लचीलेपन के साथ एक छोटे उद्देश्य के लिए कर्नेल का निर्माण करते हैं।

उबंटू जैसे वितरण के लिए, एक एकल 40 एमबी कर्नेल पैकेज स्वीकार्य है। नहीं, रगडें कि, यह वास्तव में बड़े पैमाने पर संग्रह और डाउनलोड परिदृश्य के लिए बेहतर है कि 4000 + फ्लोटिंग मॉड्यूल को पैकेज के रूप में रखना। यह उनके लिए कम डिस्क स्थान का उपयोग करता है, संकलन-समय पर पैकेज करना आसान है, स्टोर करना आसान है और अपने उपयोगकर्ताओं के लिए बेहतर है (जिनके पास एक सिस्टम है जो बस काम करता है)।

भविष्य कोई मुद्दा नहीं लगता। सीपीयू की गति, डिस्क घनत्व / मूल्य निर्धारण और बैंडविड्थ में सुधार कर्नेल के विकास की तुलना में बहुत तेज लगता है। 10 साल में 200MB का कर्नेल पैकेज दुनिया का अंत नहीं होगा।

यह भी एक तरह से सड़क नहीं है। यदि यह अनुरक्षित नहीं है तो कोड को निकाल दिया जाएगा।

Comments

चिंता मुख्य रूप से एम्बेडेड सिस्टम के लिए है। जैसा कि आप दिखाते हैं, आपके पास अपने सिस्टम पर उपयोग करने के लिए 4,000 मॉड्यूल नहीं हैं। कुछ छोटे रोबोटिक्स या एयरोस्पेस अनुप्रयोगों में, (आरईएडी: सामान्य प्रयोजन कंप्यूटिंग नहीं) यह अस्वीकार्य अपशिष्ट होगा।

— जोनाथन

@JonathanLeaders मुझे लगता है कि आप उन्हें सुरक्षित रूप से हटा सकते हैं। डेस्कटॉप इंस्टॉल पर, वे वहां हैं जब आप अचानक एक यूएसबी पोर्ट में कुछ प्लग करते हैं, या कुछ हार्डवेयर कॉन्फ़िगरेशन को बदलते हैं, आदि

— डिडिएर ए।

हाँ बिल्कुल। मैं अभी भी मान्यताओं से आश्चर्यचकित हूं जैसे "आप किसी भी समय यूएसबी डिवाइस में प्लग कर सकते हैं इसलिए हमें कोड की 15m लाइनों की आवश्यकता है" कर्नेल स्तर पर लिखे गए हैं , और डिस्ट्रो स्तर पर नहीं, क्योंकि फोन और लिनक्स में लिनक्स का उपयोग किया जाता है। एम्बेडेड उपकरणों। खैर, मुझे लगता है कि डिस्ट्रो अपने आप में इस सूची को कम कर देता है। मुझे लगता है कि प्लगगैबिलिटी के लिए समर्थन एडिटिव होना चाहिए और घटिया नहीं होना चाहिए, आईई एक डिस्ट्रो पैकेज पैकेज जोड़कर इसे 'ऑप्ट-इन' की तरह करेगा, जैसा कि एम्बेडेड एआरएम कॉन्फ़िगरेशन के विपरीत कर्नेल को बताते हुए इसका एक प्रतिशत वर्तमान आकार है

— जोनाथन

@JonathanLeaders आप एक एम्बेडेड सिस्टम पर डेस्कटॉप के लिए कॉन्फ़िगर किया गया कर्नेल कभी नहीं चलाएंगे । हमारे एम्बेडेड सिस्टम में 13 मॉड्यूल हैं और हमने उन सभी हार्डवेयर समर्थनों को हटा दिया है जिनकी हमें आवश्यकता नहीं है (अन्य अनुकूलन के साथ)। डेस्कटॉप को एम्बेडेड सिस्टम से तुलना करना बंद करें। लिनक्स अच्छी तरह से काम करता है क्योंकि यह सब कुछ का समर्थन करता है और इसे केवल उसी चीज़ के लिए अनुकूलित किया जा सकता है जिसमें आप परवाह करते हैं। और उन 4k मॉड्यूल वास्तव में डेस्कटॉप सिस्टम पर बहुत अच्छे हैं: जब मेरा आखिरी लैपटॉप मर गया तो मैंने हार्ड ड्राइव को बहुत नए लैपटॉप में डाल दिया और सब कुछ बस काम किया ।

— ड्रयूबेंन

यह अन्यथा अच्छा / मूल्यवान जवाब एक अलग गुस्से और जुझारू लहजे से ग्रस्त है। -1।

— टाइपिया

Answer 5

टिनिऑनफिग बबल ग्राफ svg ( फिडेल )

शेल स्क्रिप्ट कर्नेल बिल्ड से json बनाने के लिए, http://bl.ocks.org/mbostock/4063269 के साथ उपयोग करें

---

संपादित करें : निकाली गई unifdefकुछ सीमा है ( -Iइसे अनदेखा और -includeअसमर्थित किया गया है, बाद वाले का उपयोग उत्पन्न कॉन्फ़िगरेशन हेडर को शामिल करने के लिए किया जाता है) इस बिंदु पर उपयोग करने से catबहुत बदलाव नहीं होता है:

274692 total # (was 274686)

स्क्रिप्ट और प्रक्रिया अपडेट की गई।

---

ड्राइवर, मेहराब आदि के अलावा बहुत सारे सशर्त कोड संकलित हैं या नहीं चुने गए कॉन्फ़िगरेशन के आधार पर, कोड आवश्यक रूप से गतिशील लोड मॉड्यूल में नहीं बल्कि कोर में बनाया गया है।

तो, linux-4.1.6 स्रोतों को डाउनलोड किया , टिनिऑनफिग को उठाया , यह मॉड्यूल को सक्षम नहीं करता है और मैं ईमानदारी से नहीं जानता कि यह क्या सक्षम करता है या उपयोगकर्ता रनटाइम में इसके साथ क्या कर सकता है, वैसे भी कर्नेल को कॉन्फ़िगर करें:

# tinyconfig      - Configure the tiniest possible kernel
make tinyconfig

कर्नेल का निर्माण किया

time make V=1 # (should be fast)
#1049168 ./vmlinux (I'm using x86-32 on other arch the size may be different)

कर्नेल बिल्ड प्रोसेस, छिपी हुई फाइलों *.cmdको कमांड लाइन के साथ बुलाया जाता है , जो .oफाइलों को बनाने के लिए इस्तेमाल किया जाता है , उन फाइलों को प्रोसेस करने के लिए और script.shनीचे दिए गए टारगेट और निर्भरता को कॉपी करने और खोजने के लिए उपयोग करने के लिए :

find -name "*.cmd" -exec sh script.sh "{}" \;

यह .oनामित लक्ष्य की प्रत्येक निर्भरता के लिए एक प्रति बनाता है.o.c

.c कोड

find -name "*.o.c" | grep -v "/scripts/" | xargs wc -l | sort -n
...
   8285 ./kernel/sched/fair.o.c
   8381 ./kernel/sched/core.o.c
   9083 ./kernel/events/core.o.c
 274692 total

.ह हेडर्स (सैनिटाइज्ड)

make headers_install INSTALL_HDR_PATH=/tmp/test-hdr
find /tmp/test-hdr/ -name "*.h" | xargs wc -l
...
  1401 /tmp/test-hdr/include/linux/ethtool.h
  2195 /tmp/test-hdr/include/linux/videodev2.h
  4588 /tmp/test-hdr/include/linux/nl80211.h
112445 total

Comments

@JonathanLeaders ने इस पर काम करते हुए मज़े किए, किसी को खुशी हुई

— एलेक्स

Answer 6

शुरू से ही सार्वजनिक रूप से तानानबौम और टॉर्वाल्ड्स के बीच अखंड गुठली के व्यापार पर बहस हुई थी। अगर आपको हर चीज के लिए यूजरस्पेस में पार करने की जरूरत नहीं है, तो कर्नेल का इंटरफ़ेस सरल हो सकता है। यदि कर्नेल अखंड है, तो यह आंतरिक रूप से अधिक अनुकूलित (और अधिक गन्दा!) हो सकता है।

हमारे पास काफी समय से एक समझौता के रूप में मॉड्यूल है। और यह डीपीडीके (कर्नेल से अधिक नेटवर्किंग कार्यक्षमता बढ़ाना) जैसी चीजों के साथ जारी है। अधिक कोर जोड़ा जाता है, उतना ही महत्वपूर्ण है कि ताला लगाने से बचें; इतनी अधिक चीजें यूजर्सस्पेस में चली जाएंगी और कर्नेल सिकुड़ जाएगा।

ध्यान दें कि अखंड गुठली एकमात्र समाधान नहीं है। कुछ आर्किटेक्चर पर, कर्नेल / यूजरस्पेस सीमा किसी भी अन्य फ़ंक्शन कॉल की तुलना में अधिक महंगी नहीं है, जिससे माइक्रोकर्नेल आकर्षक हो जाता है।

Comments

"कुछ आर्किटेक्चर पर, कर्नेल / यूजरस्पेस सीमा किसी भी अन्य फ़ंक्शन कॉल की तुलना में अधिक महंगी नहीं है" - दिलचस्प! वह कौन सी वास्तुकला होगी? अगर आप किसी भी तरह के मेमोरी प्रोटेक्शन को कम से कम नहीं छोड़ते हैं, तो इसे खींचने में अविश्वसनीय रूप से मुश्किल लगता है।

— वू

मैं इवान गोडार्ड के millcomputing.com वीडियो (मिल / बेल्ट सीपीयू, बहुत वीएलआईडब्ल्यू-जैसे) के माध्यम से चला गया। यह विशेष दावा एक केंद्रीय विषय है, और इसके निहितार्थ स्पष्ट नहीं हैं जब तक कि आप सुरक्षा वीडियो तक नहीं पहुंचते। यह सिमुलेशन में एक पीओसी वास्तुकला है, लेकिन यह शायद इस संपत्ति के साथ एकमात्र वास्तुकला नहीं है।

— रोब

आह कि यह बताते हैं। मेरे अनुभव में (और मैं सबसे पहले यह स्वीकार करूंगा कि मैं उस उद्योग का अनुसरण नहीं करता हूं) बहुत से सिम्युलेटेड आर्किटेक्चर हैं और कुछ अपने दावों पर खरा उतरते हैं जैसे ही रबड़ सड़क से टकराते हैं, यानी वे डालते हैं। असली हार्डवेयर पर। हालांकि इसके पीछे का विचार किसी भी मामले में दिलचस्प हो सकता है - पहली बार नहीं जब विशेष सीपीयू का उल्लेख किया गया हो। यदि आप कभी भी एक मौजूदा आर्किटेक्चर पाते हैं जिसमें यह संपत्ति है, तो मुझे वास्तव में दिलचस्पी होगी।

— वू

BTW यहाँ आपके द्वारा उल्लिखित बहस पर अधिक संसाधन हैं: en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate

— जोनाथन