كتيّب دمج تحديثات البرامج الثابتة لخدمة Fwupd

الإصدار: 1.0.2
تاريخ آخر تعديل: 12‏/03‏/2025

الملخّص

يهدف هذا المستند إلى تقديم شرح مفصّل حول كيفية تنفيذ fwupd من قِبل المورّدين لمشاريعهم القادمة. ويتضمن أيضًا إحصاءات مقتبسة مباشرةً من القائمين على LVFS. ‫Fwupd هو إطار عمل مفتوح المصدر لتحديث البرامج الثابتة يمكن أن يساعد في توحيد الطريقة التي نُجري بها تحديثات البرامج الثابتة بالشراكة مع مورّدين خارجيين.

الخطوة الأولى: جمع المعلومات وتقديم الإرشادات

بالنسبة إلى المورّدين: السؤال الأول:

  • أسئلة حول المكوّنات القابلة للتحديث

    • حجم التحديث

    • وقت التعديل

    • نوع التحديث الحالي (A/B أو نموذج أداة التمهيد/وقت التشغيل)

    • ماذا يحدث لوظيفة المكوّن أثناء التحديث؟

    • ما الذي يجب أن يحدث للنظام لبدء استخدام تحديث ناجح؟

    • هل يجب تثبيت مكونات متعددة بترتيب معيّن؟

  • الإلمام بالعمل مع LVFS/fwupd أو معرفة كيفية استخدامه

  • إمكانية تخصيص مورد مهندس للمساعدة في تنفيذ المكوّن الإضافي (اطّلِع على المزيد من التفاصيل أدناه)

  • الالتزام بفتح مصدر المكوّن الإضافي وفقًا لـ LGPLv2+ (الرمز البرمجي الذي يكتب البرنامج الثابت إلى المكوّن) والسماح بإعادة توزيع البرنامج الثابت من خلال LVFS

بالنسبة إلى المورّدين، إليك الإرشادات الأولية:

  • يجب أن يقلل التحديث من الوقت الذي يتأثر فيه أداء المكوّن الخارجي أو الداخلي، ويُفضَّل أن يكون بضع ثوانٍ. يجب أن يتم تنفيذ الجزء الأطول من التحديث بصمت في الخلفية بدون إزعاج المستخدم.

    • إذا كان هذا الجهاز الملحق يؤثر في تجربة المستخدم بطريقة واضحة (مثل توقّف الشاشة عن العمل)، يصبح هذا الشرط أكثر صرامة.

  • لتفعيل هذا النوع من التحديثات الصامتة، ننصح بشدة بتفعيل ميزة "التحديثات التجريبية".

    • إنّ تحديثات A/B التي يمكن تفعيلها عند فصل الجهاز الملحق عن مصدر الطاقة مثالية للحدّ من انقطاع الخدمة عن المستخدم

  • يجب أن يكون التحديث قابلاً للاسترداد. في حال إيقاف التشغيل أو فصل الجهاز الملحق أو غير ذلك، يجب ألا يؤدي التحديث إلى تعطيل الجهاز أو الجهاز الملحق. يجب أن يكون قويًا لكي تتمكّن من استرداده بدون تدخل المستخدم.

    • يجب أن يكون الافتراض الأولي هو عدم اتّخاذ أي إجراء من قِبل المستخدم أثناء عملية التحديث بالكامل، ويجب أن يتم تشغيل النصوص البرمجية المناسبة ومراحل التحديث بشكلٍ مستقل.

الخطوة الثانية: استخدام أداة fwupd

