.\" Generated by scdoc 1.11.3
.\" Complete documentation for this program is not available as a GNU info page
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.nh
.ad l
.\" Begin generated content:
.TH "DEPMOD" "8" "2025-03-28" "kmod" "depmod"
.PP
.SH "نام (NAME)"
depmod \- ایجاد فایل‌های modules.\&dep و فایل‌های نگاشت
.PP
.SH "خلاصه دستور (SYNOPSIS)"
.PP
\fBdepmod\fR [\fB-b\fR \fIbasedir\fR] [\fB-m\fR \fImoduledir\fR] [\fB-o\fR \fIoutdir\fR] [\fB-e\fR] [\fB-E\fR \fIModule.\&symvers\fR]
       [\fB-F\fR \fISystem.\&map\fR] [\fB-n\fR] [\fB-v\fR] [\fB-A\fR] [\fB-P\fR \fIprefix\fR] [\fB-w\fR] [\fIversion\fR]
.PP
\fBdepmod\fR [\fB-e\fR] [\fB-E\fR \fIModule.\&symvers\fR] [\fB-F\fR \fISystem.\&map\fR] [\fB-n\fR] [\fB-v\fR] [\fB-P\fR \fIprefix\fR]
       [\fB-w\fR] [\fIversion\fR] [\fIfilename\fR.\&.\&.\&]
