.\" -*- nroff -*- .\" .\" .SY, .YS, .OP macros from /usr/share/groff/1.21/tmac/an-ext.tmac .\" .\" Declare start of command synopsis. Sets up hanging indentation. .de SY . ie !\\n(mS \{\ . nh . nr mS 1 . nr mA \\n(.j . ad l . nr mI \\n(.i . \} . el \{\ . br . ns . \} . . HP \w'\fB\\$1\fP\ 'u . B "\\$1" .. . . .\" End of command synopsis. Restores adjustment. .de YS . in \\n(mIu . ad \\n(mA . hy \\n(HY . nr mS 0 .. . . .\" Declare optional option. .de OP . ie \\n(.$-1 \ . RI "[\fB\\$1\fP" "\ \\$2" "]" . el \ . RB "[" "\\$1" "]" .. .TH DKMS 8 "16 Aug 2026" dkms-3.4.3 .SH "نام (NAME)" dkms \- پشتیبانی پویا از ماژول‌های هسته (Dynamic Kernel Module Support) .SH "خلاصه دستور (SYNOPSIS)" .SY dkms .OP action .OP options .OP module/module-version .OP /path/to/source-tree .OP /path/to/tarball.tar .OP /path/to/driver.rpm .YS .SH "توضیحات (DESCRIPTION)" .B dkms یک چارچوب کاری است که امکان ساخت پویای ماژول‌های هسته را برای هر هسته موجود روی سیستم شما به شیوه‌ای ساده‌سازی‌شده و سازمان‌یافته فراهم می‌کند\&. .SH "عملیات‌ها (ACTIONS)" .SY add .OP "module/module\-version | /path/to/source\-tree | /path/to/tarball.tar" .YS .IP "" 4 یک ترکیب ماژول/نسخه\-ماژول را برای ساخت و نصب به درخت (tree) اضافه می‌کند\&. اگر .IR module/module\-version ، .IR "\-m module/module\-version" ، یا .I \-m module\ \-v module\-version به عنوان گزینه داده شوند، این دستور نیازمند وجود کد منبع در .I /usr/src/\-/ و همچنین یک پرونده .I dkms.conf با ساختار و قالب‌بندی صحیح است\&. اگر .I /path/to/source\-tree به عنوان یک گزینه داده شود و درخت منبع شامل یک پرونده .I dkms.conf باشد، مسیر .I /path/to/source\-tree را در .I /usr/src/module\-module\-version رونوشت (کپی) می‌کند\&. اگر .I /path/to/tarball.tar داده شود، این دستور همانند دستور .B ldtarball رفتار می‌کند\&. .PP .SY remove .OP module/module\-version .OP -k kernel/arch .OP \-\-all .YS .IP "" 4 یک ترکیب ماژول/نسخه یا ماژول/نسخه/هسته/معماری را از درخت حذف می‌کند\&. اگر ماژول در حال حاضر نصب باشد، ابتدا آن را لغو نصب (uninstall) می‌کند و در صورت امکان، آن را با original_module (ماژول اصلی) خود جایگزین می‌نماید\&. از گزینه .B \-\-all برای حذف تمام نمونه‌ها برای تمام هسته‌ها به طور همزمان استفاده کنید\&. .PP .SY build .OP module/module\-version .OP -k kernel/arch .OP --force .YS .IP "" 4 ترکیب ماژول/نسخه مشخص‌شده را برای هسته/معماری مشخص‌شده می‌سازد (build می‌کند)\&. اگر گزینه .I \-k مشخص نشده باشد، برای هسته و معماری در حال اجرای فعلی ساخته می‌شود\&. تمام فرآیندهای ساخت در شاخه .I /var/lib/dkms///build/ رخ می‌دهند\&. اگر ترکیب ماژول/نسخه\-ماژول هنوز اضافه نشده باشد، dkms تلاش می‌کند آن را اضافه کند و در این صورت .B build می‌تواند همان آرگومان‌های دستور .B add را بپذیرد\&. اگر ماژول از قبل ساخته شده باشد، به‌طور پیش‌فرض دوباره ساخته نخواهد شد و برای لغو این حالت باید از گزینه .B --force استفاده شود\&. .PP .SY unbuild .OP module/module\-version .OP -k kernel/arch .OP \-\-all .YS .IP "" 4 عملیات ساخت را برای ترکیب ماژول/نسخه یا ماژول/نسخه/هسته/معماری از درخت لغو می‌کند (undo می‌کند)\&. اگر ماژول در حال حاضر نصب باشد، ابتدا آن را لغو نصب کرده و در صورت امکان، آن را با original_module خود جایگزین می‌کند\&. در نهایت تمامی ماژول‌های باینری هسته حذف می‌شوند\&. از گزینه .B \-\-all برای لغو ساخت تمام نمونه‌ها برای تمامی هسته‌ها به‌طور یکجا استفاده کنید\&. .PP .SY install .OP module/module\-version .OP -k kernel/arch .OP --force .OP /path/to/driver.rpm .YS .IP "" 4 یک ترکیب ماژول/نسخه ساخته‌شده را روی هسته‌ای که برای آن ساخته شده نصب می‌کند\&. اگر گزینه هسته مشخص نشده باشد، هسته در حال اجرای فعلی فرض می‌شود\&. اگر ماژول هنوز ساخته نشده باشد، dkms تلاش می‌کند آن را بسازد\&. اگر ماژول هنوز اضافه نشده باشد، dkms تلاش می‌کند آن را اضافه کند\&. در هر دو حالت، دستور .B install می‌تواند آرگومان‌های مشابه دستورات .B build یا .B add را بپذیرد\&. اگر ماژول قبلاً نصب شده باشد، به‌طور پیش‌فرض دوباره نصب نخواهد شد و باید از گزینه .B --force برای لغو این رفتار استفاده شود\&. اگر یک پرونده .rpm بدهید، dkms سعی می‌کند آن پرونده را با .BR "rpm -Uvh" نصب کند و در صورتی که RPM با موفقیت نصب شود، یک عملیات .B autoinstall را اجرا می‌کند تا اطمینان حاصل شود که همه‌چیز برای هسته شما ساخته شده است\&. .PP .SY uninstall .OP module/module\-version .OP -k kernel/arch .OP \-\-all .YS .IP "" 4 یک ترکیب ماژول/نسخه\-ماژول نصب‌شده را از هسته/معماری ارائه‌شده در گزینه \-k، یا از هسته فعلی در صورتی که گزینه \-k داده نشده باشد، لغو نصب می‌کند\&. از گزینه .B \-\-all برای لغو نصب تمام نمونه‌ها برای همه هسته‌ها به‌طور همزمان استفاده کنید\&. پس از اتمام لغو نصب، راه‌انداز در حالت ساخته‌شده (built) باقی خواهد ماند\&. برای حذف کامل یک راه‌انداز، باید از عملیات remove استفاده شود\&. .PP .SY match .OP --templatekernel kernel/arch .OP -k kernel/arch .YS .IP "" 4 دستور Match ماژول‌ها را با بررسی پیکربندی .B templatekernel مشخص‌شده، بر روی هسته مورد نظر نصب می‌کند\&. هر ماژولی که درون .B dkms روی .B templatekernel نصب شده باشد، سپس بر روی آن هسته مشخص‌شده نیز نصب خواهد شد\&. .PP .SY mktarball .OP module/module\-version .OP -k kernel/arch .OP --archive /path/to/tarball.tar .OP --source-only .OP --binaries-only .YS .IP "" 4 یک آرشیو تاربال (tarball) از تمام پرونده‌های موجود در درخت DKMS برای ترکیب ماژول/نسخه مشخص‌شده ایجاد می‌کند\&. این شامل کد منبع و هر ماژول ساخته‌شده برای هسته‌های موجود در درخت (طبق آنچه مشخص شده) است\&. در غیر این صورت، می‌توانید یک هسته تکی یا چند هسته را برای آرشیو کردن مشخص کنید ( .IR "\-k kernel1/arch1 \-k kernel2/arch2" )\&. به‌صورت اختیاری، می‌توانید از .B \-\-archive برای تعیین پرونده‌ای که مایلید این تاربال در آن ذخیره شود استفاده کنید\&. همچنین اگر می‌خواهید تاربال حاصل شامل کد منبع ماژول نباشد، می‌توانید .B \-\-binaries\-only را مشخص کنید\&. به‌همین ترتیب، می‌توان از .B \-\-source-only استفاده کرد تا مشخص شود که هیچ باینری پیش‌ساخته‌ای نباید در تاربال گنجانده شود\&. به طور کلی، .B mktarball برای اهداف مدیریت سیستم‌ها بسیار عالی است زیرا می‌توانید راه‌انداز خود را تنها روی یک سیستم بسازید و سپس از .B ldtarball روی تمام سیستم‌های دیگر خود برای بارگذاری همان ماژول‌های ساخته‌شده بدون نیاز به انتظار برای کامپایل استفاده کنید\&. .PP .SY ldtarball .OP /path/to/tarball.tar .OP --force .YS .IP "" 4 این دستور تاربال ساخته‌شده از دستور .B mktarball را دریافت کرده و آن را در درخت DKMS شما بارگذاری می‌کند\&. این کار ماژول‌های تازه اضافه‌شده را در وضعیت ساخته‌شده (built) رها می‌کند و سپس باید .B dkms install برای نصب هر یک از آن‌ها فراخوانی شود\&. اگر پرونده‌ها از قبل در مکانی که .B ldtarball قصد قرار دادن آن‌ها را دارد وجود داشته باشند، هشدار داده و روی آن‌ها رونوشت نمی‌کند\&. برای لغو این رفتار باید از گزینه .B \-\-force استفاده شود\&. .PP .SY status .OP module/module\-version .OP -k kernel/arch .YS .IP "" 4 وضعیت فعلی ماژول‌ها، نسخه‌ها و هسته‌ها را در درخت و همچنین اینکه آیا اضافه شده‌اند، ساخته شده‌اند یا نصب شده‌اند برمی‌گرداند\&. وضعیت را می‌توان فقط برای یک ماژول خاص، یک هسته خاص، یک ترکیب ماژول/نسخه یا یک ترکیب ماژول/نسخه/هسته نمایش داد\&. اگر شاخه منبع، یا پیوند نمادین 'source' که به آن اشاره می‌کند مفقود باشد، وضعیت ترکیب ماژول/نسخه به صورت 'broken' (خراب) نمایش داده خواهد شد\&. در این صورت dkms هیچ اقدام دیگری روی آن ترکیب خاص ماژول/نسخه انجام نخواهد داد\&. مداخله دستی لازم است\&. اگر فقط پیوند نمادین 'source' مفقود باشد، می‌توان از عملیات .B add برای اضافه کردن مجدد ترکیب ماژول/نسخه به dkms استفاده کرد\&. .PP .SY autoinstall .YS .IP "" 4 تلاش می‌کند تا آخرین بازبینی (revision) از تمام ماژول‌هایی را که برای سایر نسخه‌های هسته نصب شده‌اند، نصب کند\&. سرویس autoinstaller مربوط به DKMS یک بخش واسط (stub) است که از این عملیات برای انجام وظایف خود استفاده می‌کند\&. .PP .SY generate_mok .YS .IP "" 4 دستوری که برای تولید کلیدهای Secure Boot به‌صورت مستقل صادر می‌شود\&. تنها در صورتی مورد نیاز است که دستکاری قبلی کلیدها لازم باشد، در غیر این صورت کلیدها به طور خودکار در اولین تلاش برای ساخت یک ماژول DKMS تولید می‌شوند\&. هیچ آرگومان اضافی تجزیه (پردازش) نمی‌شود\&. .SH "گزینه‌ها (OPTIONS)" .TP .B \-m / نام ماژول و نسخه ماژولی که می‌خواهید روی آن عملیات انجام دهید\&. بخش .B \-m این گزینه اختیاری است و تقریباً در تمام شرایط می‌توان آن را حذف کرد\&. .TP .B \-v نسخه ماژول برای اجرای عملیات مشخص‌شده روی آن\&. این گزینه فقط در صورتی باید مشخص شود که گزینه .B \-m را بدون جزء درون خود ارسال کنید\&. .TP .B \-k / هسته و معماری برای انجام عملیات روی آن\&. می‌توانید با تکرار آرگومان \-k همراه با نسخه هسته و معماری متفاوت، چندین جفت نسخه هسته/معماری را در خط فرمان مشخص کنید\&. با این حال، همه عملیات‌ها از چندین نسخه هسته پشتیبانی نمی‌کنند (در این حالت با خطا مواجه خواهد شد)\&. بخش معماری را می‌توان حذف کرد و DKMS فرض می‌کند که منظور شما معماری سیستم در حال اجرای فعلی است\&. .TP .B \-a, \-\-arch معماری سیستمی که باید عملیات روی آن انجام شود\&. اگر آن را به عنوان بخشی از گزینه .B \-k ارسال کنید، اختیاری است\&. در صورت عدم تعیین، معماری سیستم در حال اجرای فعلی را فرض می‌کند ( .BR "uname \-m" )\&. می‌توانید با تکرار آرگومان .B \-a همراه با نام معماری متفاوت، چندین پارامتر معماری را در همان خط فرمان مشخص کنید\&. هنگامی که چندین معماری مشخص می‌شود، باید رابطه ۱ به ۱ بین آرگومان‌های .B \-k و آرگومان‌های .B \-a وجود داشته باشد\&. سپس DKMS فرض می‌کند که اولین آرگومان .B \-a با اولین .B \-k هم‌تراز است و به همین ترتیب برای دومی، سومی و غیره\&. برای مثال، اگر مشخص کنید: .B \-k kernel1 \-k kernel2 \-a i386 \-k kernel3 \-a i686 \-a x86_64 ، DKMS آن را به این صورت پردازش خواهد کرد: .BR kernel1\-i386 ، .BR kernel2\-i686 ، .BR kernel3\-x86_64 \&. .TP .B \-q, \-\-quiet حالت بی‌صدا (Quiet)\&. .TP .B \-V, \-\-version نسخه نصب‌شده فعلی dkms را چاپ کرده و خارج می‌شود\&. .TP .B \-h, \-\-help راهنما\&. .TP .B \-c مکان پرونده .IR dkms.conf \&. این برای عملیات add لازم است و در صورت عدم تعیین، فرض می‌شود که در .I /usr/src/\-/ قرار دارد\&. برای اطلاعات بیشتر در مورد ساختار .I dkms.conf به بخش‌های زیر مراجعه کنید\&. .TP .B \-\-config در طول یک .BR build ، این گزینه برای تعیین یک مکان جایگزین برای پرونده پیکربندی .I include/config/auto.conf هسته که شامل پیکربندی آن هسته است، استفاده می‌شود\&. به‌طور معمول، .B dkms قادر است مکان پرونده پیکربندی را از فایل‌سیستم استخراج کند، اما در صورت بروز مشکل در تشخیص، باید به .B dkms بگویید پرونده ضروری .I include/config/auto.conf (یا پرونده قدیمی‌تر .IR .config ) در کجا یافت می‌شود تا هسته شما بتواند به‌درستی برای ساخت ماژول آماده شود\&. .TP .B \-\-archive این گزینه در حین عملیات .B ldtarball برای تعیین مکان تاربالی که مایل به بارگذاری آن در درخت DKMS خود هستید استفاده می‌شود\&. تنها در صورتی باید بخش .B --archive این گزینه را مشخص کنید که قبلاً به عنوان یک پرونده وجود نداشته باشد\&. .TP .B \-\-templatekernel این گزینه برای عملیات زیر الزامی است: .BR match \&. دستور Match به templatekernel مشخص‌شده نگاه می‌کند و تمام ترکیب‌های مشابه ماژول/نسخه را روی هسته دیگر نصب می‌نماید\&. .TP .B \-\-force این گزینه می‌تواند همراه با .BR "build، install" و .B ldtarball برای اجبار به رونوشت روی پرونده‌های موجود استفاده شود\&. .TP .B \-\-force\-version\-override این گزینه بررسی جدیدتر بودن نسخه ماژولی که قرار است نصب شود نسبت به نسخه نصب‌شده فعلی را نادیده می‌گیرد (رد می‌کند)\&. .TP .B \-\-binaries\-only این گزینه می‌تواند همراه با .B mktarball استفاده شود تا یک تاربال DKMS ایجاد کند که شامل کد منبع ماژول در خود نباشد\&. اگر می‌دانید سیستمی که قرار است این تاربال روی آن بارگذاری شود قبلاً کد منبع را نصب کرده است، این کار می‌تواند در کاهش اندازه تاربال مفید باشد\&. برای بارگذاری تاربالی که به‌صورت فقط-باینری ساخته شده است، .B حتماً باید کد منبع ماژول را در درخت DKMS آن سیستم داشته باشید\&. در غیر این صورت، DKMS از بارگذاری تاربال فقط-باینری .B خودداری خواهد کرد (خطا می‌دهد)\&. .TP .B \-\-source\-only این گزینه می‌تواند همراه با .B mktarball استفاده شود، اما اگر نمی‌خواهید تاربالی که ایجاد می‌کنید شامل هیچ ماژول پیش‌ساخته‌ای باشد، ارسال این گزینه مانع از گنجاندن هرگونه ماژول پیش‌ساخته در تاربال داخلی DKMS می‌شود\&. .TP .B \-\-all این گزینه می‌تواند برای تعیین خودکار تمام هسته‌ها/معماری‌های مربوطه برای یک ماژول/نسخه\-ماژول استفاده شود\&. می‌توان از آن برای مواردی مانند remove، unbuild و uninstall استفاده کرد\&. این کار زحمت تعیین دستی \-k kernel1 \-a arch1 \-k kernel2 \-a arch2 را برای تک‌تک هسته‌هایی که ماژول را برای آن‌ها ساخته‌اید برطرف می‌کند\&. .TP .B \-\-no\-depmod این گزینه از اجرای دستور depmod توسط DKMS در هنگام .B install و .B uninstall جلوگیری می‌کند که مانع از محاسبه (مجدد) وابستگی‌های ماژول شده و در نتیجه در زمان صرفه‌جویی می‌کند\&. .TP .B \-\-modprobe\-on\-install این گزینه پس از نصب موفقیت‌آمیز، دستور modprobe را روی ماژول‌ها اجرا می‌کند\&. .TP .B \-\-kernelsourcedir با استفاده از این گزینه می‌توانید مکان شاخه کد منبع هسته خود را مشخص کنید\&. در صورتی که منبع هسته شما از طریق .I /usr/lib/modules/$kernel_version/build در دسترس باشد، به احتمال زیاد نیازی به تنظیم این گزینه نخواهید داشت\&. .TP .B \-\-directive <"cli\-directive=cli\-value"> با استفاده از این گزینه می‌توانید دستورالعمل‌های (directives) اضافی را از طریق خط فرمان مشخص کنید\&. گزینه .B \-\-directive می‌تواند چندین بار در همان خط فرمان برای تعیین چندین دستورالعمل خط فرمان اضافی استفاده شود\&. .TP .B \-\-rpm_safe_upgrade این پرچم باید هنگام بسته‌بندی ماژول‌های فعال‌شده با DKMS در قالب RPM استفاده شود\&. این گزینه باید هم در حین عملیات .B add و هم در حین عملیات .B remove در فایل spec مربوط به RPM مشخص شود تا اطمینان حاصل گردد که DKMS و RPM در تمام سناریوها هنگام ارتقا بین نسخه‌های مختلف یک بسته RPM ماژول dkms رفتار درستی دارند\&. .TP .B \-\-dkmstree path/to/place یک درخت مقصد برای ساخت و نصب ماژول‌ها فراهم می‌کند\&. در مواردی کاربرد دارد که نمی‌خواهید سیستمی را هنگام استفاده صرف برای ساخت ماژول آلوده کنید\&. .TP .B \-\-sourcetree path/to/place مکانی برای ساخت بسته DKMS از روی آن فراهم می‌کند\&. برای سیستم‌هایی مفید است که ممکن است در آن‌ها دسترسی ریشه (root) نداشته باشید، اما همچنان تمایل به ساخت بسته‌های DKMS داشته باشید\&. .TP .B \-\-installtree path/to/place مکانی برای قرار دادن ماژول‌ها در هنگام صدور دستور .I dkms install فراهم می‌کند\&. .TP .B \-j number حداکثر .I number تعداد کار را به‌طور موازی اجرا می‌کند؛ گزینه -j از .IR make (1) را ببینید\&. پیش‌فرض روی تعداد پردازنده‌های سیستم است که توسط .IR nproc (1) تشخیص داده می‌شود\&. برای عدم اعمال محدودیت بر تعداد کارهای موازی، 0 را مشخص کنید\&. .TP .B \-\-verbose خروجی مفصل و پرحرف دستورات خارجی اجراشده در DKMS را فعال می‌کند\&. .SH "ماژول‌های اصلی (ORIGINAL MODULES)" در اولین نصب یک ماژول برای یک ، .B dkms شاخه .I /usr/lib/modules/ را برای یافتن ماژول از پیش موجود با همان نام جستجو خواهد کرد\&. در صورت یافتن، به‌طور خودکار به عنوان یک "original_module" ذخیره می‌شود تا اگر ماژول جدیدتر بعداً حذف شد، .B dkms ماژول اصلی را سر جای خود بازگرداند\&. در حال حاضر، DKMS این ماژول‌های اصلی را با اولویت اول برای ماژول‌های واقع در .I /usr/lib/modules//updates/ و سپس .B $DEST_MODULE_LOCATION (همان‌طور که در .I dkms.conf مشخص شده) جستجو می‌کند\&. اگر در هیچ‌یک از این مکان‌ها پیدا نشود، از دستور find برای یافتن آن برای آن هسته استفاده خواهد شد\&. اگر هیچ موردی یافت نشود، در حین لغو نصب بعدی، هیچ ماژولی در هسته شما جایگزین نخواهد شد\&. اگر بیش از یک ماژول یافت شود، اولین موردی که پیدا شده (بر اساس اولویت اشاره‌شده در بالا) به عنوان "original_module" در نظر گرفته می‌شود\&. همچنین تمام نسخه‌های ماژول هم‌نام از درخت هسته شما حذف شده و در .I /var/lib/dkms//original_module/$kernelver/collisions قرار می‌گیرند تا بعداً به‌طور *دستی* در دسترس باشند\&. DKMS در عمل هرگز کاری با ماژول‌های یافت‌شده در شاخه .B /collisions انجام نخواهد داد و آن‌ها تا زمانی که خودتان دستی حذفشان کنید در آنجا ذخیره می‌مانند\&. .SH "پیکربندی DKMS.CONF (DKMS.CONF)" هنگام اجرای یک عملیات .BR add ، باید یک پرونده معتبر .I dkms.conf یافت شود\&. یک پرونده پیکربندی با ساختار مناسب برای اطلاع‌رسانی به DKMS درباره چگونگی و مکان نصب ماژول ضروری است\&. اگرچه همه دستورالعمل‌ها الزامی نیستند، اما ارائه هرچه بیشتر آن‌ها به رفع هرگونه ابهام کمک می‌کند\&. توجه داشته باشید که .I dkms.conf در واقع تنها یک شل‌اسکریپت از تعاریف متغیرها است که سپس توسط فایل اجرایی .B dkms بارگذاری و اجرا (source) می‌شود (به فرمت .IR 'DIRECTIVE="directive text goes here"' )\&. همچنین دستورالعمل‌ها به حروف کوچک و بزرگ حساس هستند و باید با حروف بزرگ (ALL CAPS) وارد شوند\&. درک این نکته مهم است که بسیاری از دستورالعمل‌های DKMS آرایه‌هایی هستند که مقادیر اندیس آن‌ها به یکدیگر گره خورده‌اند\&. این وابستگی‌های آرایه‌ای را می‌توان خانواده‌ها در نظر گرفت، و در حال حاضر سه خانواده از آرایه‌های دستورالعمل وجود دارد\&. .B MAKE[#] و .B MAKE_MATCH[#] یک خانواده را تشکیل می‌دهند\&. .B PATCH[#] و .B PATCH_MATCH[#] خانواده دوم را تشکیل می‌دهند\&. سومین و بزرگ‌ترین خانواده شامل .B BUILT_MODULE_NAME[#] ، .B BUILT_MODULE_LOCATION[#] ، .B DEST_MODULE_NAME[#] ، .B DEST_MODULE_LOCATION[#] و .B STRIP[#] است\&. هنگام اندیس‌گذاری این آرایه‌ها در زمان ایجاد .I dkms.conf خود، هر خانواده باید از مقدار اندیس 0 شروع شود\&. .TP .B PACKAGE_NAME= این دستورالعمل برای تعیین نام مرتبط با کل بسته ماژول‌ها استفاده می‌شود\&. این همان نامی است که با گزینه .B \-m هنگام ساخت، افزودن و غیره استفاده می‌شود و لزوماً نباید با .B MODULE_NAME یکسان باشد\&. این دستورالعمل باید در هر پرونده پیکربندی DKMS وجود داشته باشد\&. .TP .B PACKAGE_VERSION= این دستورالعمل برای تعیین نسخه مرتبط با کل بسته ماژول‌های در حال نصب درون آن بسته dkms استفاده می‌شود\&. این دستورالعمل باید در هر پرونده پیکربندی DKMS وجود داشته باشد\&. .TP .B BUILT_MODULE_NAME[#]= این دستورالعمل نام ماژول را درست پس از ساخت آن مشخص می‌کند\&. اگر بسته ماژول DKMS شما شامل بیش از یک ماژول برای نصب باشد، این یک دستورالعمل .B الزامی برای همه آن ماژول‌ها است\&. این دستورالعمل صراحتاً نباید شامل پسوند انتهایی ".o" یا ".ko" باشد\&. توجه داشته باشید که برای هر ماژول در یک بسته dkms، مقدار عددی .B # باید برای هر یک از دستورالعمل‌های .BR BUILT_MODULE_NAME ، .BR BUILT_MODULE_LOCATION ، .B DEST_MODULE_NAME و .B DEST_MODULE_LOCATION یکسان باشد و شماره‌گذاری باید از 0 شروع شود (مثلاً .B BUILT_MODULE_NAME[0]="qla2200" BUILT_MODULE_NAME[1]="qla2300" )\&. .TP .B BUILT_MODULE_LOCATION[#]= این دستورالعمل به DKMS می‌گوید پس از ساخت ماژول، آن را در کجا پیدا کند\&. این مسیر باید به‌صورت نسبی نسبت به شاخه ریشه پرونده‌های منبع شما (جایی که پرونده .I dkms.conf شما در آن یافت می‌شود) داده شود\&. در صورت عدم تنظیم، DKMS انتظار دارد .B BUILT_MODULE_NAME[#] شما را در شاخه ریشه پرونده‌های منبع بیابد\&. توجه داشته باشید که برای هر ماژول در یک بسته dkms، مقدار عددی .B # باید برای هر یک از دستورالعمل‌های .BR BUILT_MODULE_NAME ، .BR BUILT_MODULE_LOCATION ، .B DEST_MODULE_NAME و .B DEST_MODULE_LOCATION یکسان باشد و شماره‌گذاری باید از 0 شروع شود (مثلاً .B BUILT_MODULE_LOCATION[0]="some/dir/" BUILT_MODULE_LOCATION[1]="other/dir/" )\&. .TP .B DEST_MODULE_NAME[#]= این دستورالعمل می‌تواند برای تعیین نام ماژول به همان صورتی که باید نصب شود استفاده گردد\&. این کار نام ماژول را از .B BUILT_MODULE_NAME[#] به .B DEST_MODULE_NAME[#] تغییر می‌دهد\&. این دستورالعمل صراحتاً نباید شامل پسوند انتهایی ".o" یا ".ko" باشد\&. در صورت عدم تنظیم، فرض می‌شود که همان مقدار .B BUILT_MODULE_NAME[#] را دارد\&. توجه داشته باشید که برای هر ماژول در یک بسته dkms، مقدار عددی .B # باید برای هر یک از دستورالعمل‌های .BR BUILT_MODULE_NAME ، .BR BUILT_MODULE_LOCATION ، .B DEST_MODULE_NAME و .B DEST_MODULE_LOCATION یکسان باشد و شماره‌گذاری باید از 0 شروع شود (مثلاً .B DEST_MODULE_NAME[0]="qla2200_6x" DEST_MODULE_NAME[1]="qla2300_6x" )\&. .TP .B DEST_MODULE_LOCATION[#]= این دستورالعمل مقصدی را که ماژول پس از کامپایل باید در آن نصب شود مشخص می‌کند\&. همچنین برای یافتن original_modules استفاده می‌شود\&. این یک دستورالعمل .B الزامی است، به جز در مواردی که در ادامه ذکر شده است\&. این دستورالعمل باید با عبارت "/kernel" آغاز شود که اشاره به .I /usr/lib/modules//kernel دارد\&. توجه داشته باشید که برای هر ماژول در یک بسته dkms، مقدار عددی .B # باید برای هر یک از دستورالعمل‌های .BR BUILT_MODULE_NAME ، .BR BUILT_MODULE_LOCATION ، .B DEST_MODULE_NAME و .B DEST_MODULE_LOCATION یکسان باشد و شماره‌گذاری باید از 0 شروع شود (مثلاً .B DEST_MODULE_LOCATION[0]="/kernel/drivers/something/" DEST_MODULE_LOCATION[1]="/kernel/drivers/other/" )\&. دستورالعمل .B DEST_MODULE_LOCATION در توزیع‌های Fedora، Red Hat Enterprise Linux، SuSE Linux Enterprise Server، openSUSE و Ubuntu نادیده گرفته می‌شود\&. به جای آن، شاخه مناسب و مختص همان توزیع استفاده می‌شود\&. .TP .B STRIP[#]= به‌طور پیش‌فرض مقدار strip برابر "yes" در نظر گرفته می‌شود\&. اگر روی "no" تنظیم شود، DKMS دستور .B strip \-g را روی ماژول ساخته‌شده شما اجرا نخواهد کرد تا نمادهای اشکال‌زدایی (debug symbols) را از آن حذف نکند\&. مقدار .B STRIP[0] به عنوان پیش‌فرض برای هر ورودی تنظیم‌نشده در آرایه .B STRIP استفاده می‌شود\&. .TP .B MAKE[#]= آرایه دستورالعمل MAKE به DKMS می‌گوید از کدام دستور make باید برای ساخت ماژول شما استفاده شود\&. دستور پیش‌فرض make باید در .B MAKE[0] قرار گیرد\&. سایر ورودی‌های موجود در آرایه MAKE تنها در صورتی استفاده می‌شوند که ورودی متناظر آن‌ها در .B MAKE_MATCH[#] به عنوان یک عبارت باقاعده (با استفاده از grep -E) با هسته‌ای که ماژول برای آن ساخته می‌شود مطابقت داشته باشد\&. توجه داشته باشید که اگر هیچ مقداری در .B MAKE_MATCH[#] برای هر .B MAKE[#] که در آن # > 0 باشد قرار نگیرد، آن دستورالعمل .B MAKE نادیده گرفته می‌شود\&. ورودی .B MAKE_MATCH[0] اختیاری است و اگر مقداردهی شده باشد، برای تعیین اینکه آیا باید از MAKE[0] برای ساخت ماژول برای آن هسته استفاده شود یا خیر به کار می‌رود\&. اگر چندین دستورالعمل .B MAKE_MATCH با هسته‌ای که ماژول برای آن ساخته می‌شود مطابقت داشته باشند، آخرین .B MAKE[#] مطابق برای ساخت ماژول شما استفاده خواهد شد\&. اگر هیچ دستورالعمل .B MAKE مشخص نشده باشد یا هیچ .B MAKE_MATCH با هسته‌ای که ماژول برای آن ساخته می‌شود مطابقت نداشته باشد، DKMS تلاش خواهد کرد از یک دستور عمومی make برای ساخت ماژول شما استفاده کند\&. عبارت .B KERNELRELEASE=$kernelver \-j$parallel_jobs به‌طور خودکار به انتهای .B MAKE[#] اضافه می‌شود\&. اگر می‌خواهید این رفتار را لغو کنید، می‌توانید دستور make را داخل نقل‌قول قرار دهید: 'make'\&. .TP .B MAKE_MATCH[#]= توضیحات فوق درباره دستورالعمل‌های .B MAKE[#] را ببینید\&. این آرایه باید با عبارت‌های باقاعده‌ای پر شود که هنگام مطابقت با هسته‌ای که ماژول برای آن ساخته می‌شود، به .B DKMS بگویند از دستور make متناظر در آرایه دستورالعمل .B MAKE[#] برای ساخت ماژول شما استفاده کند\&. .TP .B NO_WEAK_MODULES= دستورالعمل .B NO_WEAK_MODULES هنگامی که روی "yes" تنظیم شود، از ایجاد پیوند نمادین توسط dkms به شاخه .B weak-updates جلوگیری می‌کند\&. قابلیت weak modules برای برطرف کردن نیاز به ساخت مجدد ماژول‌های هسته هنگام رخ دادن ارتقای هسته طراحی شده است و به نمادهای درون kABI متکی است\&. مقادیر معتبر "yes" یا "no" هستند\&. رابط ماژول هسته kABI در حال حاضر در Red Hat Enterprise Linux (و مشتقات آن)، SUSE Linux Enterprise Server و openSUSE Leap پشتیبانی می‌شود؛ در سایر توزیع‌ها این دستورالعمل نادیده گرفته می‌شود\&. .TP .B OBSOLETE_BY= .B این دستورالعمل منسوخ شده است و در نسخه آینده حذف خواهد شد\&. استفاده از .B BUILD_EXCLUSIVE_KERNEL_MAX را به جای .B OBSOLETE_BY در نظر بگیرید، زیرا روش اول رویکرد کلی‌تری برای حل همین مشکل است\&. این دستورالعمل به شما امکان می‌دهد نسخه هسته‌ای را مشخص کنید که نیاز به این ماژول DKMS خاص را منسوخ (بی‌استفاده) می‌کند\&. این مقدار را می‌توان به عنوان یک هسته بالادست (upstream) خاص یا یک جهش ABI (bump) از یک هسته مشخص کرد\&. برای مثال، "2.6.24" یک هسته بالادست خواهد بود و "2.6.24\-16" نشان‌دهنده یک جهش ABI برای یک هسته است\&. هر دو در این بخش معتبر هستند\&. استفاده از آن نشان‌دهنده عدم نسخه‌گذاری مناسب ماژول با استفاده از برچسب‌های .B ()MODULE_VERSION در خود کد منبع ماژول است\&. بهتر است برچسب‌های .B ()MODULE_VERSION اصلاح شوند تا اینکه از .B OBSOLETE_BY استفاده شود\&. این کار همچنین یک وابستگی ضمنی به توزیع/نسخه بر روی بسته ایجاد می‌کند، زیرا مقدار .B OBSOLETE_BY تنها در زمینه یک توزیع/نسخه واحد معنادار است\&. .TP .B PATCH[#]= از آرایه دستورالعمل PATCH برای تعیین وصله‌هایی (patches) استفاده کنید که باید قبل از انجام ساخت روی کد منبع شما اعمال شوند\&. انتظار می‌رود تمام وصله‌ها در قالب .B \-p1 باشند و با دستور .B patch \-p1 اعمال می‌شوند\&. هر دستورالعمل باید نام پرونده وصله‌ای را که باید اعمال شود مشخص کند، و تمام وصله‌ها باید در زیرشاخه patches از شاخه کد منبع شما ( .I /usr/src/\-/patches/ ) یا در .I /etc/dkms//patches/ (که بر شاخه منبع اولویت دارد) قرار داشته باشند\&. اگر اعمال هر وصله‌ای با شکست مواجه شود، فرآیند ساخت متوقف خواهد شد و موارد رد شده را می‌توان در .I /var/lib/dkms///build/ بررسی کرد\&. اگر وصله‌ای فقط باید به‌صورت شرطی اعمال شود، باید از آرایه .B PATCH_MATCH[#] استفاده شود و یک عبارت باقاعده متناظر در .B PATCH_MATCH[#] قرار گیرد که به dkms هشدار می‌دهد تنها در صورتی از آن .B PATCH[#] استفاده کند که عبارت باقاعده با هسته‌ای که ماژول در حال حاضر برای آن ساخته می‌شود مطابقت داشته باشد\&. .TP .B PATCH_MATCH[#]= توضیحات فوق برای دستورالعمل‌های .B PATCH[#] را ببینید\&. اگر فقط می‌خواهید یک وصله در سناریوهای خاصی اعمال شود، آرایه .B PATCH_MATCH باید با ارائه یک عبارت باقاعده که با هسته‌های مد نظر شما برای اعمال .B PATCH[#] متناظر پیش از ساخت آن ماژول تطابق دارد، مورد استفاده قرار گیرد\&. .TP .B AUTOINSTALL= اگر این دستورالعمل روی "yes" تنظیم شود، سرویس autoinstaller مربوط به DKMS به‌طور خودکار تلاش می‌کند این ماژول را روی هر هسته‌ای که به آن بوت می‌شوید نصب کند\&. برای اطلاعات بیشتر به بخش .B نصب‌کننده خودکار DKMS (DKMS AUTOINSTALLER) مراجعه کنید\&. مقادیر معتبر "yes" یا "no" هستند\&. .TP .B BUILD_DEPENDS[#]= این دستورالعمل اختیاری آرایه‌ای است که به شما امکان می‌دهد ماژول‌های دیگر را به عنوان وابستگی‌های ماژول خود مشخص کنید\&. هر عنصر آرایه باید .B PACKAGE_NAME ماژول دیگری باشد که توسط dkms مدیریت می‌شود\&. نسخه یا معماری را در وابستگی مشخص نکنید\&. وجود یک وابستگی مفقود برای تلاش مجدد جهت ساخت ماژول به پارامتر .OP --force نیاز دارد\&. هنگامی که از طریق .B autoinstall فراخوانی می‌شود، وابستگی‌های حل‌نشده بسته به اینکه برای dkms شناخته‌شده هستند یا خیر، به‌طور متفاوتی مدیریت می‌شوند\&. وابستگی‌ای که خودش یک ماژول تحت مدیریت dkms است اما نصب آن ناموفق بوده است (برای مثال به دلیل یک وابستگی حلقوی یا خطای ساخت)، به عنوان یک شکست قطعی در نظر گرفته می‌شود و باعث می‌شود .B autoinstall با کد خروج غیرصفر خارج شود\&. وابستگی‌ای که در زمان اجرای .B autoinstall در dkms ثبت .I نشده است به عنوان معوق (deferred) در نظر گرفته می‌شود: یک هشدار صادر می‌شود و ماژول وابسته در وضعیت .B added باقی می‌ماند، اما .B autoinstall با موفقیت خارج می‌شود\&. این کار از خرابی‌های کاذب در هنگام نصب بسته‌های چندگانه که در آن بسته منبع وابستگی هنوز اسکریپت postinst خود را اجرا نکرده است، یا جایی که وابستگی توسط چیزی خارج از dkms تأمین می‌شود، جلوگیری می‌کند\&. ماژول وابسته به محض اینکه وابستگی در دسترس قرار گیرد، توسط تریگر بعدی .B autoinstall انتخاب و پردازش خواهد شد\&. مثال: یک سیستم اوبونتو با ماژول A و ماژول B که به A وابسته است\&. در طول یک به‌روزرسانی، هم هسته و هم ماژول A به‌روزرسانی می‌شوند، بنابراین .B autoinstall به عنوان قلاب پس از هسته (kernel post hook) اجرا می‌شود\&. این بدان معناست که کل منطق وابستگی با شکست مواجه می‌شود زیرا ماژول A هنوز برای برآورده کردن نیاز ماژول B نصب نشده است\&. .TP .B BUILD_DEPENDS_REBUILD= اگر این دستورالعمل روی .B yes تنظیم شود، ماژولی که .B BUILD_DEPENDS برای آن تنظیم شده است، هر بار که نسخه یک وابستگی تغییر کند، دوباره ساخته خواهد شد\&. این معمولاً در یک پرونده اختصاصی .I /etc/dkms/.conf به ازای هر نصب ارائه می‌شود\&. برای پیگیری تغییر وابستگی، نسخه ماژولی که در زمان ساخت استفاده شده در پرونده .I /var/lib/dkms//-/.dep_ ثبت می‌شود\&. به محض تغییر نسخه ماژول، این مورد مقایسه شده و ماژول وابسته دوباره ساخته می‌شود\&. با پارامتر .I --force وابستگی پیگیری نمی‌شود\&. .TP .B BUILD_EXCLUSIVE_KERNEL= این دستورالعمل اختیاری به شما امکان می‌دهد یک عبارت باقاعده را مشخص کنید که زیرمجموعه‌ای از هسته‌ها را که DKMS مجاز به ساخت ماژول شما برای آن‌هاست، تعریف می‌کند\&. اگر هسته‌ای که برای آن ساخته می‌شود با این عبارت باقاعده مطابقت نداشته باشد (یا محدودیت‌های هیچ دستورالعمل .B BUILD_EXCLUSIVE_* دیگری را برآورده نکند)، ساخت با کد خروج 77 دچار خطا خواهد شد\&. توجه داشته باشید که .B dkms autoinstall این نوع شرایط خطا را نادیده می‌گیرد و به سادگی از ماژول‌های مربوطه صرف‌نظر می‌کند\&. برای مثال، اگر آن را روی ="^2\.4.*" تنظیم کنید، ماژول شما برای هسته‌های 2.6 یا جدیدتر ساخته نخواهد شد\&. .TP .B BUILD_EXCLUSIVE_KERNEL_MIN= و .B BUILD_EXCLUSIVE_KERNEL_MAX= این دستورالعمل‌های اختیاری امکان تعیین حداقل و حداکثر نسخه‌های هسته پشتیبانی‌شده توسط ماژول را فراهم می‌کنند\&. اگر یک (یا هر دو) مورد از این‌ها تعریف شوند، ماژول برای هسته‌های خارج از محدودیت‌های نسخه مشخص‌شده ساخته نخواهد شد\&. برای مثال، اگر .B BUILD_EXCLUSIVE_KERNEL_MIN را روی "=3.5" تنظیم کنید، ماژول شما برای مواردی مانند "3.5-rc2"، "3.6.18" یا سایر نسخه‌های جدیدتر ساخته می‌شود اما برای "3.4.999" یا هسته‌های قدیمی‌تر ساخته نخواهد شد\&. به همین ترتیب، اگر .B BUILD_EXCLUSIVE_KERNEL_MAX را روی ="4.12" تنظیم کنید، ماژول شما برای مثال برای "4.11.999"، "3.9-rc5" یا سایر نسخه‌های قدیمی‌تر ساخته می‌شود، اما برای "4.12-rc1" یا هسته‌های جدیدتر ساخته نخواهد شد\&. .TP .B BUILD_EXCLUSIVE_ARCH= این دستورالعمل اختیاری عملکردی بسیار مشابه با .B BUILD_EXCLUSIVE_KERNEL دارد با این تفاوت که با معماری هسته مطابقت داده می‌شود\&. برای مثال، اگر آن را روی ="i.86" تنظیم کنید، ماژول شما برای ia32e، x86_64، amd64، s390 و غیره ساخته نخواهد شد\&. .TP .B BUILD_EXCLUSIVE_CONFIG= این دستورالعمل اختیاری به شما امکان می‌دهد فهرستی از گزینه‌های پیکربندی هسته ("CONFIG_FOO") جداشده با فاصله را مشخص کنید که برای ساخت ماژول باید در پرونده ".config" هسته‌های مورد نظر فعال باشند (یا به صورت کامپایل‌شده درون هسته یا برای ساخته شدن به عنوان یک ماژول) یا در صورت داشتن پیشوند علامت تعجب (مانند "!CONFIG_BAR") باید غایب باشند\&. برای مثال، اگر آن را روی ="CONFIG_PCI !CONFIG_PREEMPT_RT" تنظیم کنید، ماژول شما فقط برای هسته‌هایی ساخته می‌شود که PCI در آن‌ها فعال باشد، اما مجموعه وصله RT غیرفعال باشد\&. .TP .B BUILD_EXCLUSIVE_KERNEL[#]=, BUILD_EXCLUSIVE_KERNEL_MIN[#]=, BUILD_EXCLUSIVE_KERNEL_MAX[#]=, BUILD_EXCLUSIVE_ARCH[#]=, BUILD_EXCLUSIVE_CONFIG[#]= این دستورالعمل‌های اختیاری به ازای هر ماژول، عملکردی مشابه با همتایان سراسری خود دارند اما فقط برای ماژول خاص در اندیس داده‌شده اعمال می‌شوند\&. آن‌ها به شما امکان می‌دهند محدودیت‌های BUILD_EXCLUSIVE متفاوتی را برای هر ماژول در یک بسته چندماژولی تعیین کنید\&. دستورالعمل‌های سراسری BUILD_EXCLUSIVE همچنان برای سازگاری با گذشته بررسی می‌شوند، و اگر هر ماژولی در برآورده کردن محدودیت‌های سراسری یا محدودیت‌های ویژه هر ماژول خود ناموفق باشد، فرآیند ساخت آن رد (مستثنی) خواهد شد\&. برای مثال، اگر دو ماژول در بسته خود داشته باشید: .B BUILD_EXCLUSIVE_KERNEL[0]="^5\..*" .B BUILD_EXCLUSIVE_KERNEL[1]="^6\..*" ماژول 0 فقط برای هسته 5.x ساخته می‌شود، در حالی که ماژول 1 فقط برای هسته 6.x ساخته خواهد شد\&. .TP .B POST_ADD= نام اسکریپتی که باید پس از انجام یک عملیات .B add اجرا شود\&. مسیر باید به صورت نسبی نسبت به شاخه ریشه کد منبع شما داده شود\&. .TP .B POST_BUILD= نام اسکریپتی که باید پس از انجام یک عملیات .B build اجرا شود\&. مسیر باید به صورت نسبی نسبت به شاخه ریشه کد منبع شما داده شود\&. .TP .B POST_INSTALL= نام اسکریپتی که باید پس از انجام یک عملیات .B install اجرا شود\&. مسیر باید به صورت نسبی نسبت به شاخه ریشه کد منبع شما داده شود\&. .TP .B POST_REMOVE= نام اسکریپتی که باید پس از انجام یک عملیات .B remove اجرا شود\&. مسیر باید به صورت نسبی نسبت به شاخه ریشه کد منبع شما داده شود\&. .TP .B PRE_BUILD= نام اسکریپتی که باید پیش از انجام یک عملیات .B build اجرا شود\&. مسیر باید به صورت نسبی نسبت به شاخه ریشه کد منبع شما داده شود\&. .TP .B PRE_INSTALL= نام اسکریپتی که باید پیش از انجام یک عملیات .B install اجرا شود\&. مسیر باید به صورت نسبی نسبت به شاخه ریشه کد منبع شما داده شود\&. اگر اسکریپت با یک مقدار غیرصفر خارج شود، نصب لغو خواهد شد\&. این مورد معمولاً برای انجام یک مقایسه نسخه سفارشی استفاده می‌شود\&. .PP همه اسکریپت‌ها (POST_ADD، PRE_BUILD، POST_BUILD، PRE_INSTALL، POST_INSTALL، POST_REMOVE) می‌توانند به جای شاخه منبع ماژول، در .I /etc/dkms// نیز قرار گیرند\&. اسکریپت‌های موجود در .I /etc/dkms// بر اسکریپت‌های موجود در شاخه منبع اولویت دارند\&. .PP .SH "متغیرهای DKMS.CONF (DKMS.CONF VARIABLES)" درون پرونده پیکربندی DKMS خود، می‌توانید از متغیرهای خاصی استفاده کنید که در زمان اجرا با مقادیر خود جایگزین می‌شوند\&. .TP .B $kernelver این متغیر می‌تواند در داخل یک تعریف دستورالعمل استفاده شود و در حین استفاده، نسخه واقعی هسته مورد نظر به جای آن جایگزین خواهد شد\&. این امر به‌ویژه در دستورات .B MAKE هنگام تعیین عبارات INCLUDE که باید هنگام کامپایل ماژول شما استفاده شوند مفید است (مثلاً MAKE="make all INCLUDEDIR=/usr/lib/modules/${kernelver}/build/include")\&. .TP .B $kernel_source_dir این متغیر حاوی مقدار مکان شاخه کد منبع هسته شماست\&. معمولاً این مقدار برابر با .IR /usr/lib/modules/$kernelver/build خواهد بود، مگر اینکه با گزینه .B \-\-kernelsourcedir به گونه دیگری مشخص شده باشد\&. .SH "بازنویسی‌های DKMS.CONF (DKMS.CONF OVERRIDES)" می‌توانید دستورالعمل‌های ارائه‌شده در پرونده‌های .I dkms.conf ارائه‌شده توسط ماژول را بازنویسی (override) کنید\&. هر بار پس از خوانده شدن یک پرونده .IR dkms.conf ، برنامه dkms پرونده‌های زیر را به ترتیب جستجو کرده و می‌خواند: .PP .I /etc/dkms/.conf .br .I /etc/dkms/\-.conf .br .I /etc/dkms/\-\-.conf .br .I /etc/dkms/\-\-\-.conf .PP می‌توانید از این پرونده‌ها برای بازنویسی تنظیمات موجود در پرونده .I dkms.conf ارائه‌شده توسط ماژول استفاده کنید\&. .PP علاوه بر این، وصله‌ها و اسکریپت‌ها را می‌توان در .I /etc/dkms// قرار داد تا مواردی را که توسط درخت منبع ماژول ارائه شده‌اند بازنویسی کنند: .PP .I /etc/dkms//patches/ \(em پرونده‌های وصله (وصله‌های هم‌نام از شاخه منبع را بازنویسی می‌کنند؛ ساختار شاخه حفظ می‌شود، بنابراین وصله‌ها در زیرشاخه‌هایی مانند .I /etc/dkms//patches/subdir/patch.patch وصله متناظر .I subdir/patch.patch از درخت منبع را بازنویسی خواهند کرد) .br .I /etc/dkms// \(em اسکریپت‌های ارجاع‌شده توسط PRE_BUILD، POST_BUILD و غیره (اسکریپت‌های هم‌نام از شاخه منبع را بازنویسی می‌کنند) .SH "پیکربندی اصلی FRAMEWORK.CONF (FRAMEWORK.CONF MAIN CONFIGURATION)" پرونده پیکربندی .B /etc/dkms/framework.conf نحوه مدیریت کلی چارچوب DKMS را کنترل می‌کند\&. این پرونده هر بار که دستور .B dkms اجرا می‌شود، خوانده و اعمال (source) می‌گردد\&. کاربرد اصلی آن در حال حاضر تنظیم مقادیر پیش‌فرض متفاوت برای متغیرها است\&. این پرونده حاوی توضیحاتی برای هر یک از دستورالعمل‌هایی است که پشتیبانی می‌کند\&. علاوه بر .BR /etc/dkms/framework.conf ، هر پرونده‌ای که با الگوی تطبیق .B /etc/dkms/framework.conf.d/*.conf مطابقت داشته باشد نیز بارگذاری خواهد شد\&. .TP .B dkms_tree, source_tree, install_tree, tmp_location کنترل می‌کنند که DKMS از کدام پوشه‌ها برای مؤلفه‌ها و مصنوعات (artifacts) استفاده کند\&. .TP .B verbose می‌تواند روی هر مقداری غیر از مقدار تهی (null) تنظیم شود تا خروجی مفصل و پرحرف دستورات خارجی اجراشده در DKMS را فعال کند\&. .TP .B symlink_modules کنترل می‌کند که آیا ماژول‌های باینری در /usr/lib/modules کپی شوند یا فقط پیوندهای نمادین در آنجا ایجاد گردند\&. توجه داشته باشید که این متغیرها را می‌توان در خط فرمان نیز با گزینه‌های .BR \-\-dkmstree ، .BR \-\-sourcetree ، .B \-\-installtree و .B \-\-symlink-modules دستکاری کرد\&. .TP .B autoinstall_all_kernels توسط postinst مشترک برای ماژول‌های DKMS استفاده می‌شود\&. این متغیر کنترل می‌کند که آیا ساخت باید برای تمام هسته‌های نصب‌شده انجام شود یا فقط برای هسته فعلی و آخرین هسته نصب‌شده\&. این گزینه معادل خط فرمانی ندارد\&. .TP .B sign_file این مسیر باینری هسته .B sign-file است که برای امضای ماژول‌های هسته استفاده می‌شود\&. متغیر .B $kernelver می‌تواند در مسیر برای نمایش نسخه هسته مورد نظر استفاده شود\&. مسیر باینری به توزیع بستگی دارد\&. .TP .B mok_signing_key, mok_certificate مکان پرونده‌های کلید و گواهی مورد استفاده برای Secure Boot\&. متغیر .B $kernelver می‌تواند در مسیر برای نشان دادن نسخه هسته مورد نظر استفاده شود\&. نکته: اگر هر یک از پرونده‌های مشخص‌شده توسط .B mok_signing_key و .B mok_certificate وجود نداشته باشند، dkms هر دو پرونده را دوباره ایجاد خواهد کرد\&. متغیر .B mok_signing_key همچنین تا زمانی که برنامه .B sign-file از آن پشتیبانی کند، می‌تواند یک رشته "...:pkcs11" برای موتور PKCS#11 باشد\&. .TP .B modprobe_on_install ماژول‌های ساخته‌شده را پس از نصب موفقیت‌آمیز به‌طور خودکار بارگذاری می‌کند\&. .TP .B parallel_jobs حداکثر این تعداد کار را به‌صورت موازی اجرا می‌کند\&. .TP .B compress_gzip_opts, compress_xz_opts, compress_zstd_opts نحوه فشرده‌سازی ماژول‌ها را کنترل می‌کنند\&. به‌طور پیش‌فرض، بالاترین سطح فشرده‌سازی موجود استفاده می‌شود\&. .TP .B build_environment اگر این دستورالعمل روی هر مقدار غیر تهی تنظیم شود، هنگام ساخت ماژول‌ها، متغیرهای صادرشده (export شده) موجود در آن پرونده با دستور .B source به درون پوسته DKMS وارد (import) خواهند شد\&. می‌توان از آن برای تعیین یک .B gcc سفارشی نصب‌شده در یک مسیر سفارشی استفاده کرد؛ و متغیر .B $kernelver می‌تواند درون پرونده محیطی برای نشان دادن نسخه هسته هدف استفاده شود\&. چند مثال: تعریف یک اسکریپت سفارشی برای اشاره به یک GCC خاص ( .B export CC=/opt/gcc12/bin/gcc ): .B build_environment="/opt/gcc12/env" فعال‌سازی مجموعه نرم‌افزاری .B gcc-toolset-11 و استفاده از آن برای ساخت یک هسته UEK در Oracle Linux: .B build_environment="/opt/rh/gcc-toolset-11/enable" .TP .B post_transaction اگر این دستورالعمل روی هر مقدار غیر تهی تنظیم شود، محتوای دستورالعمل با هر دستوری که محتوای پوشه ماژول‌های هسته را تغییر دهد اجرا خواهد شد، یعنی .BR "dkms autoinstall" ، .B dkms install و .BR "dkms remove/unbuild/uninstall" \&. می‌تواند برای راه‌اندازی ساخت مجدد سراسری .B initrd یا فراخوانی اسکریپتی که کارهای دیگری انجام می‌دهد (مانند فراخوانی .BR kexec ، راه‌اندازی مجدد سرویس‌هایی که در بسته DKMS وجود ندارند و غیره) استفاده شود\&. این دستور با دستور توکار پوسته .B eval ساخته می‌شود و متغیر .B $kernelver می‌تواند برای نشان دادن نسخه هسته هدف استفاده شود\&. چند مثال: تولید مجدد دیسک رم (ram disk) برای هسته هدف: .B post_transaction="dracut --force --kver $kernelver" (به سبک Red Hat) یا .B post_transaction="update-initramfs -k $kernelver" (به سبک Debian)\&. اجرای یک اسکریپت دلخواه: .B post_transaction="/path/to/script.sh" راه‌اندازی مجدد یک سرویس: .B post_transaction="systemctl restart something.service" تولید مجدد دیسک رم برای تمام هسته‌های نصب‌شده، با نادیده گرفتن نسخه هسته ارائه‌شده به عنوان پارامتر: .B post_transaction="dracut --force --regenerate-all" (به سبک Red Hat) یا .B post_transaction="update-initramfs -k all" (به سبک Debian)\&. .SH "نصب‌کننده خودکار DKMS (DKMS AUTOINSTALLER)" سرویس autoinstaller مربوط به DKMS (که بسته به توزیع شما می‌تواند .B dkms_autoinstaller یا .B dkms.service باشد) یک سرویس زمان راه‌اندازی (boot-time) است که به‌طور خودکار هر ماژولی را که عبارت .B AUTOINSTALL="yes" در پرونده .I dkms.conf آن تنظیم شده باشد، نصب می‌کند\&. این سرویس بسیار ساده کار می‌کند و اگر چندین نسخه از یک ماژول در درخت DKMS سیستم شما وجود داشته باشد، هیچ کاری انجام نخواهد داد و در عوض توضیح می‌دهد که مداخله دستی لازم است\&. .SH "نویسندگان (AUTHOR)" Gary Lerhaupt, Emil Velikov, Simone Caronni, Xu Zhen .SH "صفحه وب (WEBPAGE)" .I https://github.com/dkms-project/dkms