Linux: رؤية خطط تطوير نظام تشغيل محددة RPi للمجتمع؟

إذا نظرنا إلى الوراء على مدى السنوات القليلة الماضية ، ما هي التطورات التي كان يمكن للمجتمع أن يستفيد منها من الإشعار المسبق؟

تأكد من أن الليل يتبع النهار ، تزداد أرقام إصدارات Linux. نحاول الحصول على إصدارات عاملة من كل إصدار مُرشح في أسرع وقت ممكن ، على الرغم من عدم وصولهم جميعًا إلى كود الإنتاج. في الوقت نفسه ، وإن كان ذلك بوتيرة أبطأ بكثير ، فإن دبيان تقوم بإصدار إصداراتها الرئيسية ، ومن المحتمل أن ننتقل إلى باستر في وقت ما في المستقبل.

عادةً ما يرتبط تطوير البرامج الخاصة بـ Raspberry Pi بإصدارات الأجهزة ، وإذا كنت تتوقع إشعارًا مسبقًا بهذه الإصدارات ، فستصاب بخيبة أمل.

كما يقول فيل ، ترتبط الكثير من الأشياء بإصدارات الأجهزة.

تقريبًا كل الأشياء التي يبلغ عنها إريك هي أشياء كانت قيد التقدم لفترة من الوقت ، ولكن أثناء وجوده هنا ، أتيحت لنا الفرصة لمناقشة وتحديد الأجزاء المفقودة لجعل KMS (وهمية) أقرب إلى الخط الرئيسي.
لديه خبرة محدودة للغاية في برامج الترميز والكاميرات ، ولكن لديه الكثير في 3D و KMS. لدي معرفة محدودة جدًا بـ V3D ، وبعضها عن التكوين العام ، والكثير عن برامج الترميز والكاميرات. اجمع بين الاثنين وقم بتمرير بعض المعرفة حولك ، ونحصل على بعض التقدم :-)

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

بالنسبة للنواة والبرامج الثابتة على سبيل المثال ، فهي مفتوحة جدًا هنا على Github ، بالنسبة لإصدارات Raspbian ، لا أرى أيًا من ذلك ، يبدو أن إصدارات Raspbian "تظهر من الآن في أي مكان" ؛)

pelwell من أعلى رأسي ، إعادة تسمية VC SONAME. كان من المفترض أن يتم الإعلان عنه مسبقًا ، ولكن بقدر ما أدرك أنه لم يحدث أبدًا ، وأول ما علمت به كان بعد أن تعطلت جميع أعمالي. ونعم أدرك أن هذا ليس له علاقة بالنواة. :)

انظر: https://github.com/raspberrypi/firmware/issues/625#issuecomment -230356111

pelwell @ 6by9 سنستفيد من الإشعارات المتقدمة حول عروض RPI الخاصة مثل VC والبرامج الثابتة وسطح المكتب.
المخلفات الخطرة الجديدة خارج النطاق بشكل واضح.

مثال على ذلك برنامج تشغيل VC4 حيث أشارت مشاركة مدونة إريك إلى "بعض النهايات غير الثابتة" الموصوفة بأنها "يحتاج شخص ما إلى ذلك".
من المحتمل أن يؤدي ربط جميع الأنشطة المطلوبة معًا عبر معلم رئيسي إلى جذب المساهمين لاختيارهم ، ونتيجة لذلك يسمح بدمج تحسين VC4 المخطط له " لا يحتاج إلى gpu_mem = أي أكثر " قريبًا.

من المحتمل أن يؤدي ربط جميع الأنشطة المطلوبة معًا عبر معلم رئيسي إلى جذب المساهمين لالتقاطها ، وبالتالي السماح بدمج تحسين VC4 المخطط له "لا يحتاج إلى gpu_mem = أي أكثر" قريبًا.

نظرًا لأن هذا يتطلب أعمالًا كبيرة داخل البرنامج الثابت ، والعمل المصاحب على إصدار جديد من vc-sm (نأمل أن يكون ذلك مع احتمال ضئيل للتنقيب) ، فهذا ليس شيئًا يمكن مشاركته.

هناك بعد ذلك مناقشات رئيسية مطلوبة حول كيفية إدارة الترحيل من gpu_mem إلى cma. سيؤدي التخصيص الجديد عن بُعد عبر vc-sm إلى جعل مكدس GLES للبرامج الثابتة القديمة غير قابل للتطبيق لأن زمن الانتقال ذهابًا وإيابًا لتخصيص الذاكرة سيقضي على الأداء (يقوم فك تشفير الفيديو / الكاميرا بإجراء جميع التخصيصات مقدمًا ، لذا فهو إعداد بسيط نسبيًا زيادة الوقت). وبالتالي ، سيتطلب التبديل بين CMA و gpu_mem بعض السحر في البرامج الثابتة التي تبحث في عقد شجرة الجهاز على أمل تحديد الوضع الذي يعمل فيه المستخدم ، مما يزيد من تعقيدًا حقيقة أن عناصر شجرة الجهاز الحالية تتم كلها بعد gpu_mem تم تخصيصه بالفعل.
لا يمكن مشاركة أي من ذلك كما هو الحال في البرنامج الثابت ، لذلك مرة أخرى لا يستفيد من تعيينه كعلامة فارقة.

قد يكون هناك بعض الفوائد في وضع المزيد من التفاصيل حول الرقاقة المقترحة لـ DispmanX لـ KMS ، وربما موصل إعادة الكتابة للتبديل. السابق من هؤلاء يعود بشكل أساسي إلى RPT كما نعرف DispmanX ، لكن نقطة العثرة الرئيسية هي الحاجة إلى حل مختلف بين X11 والنظام القائم على وحدة التحكم. لدى إريك الأخير بعض الأفكار ، لذا سيكون الأمر متروكًا له لتوضيح ذلك.

شكرا @ 6by9.
أتطلع لمعرفة المزيد عن خطة "كيفية إدارة الترحيل من gpu_mem إلى cma" في مرحلة ما في المستقبل.

هذه ليست مشكلة kernel حقًا ، لذا أغلق. ومع ذلك ، لا تتردد في إضافة تعليقات في نهاية المشكلة.