वर्शन: 1.0.2
पिछली बार अपडेट किए जाने की तारीख: 12-03-2025
बहुत ज़्यादा शब्द हैं, पढ़ा नहीं गया
इस दस्तावेज़ में, आने वाले समय में होने वाले प्रोजेक्ट के लिए, वेंडर fwupd को कैसे लागू कर सकते हैं, इस बारे में बताया गया है. इसमें LVFS के रखरखाव करने वालों के सीधे तौर पर दिए गए कोटेशन भी शामिल हैं. Fwupd, फ़र्मवेयर अपडेट करने के लिए ओपन सोर्स फ़्रेमवर्क है. इससे, बाहरी वेंडर के साथ मिलकर फ़र्मवेयर अपडेट करने के तरीके को एक ही जगह पर मैनेज करने में मदद मिलती है.
पहला चरण - जानकारी इकट्ठा करना और दिशा-निर्देश देना
वेंडर के लिए - सबसे पहले पूछें:
अपडेट किए जा सकने वाले कॉम्पोनेंट के बारे में सवाल
अपडेट का साइज़
अपडेट का समय
अपडेट का मौजूदा टाइप (A/B या बूटलोडर/रनटाइम मॉडल)
अपडेट के दौरान, कॉम्पोनेंट की मुख्य सुविधाओं पर क्या असर पड़ता है?
अपडेट का इस्तेमाल शुरू करने के लिए, सिस्टम में क्या करना होगा?
क्या एक से ज़्यादा कॉम्पोनेंट को किसी खास क्रम में इंस्टॉल करना ज़रूरी है?
LVFS/fwupd के साथ काम करने की जानकारी या इसके बारे में जानकारी
प्लग इन लागू करने में मदद करने के लिए, इंजीनियरिंग संसाधन को कमिट करने की सुविधा (ज़्यादा जानकारी के लिए नीचे देखें)
LGPLv2+ (कोड, जो फ़र्मवेयर को कॉम्पोनेंट में लिखता है) के लिए, प्लग इन को ओपन सोर्स करने का वादा करना और LVFS की मदद से फ़र्मवेयर को फिर से डिस्ट्रिब्यूट करने की अनुमति देना
वेंडर के लिए - शुरुआती दिशा-निर्देश:
अपडेट के दौरान, पेरिफ़रल या इंटरनल कॉम्पोनेंट की फ़ंक्शनैलिटी पर पड़ने वाले असर को कम से कम किया जाना चाहिए. आम तौर पर, यह समय कुछ सेकंड का होना चाहिए. अपडेट का ज़्यादातर हिस्सा, बैकग्राउंड में बिना किसी रुकावट के होना चाहिए, ताकि उपयोगकर्ता को परेशानी न हो
- अगर यह पेरिफ़रल, उपयोगकर्ता अनुभव पर साफ़ तौर पर असर डालता है (उदाहरण के लिए, डिसप्ले काम करना बंद कर देता है), तो यह ज़रूरी शर्त और भी सख्त हो जाती है
इस तरह के अपडेट को चालू करने के लिए, A/B अपडेट का सुझाव दिया जाता है
- A/B अपडेट, उपयोगकर्ता को होने वाली परेशानी को कम करने के लिए सबसे सही होते हैं. ये अपडेट, डिवाइस को अनप्लग करने पर चालू हो सकते हैं
अपडेट को वापस पाया जा सकता हो - अगर डिवाइस को बंद किया जाता है, डिवाइस से बाहरी डिवाइस को अनप्लग किया जाता है वगैरह, तो अपडेट की वजह से डिवाइस या बाहरी डिवाइस काम करना बंद नहीं करना चाहिए. यह ऐसा होना चाहिए जिसे उपयोगकर्ता की कार्रवाई के बिना ठीक किया जा सके.
- शुरुआती तौर पर यह मान लेना चाहिए कि पूरे अपडेट के दौरान, उपयोगकर्ता की कोई कार्रवाई नहीं होती. अपडेट की सही स्क्रिप्ट और चरणों को अपने-आप चलाया जाना चाहिए
दूसरा चरण - fwupd का इस्तेमाल करना
अगर किसी वेंडर ने कभी fwupd का इस्तेमाल नहीं किया है
Chrome OS, OEM को fwupd के ज़रिए फ़र्मवेयर अपडेट की ज़रूरी शर्तें देता है. OEM को इसकी जानकारी सीधे चिप / कॉम्पोनेंट सप्लायर को देनी चाहिए
कुछ मामलों में, ओडीएम, चिप वेंडर के साथ सीधे तौर पर इंटरफ़ेस करने में OEM की मदद कर सकता है. OEM की यह ज़िम्मेदारी है कि वह इन ज़रूरी शर्तों के बारे में जानकारी दे
कृपया ध्यान दें कि अगर LGPLv2+ लाइसेंस के साथ सोर्स कोड दिया जाता है, तो आम तौर पर इस कोड से प्लग इन बनाना मुमकिन नहीं होता. इसकी वजह यह है कि इसमें कई जटिल चीज़ें होती हैं. इसलिए, इस स्थिति में चिप वेंडर के पास ऐसा कोई व्यक्ति होना चाहिए जो fwupd के रखरखाव करने वालों और Google के इंजीनियरों के साथ काम कर सके.
OEM, चिप के वेंडर से यह वादा करने में मदद कर सकता है कि वे रखरखाव करने वालों के साथ मिलकर काम करेंगे. वेंडर की ओर से इंजीनियरिंग सहायता पाने के लिए, ये ज़रूरी शर्तें पूरी करनी होंगी:
अपडेट किए जा सकने वाले हार्डवेयर कॉम्पोनेंट की समस्याओं और डिज़ाइन की सुविधाओं के बारे में काफ़ी जानकारी हो. साथ ही, यह भी ज़रूरी है कि आप उसी टीम में शामिल हों जिसने फ़र्मवेयर लिखा है
आम ओपन सोर्स लाइसेंस (उदाहरण के लिए, LGPLv2 और MIT) के बीच का अंतर समझना
C प्रोग्रामिंग भाषा में अच्छी तरह पारंगत हों. साथ ही, GLib और GObject के बारे में बुनियादी जानकारी हो. खास तौर पर, GErrors के बारे में भी जानकारी हो
आपके पास GitHub खाता हो और आपको पुल अनुरोध खोलने और अपडेट करने, GitHub कोड की समीक्षा करने, और fwupd के साथ काम करने वाले सभी टूल (जैसे, चंकिंग, अटैच/डिटैच, डिवाइस फिर से कोशिश करना, एचआईडी वगैरह) के साथ fwupd के स्ट्रक्चर के बारे में पता हो
ज़रूरी नहीं: यूनाइटेड किंगडम में हार्डवेयर के सैंपल भेजने की सुविधा - यह सुविधा, fwupd के रखरखाव करने वालों के लिए काफ़ी काम की है. इससे वे वेंडर को समस्याओं को डीबग करने में मदद कर सकते हैं. साथ ही, हर रिलीज़ पर चलाए जाने वाले fwupd टेस्ट में बोर्ड को जोड़ सकते हैं. डेवलपमेंट ब्रैंच में रिग्रेशन को रोकने के लिए, बाद वाला तरीका ज़रूरी है.
साथ ही, OEM, fwupd मेलिंग सूची या सीधे रिचर्ड ह्यूजेस (hughsient@gmail.com) के ज़रिए बातचीत शुरू कर सकता है. साथ ही, प्लग इन कोड लिखने से पहले प्लान पर चर्चा कर सकता है
अगर कोई कंपनी छोटी है और उसके पास इंजीनियरिंग से जुड़े संसाधन कम हैं या ओपन सोर्स के बारे में उसकी समझ कम है, तो यहां दिया गया सुझाव मददगार हो सकता है:
कॉम्पोनेंट वेंडर, ओपन सोर्स के काम से जुड़ी सलाह देने वाली कंपनियों का इस्तेमाल कर सकता है. हालांकि, इसके लिए कोई अतिरिक्त शुल्क नहीं देना होगा
इस सुझाव से, बड़े पैमाने पर काम करने में मदद मिल सकती है. हालांकि, अगर वेंडर खुद यह काम करता है, तो इंजीनियर इस प्रोसेस के बारे में जान पाते हैं. साथ ही, वे आने वाले समय में नए हार्डवेयर के लिए VID/PID को आसानी से जोड़ पाते हैं. हार्डवेयर पर डीबग करने के लिए, सवालों / समस्याओं को हल करना भी तेज़ी से किया जा सकता है
तीसरा चरण - आखिरी चरण
आखिर में, कोड को fwupd में शेयर की गई सभी सुविधाओं का इस्तेमाल करके, समीक्षा किए जा सकने वाले छोटे-छोटे कमिट में रीफ़ैक्टर किया जाता है
प्रोसेस पूरी होने के बाद, प्लग इन को अपस्ट्रीम में मर्ज कर दिया जाता है
अपस्ट्रीम में इस्तेमाल किया गया कोड, ChromeOS में भी वही होगा
ChromeOS के बाहर इस्तेमाल होने वाले फ़र्मवेयर अपडेट की बाइनरी, LVFS पर उपलब्ध कराई जाएंगी
खास तौर पर, ChromeOS के मामले में:
OEM को सीपीएफ़ई के ज़रिए, फ़र्मवेयर बाइनरी को हमारे सर्वर पर अपलोड करना होगा
हार्डवेयर रिग्रेशन टेस्ट के काम करने के लिए, LVFS पर अब भी फिर से डिस्ट्रिब्यूट किए जा सकने वाले अपडेट कैबिनेट के संग्रह होने चाहिए
चौथा चरण (ज़रूरी नहीं) - नए कॉम्पोनेंट जोड़ना
- अगर fwupd फ़्रेमवर्क पहले से मौजूद है, तो अपडेट किए जा सकने वाले कॉम्पोनेंट के सप्लायर को सिर्फ़ एक और चरण पूरा करना होगा. इसके लिए, उसे हार्डवेयर के वैरिएंट के लिए, गड़बड़ियों और VID/PID जोड़ने के लिए, पुल रिक्वेस्ट पर काम करना होगा
अन्य दिशा-निर्देश - एलवीएफ़एस पर काम करना
नया वेंडर खाता बनाएं (सेट अप करने में ~2 मिनट लगते हैं)
वेंडर अपने डोमेन के लिए उपयोगकर्ता बनाते हैं या उपयोगकर्ता खातों को LVFS के साथ सिंक करने के लिए, Azure AD जैसे किसी टूल का इस्तेमाल करते हैं. वे फ़र्मवेयर को निजी और बिक्री पर पाबंदी वाले वर्शन के तौर पर, बिना किसी शुल्क के अपलोड कर सकते हैं. इसके लिए, उन्हें बहुत कम जांच करनी पड़ती है. इसलिए, आम तौर पर इंजीनियर ही शुरुआत से ऐसा करते हैं
आखिर में, टेस्टिंग या स्टेबल वर्शन में पुश करने के लिए, उनके कानूनी विभाग से किसी तरह का दस्तावेज़ चाहिए. इसमें साफ़ तौर पर यह बताया गया हो कि LVFS, फ़र्मवेयर को फिर से डिस्ट्रिब्यूट कर सकता है और उसका विश्लेषण कर सकता है. PDF में दिशा-निर्देश, रिचर्ड ने दिए हैं. ● अगर वेंडर सिर्फ़ सिलिकॉन सप्लायर या ओडीएम है, तो वह OEM का "अफ़िलिएट" बन सकता है और उसकी ओर से फ़र्मवेयर अपलोड कर सकता है. साथ ही, OEM को यह पूरी जानकारी दिखती है कि उसके नाम वाले ब्रैंड के फ़र्मवेयर में क्या हो रहा है.
सेट अप करने के लिए और भी कई चीज़ें हैं.उदाहरण के लिए, वेंडर आईडी की वजह से उन्हें पीसीआई या यूएसबी आईडी के सेट तक ही सीमित किया जाता है. हालांकि, ज़्यादातर वेंडर के पास पहले से ही असाइन किया गया आईडी होता है और इसे सेट अप करने में 20 सेकंड लगते हैं.
अन्य दिशा-निर्देश - Chrome OS के लिए खास जानकारी
हमारे मामले में, फ़र्मवेयर अपडेट की बाइनरी को सीधे LVFS से नहीं खींचा जाता. इसके बजाय, CAB फ़ाइल को लोकल फ़ाइल सिस्टम (rootfs) में सेव किया जाएगा
- आने वाले समय में की जाने वाली कार्रवाई: सही portage ओवरले पर portage ebuild बनाकर, डीएलसी में फ़र्मवेयर बाइनरी शामिल करें
fwupd को सही समय पर (CLI fwupdtool के ज़रिए) शुरू किया जाना चाहिए. अपडेट किए जा सकने वाले हर कॉम्पोनेंट के लिए, एक udev नियम (या मिलती-जुलती स्क्रिप्ट) बनाना ज़रूरी है, जो fwuptool-update upstart इवेंट को उत्सर्जित करता है. इस इवेंट को अपने-आप मैनेज किया जाएगा, ताकि सही आर्ग्युमेंट और सही सैंडबॉक्सिंग (मिनीजेल) के साथ fwupdtool को चलाया जा सके
एक और कॉम्पोनेंट यह तय करता है कि यूज़र इंटरफ़ेस (यूआई) की ज़रूरत है या नहीं. यह सिर्फ़ कुछ मामलों में तय किया जाता है. यह इस बात पर निर्भर करता है कि अपडेट किए गए कॉम्पोनेंट की प्रकृति क्या है. इसे PM और इंजीनियरिंग टीम की ओर से आकलन किया जाएगा. पहले चरण में बताए गए उच्च लेवल के दिशा-निर्देश के मुताबिक, उपयोगकर्ता की ओर से की जाने वाली कार्रवाई को कम करना
वेंडर के लिए अन्य संसाधन
बाहरी दस्तावेज़ का रेफ़रंस: https://lvfs.readthedocs.io/
बाहरी वेंडर के कानूनी समझौतों का रेफ़रंस: fwupd.org/lvfs/docs/agreement
प्लग इन बनाने का ट्यूटोरियल: https://fwupd.github.io/tutorial.html
प्लग इन को डीबग करने का ट्यूटोरियल: https://lvfs.readthedocs.io/en/latest/custom-plugin.html
समस्या वाली फ़ाइल का सैंपल: https://github.com/fwupd/fwupd/blob/master/plugins/wacom-usb/wacom-usb.quirk
बदलाव का इतिहास
| तारीख | वर्शन | नोट |
|---|---|---|
| 2025-03-12 | 1.0.2 | टेक्स्ट को PDF से Markdown में बदलना |
| 2024-01-31 | 1.0.1 | नए प्लैटफ़ॉर्म पर फिर से पब्लिश करना |
| 2023-10-12 | 1.0 | पहली बार पब्लिश होने की तारीख |