"लिनक्स कर्नेल विकास हित के क्लब में बात कर रहा है"

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




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

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

CRIU को किसके द्वारा और कहाँ लगाया जाता है?
प्रयोज्यता के रूप में, परियोजना अब "संक्रमणकालीन आयु" पर है। एक ओर, विभिन्न कंपनियों ने परियोजना में बहुत रुचि दिखाई। उदाहरण के लिए, सैमसंग, हुआवेई और यहां तक ​​कि हाल ही में Google के लोगों ने भी मुझे पहले से ही सुधार और परिवर्धन भेजा है। और जब से उन्होंने इसे भेजा है, इसका मतलब है कि वे इसके साथ कुछ करने की कोशिश कर रहे हैं। लेकिन, दूसरी ओर, सक्रिय उपयोग अभी तक नहीं देखा गया है, और यह स्पष्ट है कि क्यों।
परियोजना काफी जटिल है, और हमारे पास इसे स्थिर करने का समय नहीं है, इसलिए अभी तक इसे गंभीरता से उपयोग करना संभव नहीं है।

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

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

आपने कहा कि CRIU के लिए सभी आवश्यक सहायता कर्नेल 3.11 में होगी। पूर्ण CRIU समर्थन के लिए आज कर्नेल में क्या गायब है?
यदि हम आज के लिए सबसे हाल ही में कोर 3.10 लेते हैं, तो कोई दो चीजें नहीं हैं।
पहला, सबसे महत्वपूर्ण, एक सबसिस्टम है जो CRIU को ट्रैक करने की अनुमति देता है कि स्मृति के किन वर्गों में प्रक्रिया बदल रही है ताकि जब राज्य को फिर से हटा दिया जाए, तो यह अपनी सभी मेमोरी को कॉपी नहीं करता है, लेकिन केवल वही बदल सकता है जो बदल गया है। यह CRIU के लिए एक आवश्यक घटक नहीं है, लेकिन यह प्रक्रिया को तेज कर सकता है, उदाहरण के लिए, लाइव माइग्रेशन। कभी-कभी यह बहुत महत्वपूर्ण होता है, क्योंकि इस अनुकूलन के बिना यह संभव है, उदाहरण के लिए, एक प्रक्रिया को इतना लंबा स्थानांतरित करने के लिए कि इसका नेटवर्क कनेक्शन टूट जाएगा।
दूसरा भाग थोड़ा छोटा है, लेकिन एक मायने में यह पहले की तुलना में बहुत अधिक महत्वपूर्ण है। यह प्रक्रिया डिबगिंग सबसिस्टम का एक छोटा सा विस्तार है, जो आपको यह नियंत्रित करने की अनुमति देता है कि प्रक्रिया सिग्नल को कैसे संसाधित करती है। इसके बिना, राज्य को उन प्रक्रियाओं से हटाना असंभव है जो एक रोकी हुई स्थिति में हैं।
यह डरावना लगता है, लेकिन, सौभाग्य से, ऐसी परिस्थितियां अपेक्षाकृत दुर्लभ हैं, इसलिए सीआरआईयू अभी भी इसके बिना करता है।

CRIU के अलावा आप किन लिनक्स कर्नेल प्रोजेक्ट पर काम कर रहे हैं? आप किन गैर-लिनक्स कर्नेल परियोजनाओं में शामिल हैं?
गंभीरता से, लगभग नहीं और नहीं। मुझे OpenVZ, CRIU के भाग के रूप में क्या करना है, और लिनक्स कर्नेल के साथ हमारा एकीकरण पर्याप्त से अधिक है।

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

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

लिनक्स कर्नेल में OpenVZ कोड को एकीकृत करने की प्रक्रिया में क्या कठिनाइयाँ आईं? कर्नेल के किस संस्करण के साथ एकीकरण शुरू हुआ?
हम पहले ही भूल गए जब हमने पहला पैच भेजा था। मुझे यह भी याद नहीं है कि हमने किस सबसिस्टम की शुरुआत की थी। मुझे केवल यह याद है कि 2.6.18 कर्नेल में, जिसके आधार पर हमने एक स्थिर शाखा बनाई थी, हमारे पास पहले से ही कोड एकीकृत था।
मेरी राय में, ये नाम PID और SysVIPC थे। 2.6.32 तक, जिस पर हमारा अगला स्थिर संस्करण था, नेटवर्क वर्चुअलाइजेशन (नेट नेमस्पेस) और कुछ और एकीकृत थे।
इस तथ्य में कठिनाइयां पैदा हुईं कि मुझे विकास के लिए पूरी तरह से अलग तरीके से महारत हासिल करने के लिए "उड़ने के लिए" था। हमने मोटे तौर पर कल्पना की थी कि कर्नेल में पैच को एकीकृत करने की प्रक्रिया कैसी दिखती है। लेकिन, जब, पैच के मेरे पहले सेट के जवाब में, लोगों ने सक्रिय रूप से चर्चा करना शुरू कर दिया कि यह कैसे खरोंच से बदला जा सकता है, या सुझाव देने से पहले कि मैंने क्या किया, प्रक्रिया नियंत्रण उपतंत्र के एक अच्छे टुकड़े को फिर से लिखने के लिए, मैं भी भ्रमित था।

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

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

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

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

