क्यों इतने सारे अलग अलग Android kernels (तकनीकी जवाब कृपया)


17

क्या एंड्रॉइड एक सामान्य कर्नेल नहीं है जो सभी उपकरणों में उपयोग किया जाता है? उदाहरण के लिए CentOS डेल, एचपी, और अन्य हार्डवेयर पर स्थापित होगा। यकीन है कि वहाँ विभिन्न मॉड्यूल हैं, लेकिन यह अभी भी CentOS फिर भी है।

CyanogenMod हमेशा "टूटी" क्यों होता है? मैं हमेशा उन मंचों में सुनता हूं जो वे इस ड्राइवर या उस ड्राइवर को पोर्ट करने पर काम कर रहे हैं। यदि वे एक ही कर्नेल का उपयोग करते हैं तो क्या चालक इसके साथ काम नहीं करेंगे? मैं विभिन्न उपकरणों के लिए एक लाख विभिन्न प्रकार के कर्नेल भी देखता हूं।

जवाबों:


24

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

अपने आस-पास अच्छे से देखें, टचस्क्रीन की विविधताएं, वाईफाई चिपसेट की विविधताएं, उल्लेख नहीं करने के लिए, एक्सेलेरोमीटर, सेंसर, बैटरी, कम्पास, ध्वनि, ग्राफिक्स हैं।

उदाहरण के लिए एक कर्नेल स्रोत से एचटीसी लेना सैमसंग पर काम नहीं करेगा, और इसके विपरीत।

निर्माता चेरी-पिक या आउट-सोर्स विभिन्न बिट्स के लिए स्वतंत्र हैं जो सर्किट बोर्ड में शामिल हो जाते हैं। इसमें कोई कठोर या तेज़ नियम शामिल नहीं है। इसलिए कर्नेल को ठीक से काम करने के लिए बहुत सारे हैकिंग / संशोधन।

आपको कभी भी डेस्कटॉप लिनक्स वितरण कर्नेल की तुलना नहीं करनी चाहिए, जिसमें पीसीआई, पीसीआई-एक्सप्रेस, एसएटीए, वीजीए, एसवीजीए, यूएसबी, ईथरनेट हैं क्योंकि वे एक पूरी तरह से अलग बॉल-पार्क गेम हैं। CentOS के साथ और Android के लिनक्स कर्नेल के साथ प्रमुख अंतर यह है - सभी ड्राइवरों को या तो मॉड्यूल या बिल्ट-इन के रूप में संकलित किया जाता है, इसलिए कोई भी लिनक्स वितरण बस "बॉक्स से बाहर काम करेगा"। फिर से, डेस्कटॉप लिनक्स वितरण के साथ - आपके पास एक आर्किटेक्चर है - x86 इसलिए एक लिनक्स कर्नेल एक डेल पीसी से कहता है, लेनोवो पर बॉक्स से बाहर काम कर सकता है बशर्ते कि बोग-मानक ड्राइवर संकलित हों।

मत भूलो, एंड्रॉइड दुनिया में, विशिष्ट एआरएम चिपसेट के लिए बनाए गए कर्नेल की विविधताएं हैं, जैसे कि एआरएमवी 6, एआरएमवी 7, वहां टीईजीआरए, वहां एक्सिनोस हैं, और वे एक दूसरे के साथ द्विआधारी असंगत हैं। इसलिए यदि कोई कर्नेल TEGRA के लिए संकलित किया गया है, तो उसे भूल जाओ, यह ARMv7 पर काम नहीं करेगा!

एंड्रॉइड पर कुछ गुठली का कारण निर्माता को "टूट" दिखाई देता है। कुछ (Zte एक बहुत अच्छा उदाहरण है) एक कटा हुआ स्रोत जारी करते हैं जो स्रोत से संकलित कर सकता है लेकिन एक लापता ड्राइवर के कारण बूट करने में विफल रहता है जो GPLv2 या GPLv3 लाइसेंस द्वारा कवर नहीं किया गया है। यही समस्या है, इसलिए कुछ हैकर्स को कुछ सुरागों की तलाश में जीथब के आसपास चक्कर काटने पड़ते हैं; कुछ निर्माता, यदि सभी नहीं, अनुपालन करते हैं। Zte के स्रोत का वर्तमान अवतार शुद्ध रूप से 2.6.35.7 है, लेकिन वास्तव में इसके बहुत सारे संशोधनों के साथ 2.6.32.9 स्रोत आधार वास्तव में 2.6.35.7 के लिए वास्तविक कर्नेल स्रोत का प्रतिनिधित्व नहीं करता है!

यह वह जगह है जहां निर्माताओं को अपने संबंधित स्रोतों को जारी करना होता है, न कि केवल जीपीएलवी 2 या बाद के अनुपालन के कारण, बल्कि समुदाय के लिए इसे मॉडिफाई करने में सक्षम होना चाहिए, जैसे ओवरक्लॉकिंग क्षमताओं को जोड़ना।