إذا لم يستخدم المورّد أداة fwupd مطلقًا

  • يقدّم نظام التشغيل Chrome متطلبات تحديث البرامج الثابتة من خلال fwupd إلى المصنّع الأصلي للجهاز. على المصنّع الأصلي للجهاز إعلام موردي الشرائح أو المكوّنات مباشرةً بذلك.

  • في بعض الحالات، يمكن أن يساعد موفّر خدمة التصميم والتصنيع (ODM) المصنّع الأصلي للجهاز في التواصل مع مورّدي الشرائح مباشرةً. تقع على عاتق المصنّع الأصلي للجهاز مسؤولية إبلاغ العميل بهذه المتطلبات وفقًا لذلك.

  • يُرجى العلم أنّه في حال تقديم رمز المصدر بترخيص LGPLv2+، لا يمكن عادةً اشتقاق الإضافة من هذا الرمز (هناك الكثير من التعقيدات). وبالتالي، في هذا السيناريو، سيُطلب من مورّد الشريحة تعيين شخص يمكنه العمل مع مطوّري fwupd ومهندسي Google.

  • يمكن لمصنعي المعدّات الأصلية اتّخاذ إجراءات استباقية والمساعدة في الحصول على التزام من مورّدي الشرائح للعمل عن كثب مع القائمين على صيانة الإصدار. يجب استيفاء المتطلبات التالية لطلب العميل الدعم الهندسي من جهة المورّد:

    • أن يكون على دراية تامة بالميزات والتصميمات الخاصة بالمكوّن القابل للتحديث من الجهاز، ويُفضّل أن يكون ضمن الفريق نفسه الذي كتب البرامج الثابتة

    • فهم الفرق بين تراخيص البرامج المجانية والمفتوحة المصدر الشائعة (مثل LGPLv2 وMIT)

    • أن تكون بارعًا في لغة C، مع فهم أساسي لـ GLib وGObject، وعلى وجه التحديد فهم GErrors أيضًا

    • أن يكون لديك حساب على GitHub وأن تكون على دراية بكيفية فتح طلب سحب وتعديله، وإجراء مراجعات لرموز GitHub، والتعرّف على بنية أداة fwupd مع جميع الأدوات المساعِدة التي تقدّمها (مثل التجميع والتثبيت/الإلغاء وإعادة المحاولات على الجهاز وHID وما إلى ذلك)

    • اختياري: إمكانية إرسال عيّنات الأجهزة إلى المملكة المتحدة: مفيدة جدًا لمشرفي fwupd لمساعدة المورّد في تصحيح أخطاء البرامج وإضافة اللوحة إلى اختبارات fwupd التي يتم إجراؤها على كل إصدار ويُعدّ هذا الإجراء مهمًا لوقف التراجع في الأداء في فرع التطوير.

  • في الوقت نفسه، يمكن لمصنعي المعدّات الأصلية بدء التفاعل من خلال القائمة البريدية fwupd أو مع "ريتشارد هيوز" (hughsient@gmail.com) مباشرةً ومراجعة الخطة قبل كتابة رمز المكوّن الإضافي.

  • إذا كانت الشركة صغيرة ولا تملك موارد هندسية أو معرفة قليلة أو معدومة بالبرامج المفتوحة المصدر، قد يكون الاقتراح التالي مفيدًا:

    • يمكن لمورّد المكوّن الاستعانة بشركات استشارية على دراية بالعمل في البرامج المفتوحة المصدر (وليس هذا يعني أنّ ذلك سيؤدي إلى تكبد تكلفة إضافية).

    • على الرغم من أنّ هذا الاقتراح يمكن أن يساعد في التوسّع، إلا أنّ قيمة المورّد الذي ينفّذ ذلك داخليًا هي أنّ المهندسين يتعرّفون على العملية ويمكنهم إضافة VID/PID بسهولة في المستقبل للأجهزة الجديدة. ومن الأسهل أيضًا الإجابة عن الأسئلة أو حلّ المشاكل المتعلّقة بمحاولة تصحيح الأخطاء على الجهاز.

الخطوة الثالثة: الخطوات الأخيرة

  • وفي النهاية، تتم إعادة صياغة الرمز البرمجي إلى عمليات إرسال صغيرة يمكن مراجعتها باستخدام كل الوظائف المشتركة في fwupd.

  • بعد اكتمال عملية الدمج، يتم دمج المكوّن الإضافي في الإصدار العلني.

    • أن يكون الرمز المُستخدَم في المصدر هو الرمز نفسه في ChromeOS

    • سيتم توزيع الثنائيات الخاصة بتحديث البرامج الثابتة المستخدَمة خارج ChromeOS على LVFS.

في ما يتعلّق بنظام التشغيل ChromeOS على وجه التحديد:

  • على المصنّع الأصلي للجهاز تحميل الملف الثنائي للبرامج الثابتة إلى خوادمنا من خلال CPFE.

  • لا يزال من الضروري توفُّر أرشيفات خزانة التحديثات القابلة لإعادة التوزيع على LVFS لكي تعمل اختبارات التراجع عن الأجهزة