आप किस कर्नेल सबसिस्टम पर काम कर रहे हैं?
लगभग सभी लेकिन ड्राइवर। एक अर्थ में, यह समस्याओं में से एक है - आप किसी भी प्रणाली में गहराई से और पूरी तरह से गोता नहीं लगा सकते हैं, आपको लगातार सभी के विकास की निगरानी करनी होगी। सच है, "पसंदीदा" सिस्टम हैं - मेरे लिए यह एक नेटवर्क कोड और मेमोरी मैनेजमेंट सबसिस्टम है।

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

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

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

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

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

आप अपने काम में किस सॉफ्टवेयर का उपयोग करते हैं? कार्य वातावरण (GNOME, KDE, XFCE, आदि), ईमेल क्लाइंट (शायद वेब इंटरफ़ेस / मेल क्लाइंट का एक गुच्छा), वेब ब्राउज़र, संपादक, डेवलपर टूल (जैसे git)?
"ट्यून्ड" (हमेशा की तरह) फेडोरा लिनक्स। खैर, समानताएं उत्पादों, ज़ाहिर है। केडीई और गनोम मुझे पसंद नहीं है, मैंने तुरंत खुद को फ्लक्सबॉक्स डाल दिया। ग्राफ़िकल अनुप्रयोगों में से मैं थंडरबर्ड, क्रोम, स्काइप का उपयोग करता हूं। समय-समय पर, आपको अगले सम्मेलन के लिए स्लाइड खींचने की आवश्यकता है। अब तक, पर्याप्त OpenOffice सुविधाएँ।
बाकी (बच्चों के लिए भी कार्टून) टर्मिनल में चलते हैं।
वीआईएम संपादक, साथ ही मानक डेवलपर उपकरण - मेक, गिट, एसवीएन, जीसीसी, ओबजंप, जीडीबी।

क्या आप काम या व्यक्तिगत उद्देश्यों के लिए क्लाउड सेवाओं का उपयोग करते हैं? यदि हां, तो कौन सा?
गूगल + और हैंगआउट के अलावा, लगभग कुछ भी नहीं। मैं अक्सर इन सभी सेवाओं को "दूसरी तरफ से" देखता हूं ताकि हमारे क्लाउड उत्पादों पर प्रतिबिंब के लिए विषय मिल सकें, या सिर्फ "सामान्य विकास" के लिए।

कार्यस्थल कैसा दिखता है? क्या हार्डवेयर चुनने में कोई विशेष प्राथमिकताएँ हैं?
टेबल, कुर्सी, लैपटॉप। केवल एक हार्डवेयर वरीयता है - आईबीएम थिंकपैड में एक बहुत ही आरामदायक कीबोर्ड और ट्रैकपॉइंट है।

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

क्या आप विशेष सम्मेलनों में भाग लेते हैं? क्या आप प्रस्तुतियां देते हैं?
हां, साल में एक दो बार मैं लिनक्स कॉन्फ्रेंस में कुछ बात करता हूं। कभी-कभी मैं एक रिपोर्ट के बिना आता हूं, लेकिन फिर लक्ष्य एक तरह की "गोल मेज" में भाग लेना है। यह सामुदायिक जीवन का एक पहलू है, लोग ई-मेल के माध्यम से अधिकांश समय एक-दूसरे के साथ संवाद करते हैं और समय-समय पर इस तरह के "समारोहों" का आयोजन करते हैं ताकि उनकी समझ में सुधार हो सके।

क्या आप मंचों, चैट रूम में हैं?
लेकिन यह नहीं है। मेरे पास प्रोग्रामर हितों के बजाय एक विशिष्ट सर्कल है, आमतौर पर वे मंचों में ऐसी चीजों के बारे में नहीं पूछते हैं।

अक्सर, डेवलपर्स कहते हैं कि वे काम करते समय एक या दूसरे संगीत को सुनते हैं। आप इस बारे में कैसा महसूस करते हैं? आप किस तरह का संगीत सुन रहे हैं?
मैं "काम" पर निर्भर करता है। यदि यह कुछ नियमित है, जैसे कि प्रति दिन समाचार पत्र देखना, तो आप कुछ भी कर सकते हैं। यदि यह कोडिंग है, जिसके बारे में यह पहले से ही स्पष्ट है कि कोड क्या करना है, तो शब्दों के बिना संगीत, अन्यथा ध्यान केंद्रित करना मुश्किल है। अधिक बौद्धिक गतिविधि के लिए, मैं चुप्पी पसंद करता हूं।
और ऐसा लगता है कि मुझे संगीत में स्पष्ट प्राथमिकताएं नहीं हैं - ये क्लासिक्स, भारी संगीत और सोवियत पॉप-रॉक सेट और कुछ यादृच्छिक गाने हैं जो मैंने रेडियो पर सुने थे।

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

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

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

Pavel Emelyanov का जन्म 1982 में हुआ था। 2004 में, उन्होंने SWsoft के लिए काम करना शुरू किया, जिसे 2007 में नाम दिया गया था। 2005 में उन्होंने मास्को इंस्टीट्यूट ऑफ फिजिक्स एंड टेक्नोलॉजी से स्नातक किया। 2008 में उन्होंने अपनी थीसिस "बहु-उपयोगकर्ता वातावरण और वर्चुअलाइजेशन सिस्टम में मेमोरी खपत प्रबंधन प्रक्रियाओं के गणितीय मॉडलिंग" का बचाव किया, जो कि "गणितीय मॉडलिंग, संख्यात्मक तरीकों और कार्यक्रम परिसरों" में भौतिक और गणितीय विज्ञान का एक उम्मीदवार बन गया।
, Linux Parallels, OpenVZ CRIU. Parallels Linux.

, « »