इसलिए इसमें पर्दे के पीछे हैकिंग शामिल है और इसे चलाने के लिए कोशिश करने वाले ड्राइवरों के साथ बहुत खिलवाड़ होता है, और इसके लिए डिबग करना आसान नहीं है .. कुछ ड्राइवरों को क्रॉस-लाइसेंस प्राप्त किया जा सकता है, लेकिन खंड और शर्तों के आधार पर BUT वितरित नहीं किया जा सकता है बातचीत की।

शुक्र है, कि यह सब अब स्रोतों के कर्नेल 3.xx लाइन के साथ बदल गया है, क्योंकि एंड्रॉइड ड्राइवर अब मुख्यधारा के स्रोतों में एकीकृत हैं। लेकिन वहाँ एक gotcha है!

एक मौजूदा हैंडसेट को 3.xx कर्नेल पोर्ट करने का प्रयास करें जो लगभग 12-18 महीने पुराना है; नर्क में स्नोबॉल का मौका काम नहीं करेगा, ऐसा इसलिए है, क्योंकि अलग-अलग कारकों में, 3.xx स्रोत मोटे तौर पर 2.6.x स्रोत से भिन्न हैं और इसे काम करने के लिए बहुत हैकिंग लेंगे - मुझे पता होना चाहिए, कोशिश की है ज़ेट ब्लेड के लिए 2.6.38.6 स्रोत पोर्टिंग और विफल रहा।

इसी तरह, नवीनतम कर्नेल रिलीज 3.0.1 - जब मोडको पर ics4blade परियोजना पर काम कर रहे हैं, तो इसे पोर्ट करने के लिए कई प्रयास किए हैं लेकिन यह सरल तथ्य यह है कि Zte ने स्रोत की बहुत खराब गड़बड़ की है जो असंभव पर पोर्ट को जांघ प्रदान करता है ।


चारों ओर अपवित्र !!! विस्तृत उत्तर के लिए धन्यवाद।
user974896

आपका स्वागत है! कुछ भी आप को पता है की जरूरत है! : D
t0mm13b

आप जो कह रहे हैं उसमें से सभी को मॉड्यूल के रूप में संकलित नहीं किया गया है, लेकिन कर्नेल में ही एकीकृत किया गया है, इसलिए भले ही सीएम को एक डिवाइस पर काम करने वाला कर्नेल मिल जाए, लेकिन यह नए निर्माण के लिए बस "XXX मॉड्यूल को स्थानांतरित नहीं" कर सकता है और यह काम कर सकता है क्योंकि XXX मॉड्यूल्स नहीं हो सकते। ड्राइवरों को शिकार किया जाना चाहिए, हैक किया गया (संभवतः), और recompile।
user974896

2
सही है, और भी, ड्राइवर अलग हैं, इसलिए एक हैंडसेट पर टचस्क्रीन के लिए एक ड्राइवर दूसरे हैंडसेट पर काम नहीं करेगा जो एक अलग टचस्क्रीन का उपयोग करता है। नोट करने के लिए एक और मुख्य बिंदु - कुछ ड्राइवर कर्नेल संस्करण पर निर्भर हैं - Zte ने ब्लेड के लिए एथेरोस वाईफाई ड्राइवर का एक संस्करण निकाला है, और ड्राइवर तब तक काम नहीं करेगा जब तक कि कर्नेल 2.6.35.7 संस्करण के किसी अन्य संस्करण का न हो। वाईफाई ब्रेक - यह एक हैक किए गए तरीके से निर्भरता का प्रदर्शन करना है और उस तरह की चीजें करने का टूटा हुआ तरीका है।
t0mm13b

12

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

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

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

इसके अलावा, स्मार्टफोन्स आमतौर पर एसओसी पर आधारित होते हैं, जिसमें प्रोसेसर के साथ विशेष हार्डवेयर एकीकृत होता है। इनमें से कुछ के लिए, यह एक निश्चित ड्राइवर को लोड करने या न करने के मामले से अधिक हो सकता है; एक पूरे के रूप में कर्नेल को एक एसओसी पर चलने के लिए विशेष कॉन्फ़िगरेशन विकल्पों के साथ निर्मित करने की आवश्यकता हो सकती है, जो किसी अन्य एसओसी पर चलने के लिए आवश्यक विशेष विकल्पों के साथ असंगत हैं।


5

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