.PP
.SH "توضیحات (DESCRIPTION)"
.PP
ماژول‌های هسته لینوکس می‌توانند خدماتی (با نام «نمادها» یا symbols) را برای استفاده سایر ماژول‌ها ارائه دهند (با استفاده از یکی از انواع \fBEXPORT_SYMBOL\fR در کد منبع).\& اگر ماژول دومی از این نماد استفاده کند، مشخصاً به ماژول اول وابسته است.\& این وابستگی‌ها می‌توانند بسیار پیچیده شوند.\&
.PP
دستور \fBdepmod\fR با خواندن تمام ماژول‌های موجود در مسیر <BASEDIR>/<MODULEDIR>/\fIversion\fR فهرستی از وابستگی‌های ماژول‌ها ایجاد می‌کند.\& به‌طور پیش‌فرض <MODULEDIR> برابر /lib/modules و <BASEDIR> خالی است.\& برای بازنویسی و تغییر این مقادیر در صورت نیاز، گزینه‌های زیر را ببینید.\& این دستور مشخص می‌کند که هر ماژول چه نمادهایی را صادر (export) کرده و به چه نمادهایی نیاز دارد.\& این فهرست در فایل \fBmodules.\&dep\fR و نسخه دودویی هش‌شده آن به نام modules.\&dep.\&bin در همان دایرکتوری ذخیره می‌شود.\& اگر نام فایل‌ها در خط فرمان مشخص شده باشد، تنها آن ماژول‌ها بررسی می‌شوند (که به‌ندرت کاربرد دارد مگر اینکه تمام ماژول‌ها فهرست شده باشند).\& همچنین \fBdepmod\fR فهرستی از نمادهای ارائه‌شده توسط ماژول‌ها را در فایلی با نام modules.\&symbols و نسخه دودویی هش‌شده آن، modules.\&symbols.\&bin ایجاد می‌کند.\& در نهایت، اگر ماژول‌ها نام‌های خاص دستگاه (devname) را ارائه دهند که باید در زمان بوت (توسط ابزاری مانند systemd-tmpfiles) در /dev بارگذاری شوند، \fBdepmod\fR فایلی با نام modules.\&devname تولید خواهد کرد.\&
.PP
اگر یک \fIversion\fR (نسخه) مشخص شود، دایرکتوری ماژول مربوط به آن نسخه هسته به‌جای نسخه جاری هسته (که توسط \fBuname -r\fR برگردانده می‌شود) استفاده خواهد شد.\&
.PP
.SH "گزینه‌ها (OPTIONS)"
.PP
\fB-a\fR, \fB--all\fR
.RS 4
پویش و بررسی تمام ماژول‌ها.\& این گزینه در صورتی که هیچ نام فایلی در خط فرمان مشخص نشده باشد، به‌طور پیش‌فرض فعال است.\&
.PP
.RE
\fB-A\fR, \fB--quick\fR
.RS 4
این گزینه پیش از انجام هر کاری بررسی می‌کند که آیا ماژولی جدیدتر از فایل \fBmodules.\&dep\fR وجود دارد یا خیر؛ در صورتی که ماژول جدیدتری نباشد، به‌جای بازتولید فایل‌ها، بدون هیچ خروجی خارج می‌شود.\&
.PP
.RE
\fB-b\fR \fIbasedir\fR, \fB--basedir\fR=\fIbasedir\fR
.RS 4
بازنویسی دایرکتوری پایه <BASEDIR> که ماژول‌ها در آن قرار دارند.\& اگر ماژول‌های شما در حال حاضر در دایرکتوری (عادی) /lib/modules/\fIversion\fR قرار ندارند، بلکه در یک ناحیه آماده‌سازی (staging) هستند، می‌توانید یک \fIbasedir\fR مشخص کنید که به ابتدای نام دایرکتوری اضافه شود.\& این \fIbasedir\fR از فایل حاصل \fBmodules.\&dep\fR حذف می‌شود، بنابراین آماده انتقال به مکان عادی خواهد بود.\& اگر توزیع‌کننده‌ای هستید که نیاز دارید فایل‌های متادیتا را پیشاپیش ایجاد کنید به‌جای اینکه بعداً دوباره \fBdepmod\fR را اجرا نمایید، از این گزینه استفاده کنید.\&
.PP
اگر یک مسیر نسبی داده شود، نسبت به دایرکتوری کاری جاری محاسبه می‌شود.\&
.PP
مثال:
.RS 4
depmod -b /my/build/staging/dir/
.PP
.RE
این دستور انتظار دارد تمام فایل‌های ورودی در مسیر
\fI/my/build/staging/dir/lib/modules/$(uname -r)\fR
باشند و فایل‌های نمایه را زیر همان دایرکتوری تولید می‌کند.\&
.PP
.RE
\fB-m\fR \fImoduledir\fR, \fB--moduledir\fR=\fImoduledir\fR
.RS 4
بازنویسی دایرکتوری ماژول <MODULEDIR> که به‌طور پیش‌فرض برابر با پیشوند /lib/modules تعیین‌شده در زمان ساخت است.\& این گزینه هنگام ساخت فایل \fBmodules.\&dep\fR در \fIbasedir\fR برای سیستمی که از پیشوند متفاوتی استفاده می‌کند (مانند \fI/usr/lib/modules\fR در مقایسه با \fI/lib/modules\fR) کاربرد دارد.\&
.PP
مسیرهای نسبی و مطلق پذیرفته می‌شوند، اما همیشه نسبت به \fIbasedir\fR سنجیده می‌شوند.\&
.PP
مثال‌ها:
.RS 4
depmod -b /tmp/build -m /kernel-modules
.br
depmod -b /tmp/build -m kernel-modules
.PP
.RE
این دستور انتظار دارد تمام فایل‌های ورودی در مسیر
\fI/tmp/build/kernel-modules/$(uname -r)\fR
قرار داشته باشند و فایل‌های نمایه را زیر همان دایرکتوری تولید می‌کند.\&
.PP
بدون آرگومان همگام \fB-b\fR، مقدار moduledir نسبت به \fI/\fR سنجیده می‌شود.\&
.PP
مثال:
.RS 4
depmod -m foo/bar
.PP
.RE
این دستور انتظار دارد تمام فایل‌های ورودی در مسیر \fI/foo/bar/$(uname -r)\fR باشند و فایل‌های نمایه را در همان دایرکتوری تولید می‌کند.\& توجه داشته باشید که مگر در صورتی که libkmod برای مدیریت این مکان دلخواه آماده شده باشد، در زمان اجرا کار نخواهد کرد.\&
.PP
.PP
.RE
\fB-o\fR \fIoutdir\fR, \fB--outdir\fR=\fIoutdir\fR
.RS 4
تعیین دایرکتوری خروجی که در آن \fBdepmod\fR فایل‌های تولیدشده را ذخیره خواهد کرد.\& \fIoutdir\fR مشابه با نحوه استفاده از \fIbasedir\fR به عنوان ریشه آن مکان عمل می‌کند.\& همچنین این تنظیم اولویت دارد و در صورت استفاده همراه با \fIbasedir\fR، ورودی از آن دایرکتوری خوانده شده اما خروجی در مکان تعیین‌شده با \fIoutdir\fR ذخیره می‌شود.\&
.PP
اگر یک مسیر نسبی داده شود، نسبت به دایرکتوری کاری جاری محاسبه می‌شود.\&
.PP
مثال:
.RS 4
depmod -o /my/build/staging/dir/
.PP
.RE
این دستور انتظار دارد تمام فایل‌های ورودی زیر مسیر
\fI/lib/modules/$(uname -r)\fR
باشند و فایل‌های نمایه را در مسیر
\fI/my/build/staging/dir/lib/modules/$(uname -r)\fR
تولید می‌کند.\&
.PP
.RE
\fB-C\fR \fIfile\fR \fIor\fR \fIdirectory\fR, \fB--config\fR=\fIfile\fR \fIor\fR \fIdirectory\fR
.RS 4
این گزینه فایل‌های پیکربندی پیش‌فرض را بازنویسی می‌کند.\& به
\fBdepmod.\&d\fR(5)
مراجعه کنید.\&
.PP
.RE
\fB-e\fR, \fB--errsyms\fR
.RS 4
در صورت ترکیب با گزینه \fB-F\fR، هر نمادی را که یک ماژول نیاز دارد اما توسط سایر ماژول‌ها یا هسته ارائه نشده است گزارش می‌کند.\& به‌طور معمول فرض بر این است که نمادهای ارائه‌نشده توسط ماژول‌ها توسط هسته تأمین می‌شوند (که در یک سیستم ایده‌آل باید چنین باشد)، اما این فرض به‌ویژه هنگامی که درایورهای شخص ثالثِ به‌روزرسانی‌شده به‌درستی نصب نشده یا اشتباه ساخته شده باشند ممکن است نقض شود.\&
.PP
.RE
\fB-E\fR \fIModule.\&symvers\fR, \fB--symvers\fR=\fIModule.\&symvers\fR
.RS 4
در صورت ترکیب با گزینه \fB-e\fR، هر نسخه از نمادهای ارائه‌شده توسط ماژول‌ها را که با نسخه نماد ارائه‌شده توسط هسته در فایل \fIModule.\&symvers\fR مطابقت ندارد گزارش می‌کند.\& این گزینه با \fB-F\fR ناسازگار است.\&
.PP
.RE
\fB-F\fR \fISystem.\&map\fR, \fB--filesyms\fR=\fISystem.\&map\fR
.RS 4
با ارائه فایل \fISystem.\&map\fR تولیدشده در زمان ساخت هسته، به گزینه \fB-e\fR اجازه می‌دهد نمادهای حل‌نشده را گزارش کند.\& این گزینه با \fB-E\fR ناسازگار است.\&
.PP
.RE
\fB-h\fR, \fB--help\fR
.RS 4
چاپ پیام راهنما و خروج.\&
.PP
.RE
\fB-n\fR, \fB--show\fR, \fB--dry-run\fR
.RS 4
فایل حاصل \fBmodules.\&dep\fR و انواع فایل‌های نگاشت (map) را به‌جای نوشتن در دایرکتوری ماژول، به خروجی استاندارد ارسال می‌کند.\&
.PP
.RE
\fB-P\fR
.RS 4
برخی معماری‌ها کاراکتری اضافی را به ابتدای نمادها اضافه می‌کنند.\& این گزینه یک کاراکتر پیشوند (برای مثال '_') را برای نادیده گرفتن مشخص می‌کند.\&
.PP
.RE
\fB-v\fR, \fB--verbose\fR
.RS 4
در حالت پرگو (verbose)، دستور \fBdepmod\fR تمام نمادهایی را که هر ماژول به آن‌ها وابسته است و همچنین نام فایل ماژولی را که آن نماد را تأمین می‌کند در خروجی استاندارد چاپ می‌کند.\&
.PP
.RE
\fB-V\fR, \fB--version\fR
.RS 4
نمایش نسخه برنامه و خروج.\& برای نکات مربوط به اجرا روی هسته‌های قدیمی‌تر به بخش‌های پایین مراجعه کنید.\&
.PP
.RE
\fB-w\fR
.RS 4
هشدار در مورد وابستگی‌ها، نام‌های مستعار (alias)، نسخه‌های نماد تکراری و موارد مشابه.\&
.PP
.RE
.SH "کپی‌رایت (COPYRIGHT)"
.PP
حق نشر این صفحه راهنما در اصل متعلق به 2002، Rusty Russell، شرکت IBM Corporation است.\&
بخشی از حق نشر متعلق به Jon Masters و دیگران است.\&
.PP
.SH "همچنین ببینید (SEE ALSO)"
.PP
\fBdepmod.\&d\fR(5), \fBmodprobe\fR(8), \fBmodules.\&dep\fR(5)
.PP
.SH "گزارش باگ‌ها (REPORTING BUGS)"
.PP
لطفاً هرگونه گزارش باگ را همراه با نسخه استفاده‌شده، مراحل بازتولید مشکل و خروجی مورد انتظار به بخش پیگیری مسائل kmod ارسال کنید:
.br
<https://github.com/kmod-project/kmod/issues>
.PP
.SH "نویسندگان (AUTHORS)"
.PP
مشارکت‌های فراوانی از طریق فهرست پستی linux-modules به نشانی
<linux-modules@vger.kernel.org>
و گیت‌هاب انجام شده است.\& اگر رونوشتی از خود مخزن kmod.\&git در اختیار دارید، خروجی دستورات \fBgit-shortlog\fR(1) و \fBgit-blame\fR(1) می‌تواند نویسندگان بخش‌های خاص پروژه را به شما نشان دهد.\&
.PP
\fBLucas De Marchi\fR <lucas.de.marchi@gmail.com> نگه‌دارنده فعلی این پروژه است.\&