44
CONFIG_UNIX=m

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

compile-fan
  • 16,885
  • 22
  • 59
  • 73
  • 3
    Not programming-related - belongs on http://superuser.com – Paul R Mar 22 '11 at 14:57
  • Stack Overflow is a site for programming and development questions. This question appears to be off-topic because it is not about programming or development. See [What topics can I ask about here](http://stackoverflow.com/help/on-topic) in the Help Center. Perhaps [Super User](http://superuser.com/) or [Unix & Linux Stack Exchange](http://unix.stackexchange.com/) would be a better place to ask. Also see [Where do I post questions about Dev Ops?](http://meta.stackexchange.com/q/134306). – jww Apr 03 '16 at 19:57

3 Answers3

44

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"

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
Damon
  • 67,688
  • 20
  • 135
  • 185
  • 2
    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 exactly if 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. For unix domain sockets, it does not _really_ make sense to configure as module, because it is 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". – Damon Mar 22 '11 at 15:00
6
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/

yabo
  • 407
  • 5
  • 6
2

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.

Gyan
  • 21
  • 1