What does m mean in kernel configuration file?

CONFIG_UNIX=m
开发者_如何学编程

I know what y and n stand for,but what about m?

---

I assume, this refers to the same as the (y,n,m) prompt when running make config; in that case it would be "module".

Note that compiling Unix domain sockets (CONFIG_UNIX) as module is probably not a good idea. A lot of system components and programs depend on them, and some services might fail to start up if the module has not been loaded at that time.

Most functionality in the Linux kernel can either be compiled in ("y") or left out ("n"), and much of it can also be compiled as a loadable module. This makes sense when you don't know for certain whether you will need some feature in the future.

If you compile it as module and it turns out that it is needed, it will work, but until then it will not bloat the kernel.

It does not, however, really make sense to configure Unix domain sockets as a module, because they are needed almost everywhere (e.g. udev will fail to launch at startup).

If you know you will need something anyway, that should be "y", not "m"

---

y  =  yes (always installed)
m  =  loadable module (can install and uninstall as you wish)
n  =  no (never installed)

see: https://www.linuxquestions.org/questions/linux-general-1/boot-config%2A-273853/

---

Read the below excerpts from "Understanding Linux Kernel ":

some Linux code must necessarily be linked statically, which means that either the corresponding component is included in the kernel or it is not compiled at all. This happens typically when the component requires a modification to some data structure or function statically linked in the kernel.

For example, suppose the component has to introduce new fields into the process descriptor. Linking a module cannot change an already defined data structure such as task_struct because, even if the module uses its modified version of the data structure, all statically linked code continues to see the old version. Data corruption easily occurs. A partial solution to the problem consists of "statically" adding the new fields to the process descriptor, thus making them available to the kernel component no matter how it has been linked. However, if the kernel component is never used, such extra fields replicated in every process descriptor are a waste of memory. If the new kernel component increases the size of the process descriptor a lot, one would get better system performance by adding the required fields in the data structure only if the component is statically linked to the kernel.

As a second example, consider a kernel component that has to replace statically linked code. It's pretty clear that no such component can be compiled as a module, because the kernel cannot change the machine code already in RAM when linking the module. For instance, it is not possible to link a module that changes the way page frames are allocated, because the Buddy system functions are always statically linked to the kernel.