सी # के बजाय ड्राइवर विकास के लिए सी क्यों उपयोग किया जाता है?

14

सी # कार्यक्रमों कर्नेल मोड (Ring 0) में नहीं चल सकता क्योंकि।

2010-10-14 07:07:38

+6

+1, लेकिन बस जोड़ने के लिए: विंडोज अब उपयोगकर्ता मोड ड्राइवरों का समर्थन करता है साथ ही एक सीमित विस्तार http: // www। microsoft.com/whdc/driver/wdf/UMDF.mspx –

+0

@ ब्रायन, हाँ यह एक अच्छी टिप्पणी है। –

+2

हालांकि, मुख्य रूप से प्रबंधित भाषा में सी # जैसे ओएस को विकसित करने के लिए शोध परियोजनाएं रही हैं। Http://en.wikipedia.org/wiki/Singularity_%28operating_system%29 देखें। – Brian

6

मुख्य कारण यह है कि सी ज्यादा बेहतर निम्न स्तर (हार्डवेयर के पास) से सी # विकास के लिए अनुकूल है। सी पोर्टेबल असेंबली कोड के रूप में डिजाइन किया गया था। साथ ही, कई बार सी # का उपयोग करने के लिए यह मुश्किल या असुरक्षित हो सकता है। कुंजी समय तब होता है जब ड्राइवर रिंग -0, या कर्नेल मोड पर चलाए जाते हैं। अधिकांश एप्लिकेशन .NET रनटाइम सहित इस मोड में चलाने के लिए नहीं हैं।

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

स्रोत

2010-10-14 07:09:22 Earlz

2

क्योंकि सी # एक उच्च स्तर की भाषा है और यह सीधे प्रोसेसर से बात नहीं कर सकता है। सी कोड सीधे मूल कोड में संकलित करें कि एक प्रोसेसर समझ सकता है।

स्रोत

2010-10-14 07:09:46

+6

सी # अप्रत्यक्ष रूप से देशी कोड पर संकलित करता है। प्रत्येक कंप्यूटर "अप्रत्यक्ष रूप से" प्रोसेसर को समझने में कुछ संकलित होता है। – Earlz

+1

@Earlz, लंबे समय से एम्बेडेड सिस्टम और ड्राइवर लड़के के रूप में, मेरे कर्नेल के अंदर एक जेआईटी या दुभाषिया को ढीला करने का विचार मुझे बेहद असहज बनाता है। मुझे यह जानने में काफी परेशानी है कि ड्राइवर उस पार्टी की जटिलता के स्तर को जोड़ने के बिना अपनी विलंबता आवश्यकताओं को पूरा करेगा। दूसरी ओर, मैं विंडोज़ में उपयोगकर्ता मोड ड्राइवरों और लिनक्स में FUSE जैसी चीजों की ओर रुख का स्वागत करता हूं। – RBerteig

-1

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

स्रोत

2010-10-14 07:10:20 kbvishnu

+3

यह सही नहीं है: http://msdn.microsoft.com/en-us/library/y31yhkeb.aspx – Moberg

2

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

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

प्रबंधित भाषाओं को किसी के द्वारा प्रबंधित किया जाना है। यह प्रबंधन शायद एक कार्यकारी अंतर्निहित ऑपरेटिंग सिस्टम पर निर्भर करता है। यह कई (लेकिन सभी नहीं) ड्राइवरों के लिए प्रबंधित कोड का उपयोग करने के लिए बूटस्ट्रैप समस्या उत्पन्न करता है।

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

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

स्रोत

2010-10-14 14:43:01 nategoose

0

यहां ईमानदार सत्य है। जो लोग हार्डवेयर या हार्डवेयर इंटरफेस में अच्छे होते हैं, वे बेहद परिष्कृत प्रोग्रामर नहीं होते हैं। वे सी जैसी सरल भाषाओं से चिपके रहते हैं। अन्यथा, ढांचे का विकास हुआ होगा जो सी ++ या सी # जैसी भाषाओं को कर्नेल स्तर पर इस्तेमाल करने की अनुमति देगा। संपूर्ण ओएस सी ++ (ECOS) में लिखा गया है। तो, आईएमएचओ, यह ज्यादातर परंपरा है।

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

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

स्रोत

2010-10-14 15:10:51 Ziffusion

1

बस डारिन डिमिट्रोव के जवाब को थोड़ा सा बनाने के लिए। हां सी # प्रोग्राम कर्नेल मोड में नहीं चल सकते हैं।

लेकिन वे क्यों नहीं कर सकते?

कोड के पीछे पैट्रिक दुसुद के interview में उन्होंने Vista के विकास के दौरान किए गए प्रयास को निम्न स्तर * में सीएलआर शामिल करने के लिए किए गए प्रयास का वर्णन किया। जिस दीवार पर उन्होंने मारा था वह था कि सीएलआर ओएस सुरक्षा पुस्तकालय निर्भरता लेता है जो बदले में यूआई स्तर पर निर्भरता लेता है। वे Vista के लिए इसे हल करने में सक्षम नहीं थे। एकवचन के अलावा मुझे ऐसा करने के किसी भी अन्य प्रयास की जानकारी नहीं है।

* ध्यान दें कि सी # में ड्राइवरों को लिखने में सक्षम होने के लिए "निम्न स्तर" पर्याप्त नहीं हो सकता है, यह बहुत कम आवश्यक था।

स्रोत

2010-10-14 15:57:04

सी # के बजाय ड्राइवर विकास के लिए सी क्यों उपयोग किया जाता है?

उत्तर

संबंधित मुद्दे