ड्राइवर प्रोग्रामिंग एप्लिकेशन प्रोग्रामिंग की तुलना में बहुत अधिक कठिन है, क्योंकि कोई कर्नेल नहीं है जो आपको चंचल हार्डवेयर से ढाल देता है जिसमें वास्तविक समय-समय की आवश्यकताएं होती हैं और ऐसा होता है, और इसका मतलब यह भी है कि अलग-अलग प्रदर्शन विशेषता होने के कारण ड्राइवर को याद नहीं हो सकता है। हार्डवेयर से कुछ कठिन वास्तविक समय की घटनाएं; ये मिस बग या प्रदर्शन के मुद्दों के रूप में सतह कर सकते हैं।

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

पीसी हार्डवेयर आम तौर पर मोबाइल हार्डवेयर से बेहतर मानकीकृत होते हैं, अधिकांश पीसी को वाइब्रेटर, एक्सेलेरोमीटर, जायरोस्कोप, 3 जी रेडियो, प्रॉक्सिमिटी सेंसर, एनएफसी आदि के लिए ड्राइवरों की आवश्यकता नहीं होती है। यहां तक ​​कि 3 जी वाले उपकरणों पर भी यह आमतौर पर मानकीकृत का उपयोग करके हार्डवेयर से जुड़ता है। PCMCIA या PCI-E जैसे कनेक्शन।


4

खैर .... ड्राइवर और कर्नेल बिल्कुल एक जैसे नहीं हैं।

ड्राइवर्स सेल एंटीना, वाईफाई, ब्लूटूथ इत्यादि को नियंत्रित करते हैं। ये मालिकाना ड्राइवर होते हैं क्योंकि निर्माता को अपने हार्डवेयर से बात करने के लिए एक रास्ता (ड्राइवरों) बनाना पड़ता है।

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

आपके द्वारा देखे जाने वाले सभी लाखों गुठली वास्तव में एक दूसरे से बहुत अलग नहीं हैं। आमतौर पर एक प्रोग्रामर / मोडर मौजूदा कर्नेल को ले जाएगा और इसे अलग करने के लिए कोशिश करेगा और इसे अलग प्रदर्शन मिलेगा। आप अनिवार्य रूप से कह सकते हैं कि वे केवल (अधिकांश भाग के लिए) कर्नेल के "कॉन्फ़िगरेशन" को समायोजित कर रहे हैं। एंड्रॉइड दुनिया में, ये मोड मुख्य रूप से सीपीयू घड़ी को देख रहे हैं या ओवरक्लॉकिंग कर रहे हैं (या तो बैटरी जीवन को बचाने के लिए महत्वपूर्ण है या वीडियो गेम इम्यूलेटर या वीडियो प्लेबैक जैसे अधिकांश प्रक्रिया गहन अनुप्रयोगों को चलाने की कोशिश कर रहे हैं), या वे नीचे देख रहे हैं- volting (अपने मूल सेट मापदंडों के बाहर अपने सीपीयू को चलाकर बैटरी जीवन को बचाने के लिए ... जो प्रभाव व्यक्ति में अलग-अलग होता है क्योंकि कोई भी दो सीपीयू 100% बिल्कुल समान नहीं बनाये जाते हैं)।


मेरा मतलब है कि CyanogenMod के साथ उदाहरण के लिए वहाँ हमेशा मेरे वाईफाई, ब्लूटूथ, आदि की शिकायतें काम नहीं करती हैं। क्यों इन ड्राइवरों को CyanogenMod के लिए "पोर्ट" किया जाना है। वे केवल स्टॉक ड्राइवर क्यों नहीं ले सकते, उन्हें डिवाइस पर कॉपी करें, और उन्हें CyanogenMod के साथ चलाएं
user974896

उपकरणों के लिए "स्टॉक" ड्राइवर जैसी कोई चीज नहीं है। हर डिवाइस में हार्डवेयर के लिए अलग-अलग ड्राइवर होते हैं जैसे कैमरा, वाईफाई चिप इत्यादि और वे आमतौर पर बंद स्रोत होते हैं इसलिए उन्हें ड्राइवरों को काम करने के लिए अपने तरीके से "हैक" करना पड़ता है।
रयान कॉनरेड

1
हां लेकिन हैक करने की जरूरत क्यों। यदि वे OEM कर्नेल के साथ काम करते हैं, तो आप ड्राइवर फ़ाइलों और संबद्ध पुस्तकालयों को Cyanogen mod स्थापना में स्थानांतरित नहीं कर सकते क्योंकि कर्नेल मूल रूप से समान है।
user974896

1

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


0

CentOS विभिन्न हार्डवेयर पर स्थापित होता है, लेकिन,

  1. यह सब पीसी है जो फोन से कम बदलता है,
  2. एक Ubuntu कर्नेल, डेबियन कर्नेल और एलिमेंटरी कर्नेल सभी अलग-अलग कर्नेल स्रोत हैं।

अपने दूसरे बिंदु के लिए, पहले से पोस्ट किए गए उत्तर देखें।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.