Что означает m в файле конфигурации ядра?

Ответ 1

Я предполагаю, что это относится к тому же, что и приглашение (y, n, m) при запуске make config; в этом случае это будет "модуль".

Обратите внимание, что компиляция сокетов домена Unix (CONFIG_UNIX) в качестве модуля, вероятно, не очень хорошая идея. На них зависят многие системные компоненты и программы, и некоторые службы могут не запускаться, если модуль не был загружен в это время.

Большинство функций ядра Linux можно либо скомпилировать в ( "y" ), либо оставить вне ( "n" ), и большая часть его также может быть скомпилирована как загружаемый модуль. Это имеет смысл, если вы не знаете наверняка, нужна ли вам какая-то функция в будущем.

Если вы скомпилируете его как модуль и выяснится, что он нужен, он будет работать, но до тех пор он не раздует ядро.

Однако не имеет смысла настраивать сокеты домена Unix как модуль, потому что они нужны почти везде (например, udev не запускается при запуске).

Если вы знаете, что вам что-то понадобится, это должно быть "y", а не "m"

Ответ 2

Прочитайте приведенные ниже выдержки из "Понимание ядра Linux":

некоторый код Linux обязательно должен быть связан статически, что означает, что либо соответствующий компонент включен в ядро, либо он вообще не скомпилирован. Обычно это происходит, когда компонент требует модификации некоторой структуры данных или функции, статически связанной в ядре.

Например, предположим, что компонент должен ввести новые поля в дескриптор процесса. Связывание модуля не может изменить уже определенную структуру данных, такую ​​как task_struct, потому что, даже если модуль использует свою модифицированную версию структуры данных, все статически связанные коды продолжают видеть старую версию. Повреждение данных легко происходит. Частичное решение проблемы состоит из "статического" добавления новых полей в дескриптор процесса, что делает их доступными для компонента ядра независимо от того, как он был связан. Однако, если компонент ядра никогда не используется, такие дополнительные поля, реплицированные в каждом дескрипторе процесса, являются пустой тратой памяти. Если новый компонент ядра значительно увеличивает размер дескриптора процесса, можно повысить производительность системы, добавив необходимые поля в структуру данных только в том случае, если компонент статически связан с ядром.

В качестве второго примера рассмотрим компонент ядра, который должен заменить статически связанный код. Довольно ясно, что такой компонент не может быть скомпилирован как модуль, потому что ядро ​​не может изменить машинный код уже в ОЗУ при связывании модуля. Например, невозможно связать модуль, который изменяет способ распределения кадровых фреймов, поскольку функции системы Buddy всегда статически связаны с ядром.