Відповіді:
Це залежить. Якщо у вас є невеликий об'єм пам'яті, використання модулів може покращити резюме, оскільки вони не перезавантажуються кожен раз (я вважав це значним на 2 Гб оперативної пам'яті, але не на 4 ГБ на традиційних жорстких дисках). Особливо це стосується того, що через деяку помилку в модулі акумулятора (незалежно від того, чи він складений або як модуль), це зайняло дуже багато часу (кілька хвилин). Навіть без помилок на gentoo мені вдалося скоротити час (повідомляється systemd-analysis) з 33-х до 18-х років, просто змінивши зі статично складеного ядра на модулі - "на диво" початок ядра змінився з 9 на 1,5.
Крім того, коли ви не знаєте, яким обладнанням ви збираєтесь користуватися, модулі явно виграють.
PS. Ви можете складати навіть життєво важливі драйвери як модулі до тих пір, поки ви включите їх у initrd. Наприклад, дистрибутив буде включати файлову систему /, драйвери жорсткого диска тощо в initrd при встановленні.
Наскільки я знаю, різниці в швидкості немає.
Я думаю, ви отримаєте кілька кБ пам'яті ядра, оскільки деталізація виділень становить одну сторінку, тому в типовій архітектурі кожен модуль витрачає в середньому близько 2 кБ (½ сторінки) на потенційний модуль. Навіть на вбудованих системах це навряд чи важливо. Ви також отримуєте трохи місця на диску, оскільки модулі можна стискати так само, як і ядро; що може бути більш актуальним у вбудованих системах із невеликим запасом пам’яті.
Якщо ви взагалі не можете використовувати модулі, ви економите трохи пам’яті ядра (не потрібно завантажувача модулів), дискового простору (не потрібно утиліти модуля) та складності системи (не потрібно включати завантаження модуля як функцію у свій дистрибутив ). Ці точки досить привабливі в деяких вбудованих конструкціях, де апаратне забезпечення не розширюється.
Пара потенційних переваг. Продуктивність сперечається. Ви б уникали накладних витрат, пов'язаних з динамічним завантажувачем, але я сумніваюся, що це велика справа, якщо ви не залежите від планувальника в реальному часі.
Якщо ви використовуєте великі сторінки у вашій системі, можливо, створення більшого статичного зображення ядра означає, що ви ефективніше використовуєте кеш дескриптора сторінки. Деякі системи будуть «уклеювати» ядро так, щоб воно щільно упаковувалося в одній локальній пам’яті, що може полегшити деяку кількість затримок через незначні та, можливо, основні помилки сторінки.
В архітектурному відношенні це може вам подобатися, щоб надати одне велике зображення, стверджуючи, що менше незалежних модулів легше підтримувати, а втрата гнучкості не важлива. Дуже багато подібних міркувань займаються питаннями стилю та практики.
Іноді це необхідно. Якщо ви компілюєте якийсь життєвий драйвер (наприклад, драйвер SCSI) як модуль, система не завантажиться.
Ще один відмінний кандидат для НЕ компіляцій в якості модуля є типом файлової системи кореневого розділу. Якщо ядро не розуміє, ext3читати, /lib/modules/як буде завантажувати модулі з нього?
Подумайте про це так: щоб використовувати модулі, ядро повинно знати достатньо про вашу систему для читання та завантаження модулів ядра. Використовуйте це та пробну помилку :-)
Я статично компілюю кожен драйвер для вбудованого обладнання всередині ядра. Винятком буде апаратне забезпечення, яке не є постійним (наприклад, апаратне забезпечення, підключене до usb).
Оскільки моя конфігурація обладнання, швидше за все, не зміниться незабаром, я не морочуся модулями.