الخطوة الرابعة (اختيارية) - إضافة مكوّنات جديدة

  • إذا كان إطار عمل fwupd متوفّرًا، تكون الخطوة الإضافية الوحيدة هي أن يعمل مزوّد المكوّنات القابلة للتحديث على طلبات سحب لإضافة ميزات خاصة و VID/PID لأنواع الأجهزة.

إرشادات أخرى - العمل على LVFS

  • إنشاء حساب مورّد جديد (تستغرق عملية الإعداد دقيقتين تقريبًا)

  • ينشئ المورّدون مستخدمين لنطاقاتهم الخاصة أو يستخدمون خدمة مثل Azure AD لمحاولة مزامنة حسابات المستخدمين مع خدمة LVFS. يمكنهم تحميل البرامج الثابتة إلى الإصدارات الخاصة والمحظورة من قِبل المورّد مجانًا تمامًا من خلال عمليات تحقّق قليلة جدًا (لذلك غالبًا ما ينفّذ المهندسون ذلك منذ البداية).

  • في نهاية المطاف، يتطلب الدفع إلى الإصدار التجريبي أو الإصدار الثابت نوعًا من المستندات من القسم القانوني الذي يوضّح بوضوح أنّه يمكن لـ LVFS إعادة توزيع الإصدار الثابت وتحليله. يقدّم "ريتشارد" إرشادات حول ملفات PDF. ● إذا كان المورّد يبيع السيليكون فقط أو كان مصنّعًا للأجهزة الأصلية (ODM)، يمكنه أن يصبح "شريكًا تابعًا" للمصنّع الأصلي للجهاز (OEM) ويمكنه تحميل البرامج الثابتة نيابةً عنه، مع منح المصنّع الأصلي للجهاز إمكانية الاطّلاع الكامل على ما يحدث للبرامج الثابتة التي تحمل اسمه.

  • هناك الكثير من الإجراءات الأخرى التي يجب إعدادها (مثل رقم تعريف المورّد الذي يحدّ من استخدامهم لمجموعة من أرقام تعريف PCI أو USB)، ولكن معظم المورّدين لديهم رقم تعريف مخصّص لهم ويحتاجون إلى 20 ثانية لإعداده.

إرشادات أخرى - أجزاء خاصة بنظام التشغيل Chrome

  • في حالتنا، لا يتم سحب الملفات الثنائية لتعديل البرامج الثابتة من LVFS مباشرةً. بدلاً من ذلك، سيتم تخزين ملف CAB في نظام الملفات المحلي (rootfs).

    • سلسلة العمل المستقبلية: دمج البرنامج الثنائي للبرامج الثابتة في المحتوى القابل للتنزيل (DLC) عن طريق إنشاء حزمة ebuild في portage على تراكب portage المناسب

  • يجب استدعاء fwupd (من خلال أداة fwupdtool لوحدة التحكّم في الحدود) في الوقت المناسب. بالنسبة إلى كل مكوّن قابل للتحديث، يجب إنشاء قاعدة udev (أو نص برمجي مكافئ) تُنشئ حدث upstart لبرنامج fwuptool-update. سيتم التعامل مع هذا الحدث تلقائيًا لتنفيذ fwupdtool مع الوسائط الصحيحة ووضع الحماية المناسب (minijail).

  • يحدّد مكوّن آخر ما إذا كانت واجهة المستخدم مطلوبة، وذلك في حالات معيّنة فقط استنادًا إلى طبيعة المكوّن الذي تم تعديله. سيتم تقييمه من قِبل مدير المشروع وفريق المهندسين. الإرشادات ذات المستوى الأعلى، كما هو موضّح في الخطوة الأولى، هي تقليل الإجراءات التي يتّخذها المستخدم.

مراجع إضافية للبائعين

  • مرجع المستندات الخارجية: https://lvfs.readthedocs.io/

  • إشارة إلى اتفاقيات المورّدين الخارجيين: fwupd.org/lvfs/docs/agreement

  • دليل تطوير المكوّن الإضافي: https://fwupd.github.io/tutorial.html

  • دليل تصحيح أخطاء المكوّنات الإضافية: https://lvfs.readthedocs.io/en/latest/custom-plugin.html

  • نموذج ملف quirk: 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 تاريخ النشر الأولي