Scroll to navigation

MODPROBE.D(5) modprobe.d MODPROBE.D(5)

الاسم

modprobe.d - دليل التهيئة لـ modprobe

موجز

/etc/modprobe.d/*.conf

/run/modprobe.d/*.conf

/usr/local/lib/modprobe.d/*.conf

/usr/lib/modprobe.d/*.conf

/lib/modprobe.d/*.conf

الوصف

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

لاحظ أن أسماء الوحدات والأسماء المستعارة (مثل أسماء الوحدات الأخرى) يمكن أن تحتوي على - أو _: كلاهما قابل للتبديل عبر جميع أوامر الوحدات حيث يحدث تحويل الشرطة السفلية آليًا.

تنسيق الضبط

تحتوي ملفات التهيئة على أمر واحد لكل سطر، مع تجاهل الأسطر الفارغة والأسطر التي تبدأ بـ '#' (مفيدة لإضافة التعليقات). يتسبب '\' في نهاية السطر في استمراره في السطر التالي، مما يجعل الملفات أكثر ترتيبًا.

انظر قسم الأوامر أدناه لمزيد من التفاصيل.

أدلة الضبط والأسبقية

تُقرأ ملفات التهيئة من الدلائل المدرجة في الملخص بهذا الترتيب من الأسبقية. بمجرد تحميل ملف باسم معين، يُتجاهل أي ملف بنفس الاسم في الدلائل اللاحقة.

تُرتب جميع ملفات التهيئة بترتيب معجمي، بغض النظر عن الدليل الذي توجد فيه. يمكن استبدال ملفات التهيئة كليًا (عن طريق وجود ملف تهيئة جديد بنفس الاسم في دليل ذي أولوية أعلى) أو جزئيًا (عن طريق وجود ملف تهيئة يُرتب لاحقًا).

ملاحظة: يمكن تغيير دلائل التهيئة عبر متغير البيئة MODPROBE_OPTIONS. انظر قسم البيئة في modprobe(8).

الأوامر

alias wildcard modulename

يسمح لك هذا بإعطاء أسماء بديلة لوحدة نمطية. على سبيل المثال: "alias my-mod really_long_modulename" يعني أنه يمكنك استخدام "modprobe my-mod" بدلاً من "modprobe really_long_modulename". يمكنك أيضًا استخدام أحرف البدل على غرار الصدفة، لذا "alias my-mod* really_long_modulename" يعني أن "modprobe my-mod-something" له نفس التأثير. لا يمكن أن يكون لديك أسماء مستعارة لأسماء مستعارة أخرى (هذا يؤدي إلى الجنون)، ولكن يمكن أن تحتوي الأسماء المستعارة على خيارات، ستُضاف إلى أي خيارات أخرى.

لاحظ أن الوحدات يمكن أن تحتوي أيضًا على أسماء مستعارة خاصة بها، يمكنك رؤيتها باستخدام modinfo. تُستخدم هذه الأسماء المستعارة كملاذ أخير (أي إذا لم تكن هناك وحدة نمطية حقيقية، أو أمر install، أو remove، أو alias في التهيئة).

blacklist modulename

يمكن أن تحتوي الوحدات على أسماء مستعارة خاصة بها: عادةً ما تكون هذه أسماء مستعارة تصف الأجهزة التي تدعمها، مثل "pci:123...". يمكن تجاوز هذه الأسماء المستعارة "الداخلية" بواسطة كلمات رئيسية "alias" عادية، ولكن هناك حالات تدعم فيها وحدتان أو أكثر نفس الأجهزة، أو تدعي وحدة نمطية بشكل غير صالح دعم جهاز لا تدعمه: تشير الكلمة الرئيسية blacklist إلى أنه يجب تجاهل جميع الأسماء المستعارة الداخلية لتلك الوحدة النمطية المعينة.

تثبيت اسم_الوحدة الأمر...

يأمر هذا الأمر modprobe بتشغيل أمرك بدلاً من إدراج الوحدة في النواة كالمعتاد. يمكن أن يكون الأمر أي أمر شل: هذا يسمح لك بالقيام بأي نوع من المعالجة المعقدة التي قد ترغب بها. على سبيل المثال، إذا كانت الوحدة "fred" تعمل بشكل أفضل مع الوحدة "barney" المثبتة بالفعل (لكنها لا تعتمد عليها، لذا لن يقوم modprobe بتحميلها آلي)، يمكنك قول "install fred /sbin/modprobe barney; /sbin/modprobe --ignore-install fred"، والذي سيفعل ما تريد. لاحظ --ignore-install، الذي يمنع modprobe الثاني من تشغيل نفس أمر install مرة أخرى. انظر أيضًا remove أدناه.

المستقبل البعيد لهذا الأمر كحل لمشكلة توفير تبعيات وحدة إضافية غير مضمون، ومن المقرر استبدال هذا الأمر بتحذير حول إزالته النهائية أو إهماله في وقت ما في إصدار مستقبلي. استخدامه يعقد التحديد الآلي لتبعيات الوحدة بواسطة أدوات التوزيع، مثل mkinitrd (لأن هذه الأدوات تحتاج الآن إلى تفسير ما قد تفعله أوامر install بطريقة ما. في عالم مثالي، ستوفر الوحدات جميع معلومات التبعية دون استخدام هذا الأمر، ويجري العمل على تنفيذ دعم التبعية الناعمة داخل نواة لينكس.

إذا استخدمت السلسلة "$CMDLINE_OPTS" في الأمر، فسيتم استبدالها بأي خيارات محددة في سطر أوامر modprobe. يمكن أن يكون هذا مفيدًا لأن المستخدمين يتوقعون أن "modprobe fred opt=1" يمرر الوسيطة "opt=1" إلى الوحدة، حتى لو كان هناك أمر تثبيت في ملف التهيئة. لذا يصبح مثالنا أعلاه "install fred /sbin/modprobe barney; /sbin/modprobe --ignore-install fred $CMDLINE_OPTS"

خيارات اسم_الوحدة الخيار...

يسمح لك هذا الأمر بإضافة خيارات إلى الوحدة اسم_الوحدة (التي قد تكون اسمًا مستعارًا) في كل مرة يتم إدراجها في النواة: سواء مباشرة (باستخدام modprobe اسم_الوحدة) أو لأن الوحدة التي يتم إدراجها تعتمد على هذه الوحدة.

تتم إضافة جميع الخيارات معًا: يمكن أن تأتي من خيار للوحدة نفسها، لاسم مستعار، وعلى سطر الأوامر.

إزالة اسم_الوحدة الأمر...

هذا مشابه لأمر install أعلاه، باستثناء أنه يتم استدعاؤه عند تشغيل "modprobe -r".

تبعية_ناعمة اسم_الوحدة قبل: الوحدات... بعد: الوحدات...

يسمح لك أمر softdep بتحديد تبعيات وحدة ناعمة أو اختيارية. يمكن استخدام اسم_الوحدة بدون تثبيت هذه الوحدات الاختيارية، ولكن عادةً مع فقدان بعض الميزات. على سبيل المثال، قد يتطلب برنامج تشغيل لمحول ناقل مضيف تخزين تحميل وحدة أخرى لاستخدام ميزات الإدارة.

وحدات ما قبل التبعية وما بعد التبعية هي قوائم بأسماء و/أو أسماء مستعارة لوحدات أخرى سيحاول modprobe تثبيتها (أو إزالتها) بالترتيب قبل وبعد الوحدة الرئيسية المعطاة في وسيطة اسم_الوحدة.

مثال: افترض أن "softdep c pre: a b post: d e" موجود في التهيئة. تشغيل "modprobe c" الآن يعادل "modprobe a b c d e" بدون التبعية الناعمة. يتم تطبيق العلامات مثل --use-blacklist على جميع الوحدات المحددة، بينما تنطبق معلمات الوحدة فقط على الوحدة c.

ملاحظة: إذا كانت هناك أوامر install أو remove بنفس وسيطة اسم_الوحدة، فإن softdep له الأسبقية.

تبعية_ضعيفة اسم_الوحدة الوحدات...

يسمح لك أمر weakdep بتحديد تبعيات وحدة ضعيفة. هذه مشابهة للتبعية الناعمة السابقة، مع الفارق أن مساحة المستخدم لا تحاول تحميل تلك التبعية قبل الوحدة المحددة. بدلاً من ذلك، قد تطلب النواة واحدًا أو أكثر منها أثناء فحص الوحدة، اعتمادًا على الجهاز الذي ترتبط به. الغرض من الوحدة الضعيفة هو السماح لبرنامج التشغيل بتحديد أن تبعية معينة قد تكون مطلوبة، لذا يجب أن تكون موجودة في نظام الملفات (مثل initramfs) عند فحص تلك الوحدة.

مثال: افترض "weakdep c a b". يعرف برنامج يقوم بإنشاء initramfs أنه يجب إضافة a وb وc إلى نظام الملفات نظرًا لأن a وb قد يكونان مطلوبين/مرغوبين في وقت التشغيل. عند تحميل c وفحصها، قد يصدر استدعاءات لـ request_module() مما يتسبب في تحميل a أو b أيضًا.

التوافقية

سيأتي إصدار مستقبلي من kmod مع تحذير قوي لتجنب استخدام install كما هو موضح أعلاه. سيحدث هذا بمجرد اكتمال دعم التبعيات الناعمة في النواة. سيكمل هذا الدعم دعم softdep الحالي داخل هذه الأداة من خلال توفير هذه التبعيات مباشرة داخل الوحدات.

حقوق النسخ

صفحة الدليل هذه حقوق الطبع والنشر الأصلية 2004، Rusty Russell، شركة IBM.

انظر أيضًا

modprobe(8)، modules.dep(5)

العلل

يرجى توجيه أي بلاغات عن الأخطاء إلى متتبع مشكلات kmod في https://github.com/kmod-project/kmod/issues/ مع ذكر الإصدار المستخدم، وخطوات إعادة إنتاج المشكلة والنتيجة المتوقعة.

المؤلفون

وردت مساهمات عديدة من القائمة البريدية linux-modules <linux-modules@vger.kernel.org> وجيت هاب. إذا كان لديك نسخة من kmod.git نفسه، فإن مخرجات git-shortlog(1) و git-blame(1) يمكنها إطلاعك على المؤلفين لأجزاء محددة من المشروع.

Lucas De Marchi <lucas.de.marchi@gmail.com> هو المصون الحالي للمشروع.

ترجمة

تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي <zayed.alsaidi@gmail.com>

هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: kde-l10n-ar@kde.org.

28 أغسطس 2025 kmod