linux-kernel - modprobe - listar modulos kernel en ejecucion linux
¿Qué significa m en el archivo de configuración del kernel? (2)
Supongo que esto se refiere a lo mismo que el indicador (y, n, m) cuando se ejecuta make config; En ese caso sería "módulo".
Tenga en cuenta que compilar sockets de dominio Unix (CONFIG_UNIX) como módulo probablemente no sea una buena idea. Muchos de los componentes y programas del sistema dependen de ellos, y es posible que algunos servicios no puedan iniciarse si el módulo no se ha cargado en ese momento.
La mayoría de las funciones en el kernel de Linux se pueden compilar en ("y") o se pueden dejar de lado ("n"), y gran parte de ellas también se pueden compilar como un módulo cargable. Esto tiene sentido cuando no sabe con certeza si necesitará alguna característica en el futuro.
Si lo compila como módulo y resulta que es necesario, funcionará, pero hasta entonces no hinchará el núcleo.
Sin embargo, no tiene mucho sentido configurar los sockets de dominio Unix como un módulo, ya que se necesitan en casi todas partes (por ejemplo, udev no se iniciará al inicio).
Si sabes que necesitarás algo de todos modos, eso debería ser "y", no "m".
CONFIG_UNIX=m
Sé lo que y y n representan, pero ¿qué pasa con m ?
Lea los siguientes extractos de "Understanding Linux Kernel":
Algunos códigos de Linux deben estar necesariamente vinculados de forma estática, lo que significa que el componente correspondiente está incluido en el kernel o no está compilado en absoluto. Esto ocurre normalmente cuando el componente requiere una modificación de alguna estructura de datos o función estáticamente vinculada en el kernel.
Por ejemplo, supongamos que el componente tiene que introducir nuevos campos en el descriptor del proceso. La vinculación de un módulo no puede cambiar una estructura de datos ya definida como task_struct porque, incluso si el módulo utiliza su versión modificada de la estructura de datos, todos los códigos vinculados estáticamente siguen viendo la versión anterior. La corrupción de datos se produce fácilmente. Una solución parcial al problema consiste en agregar "de forma estática" los nuevos campos al descriptor del proceso, por lo que los pone a disposición del componente del kernel sin importar cómo se haya vinculado. Sin embargo, si el componente del kernel nunca se usa, los campos adicionales replicados en cada descriptor de proceso son un desperdicio de memoria. Si el nuevo componente del kernel aumenta mucho el tamaño del descriptor del proceso, se podría obtener un mejor rendimiento del sistema agregando los campos requeridos en la estructura de datos solo si el componente está estáticamente vinculado al kernel.
Como segundo ejemplo, considere un componente del kernel que tiene que reemplazar el código enlazado estáticamente. Es bastante claro que ningún componente de este tipo puede compilarse como un módulo, porque el kernel no puede cambiar el código de máquina que ya se encuentra en la RAM cuando se vincula el módulo. Por ejemplo, no es posible vincular un módulo que cambia la forma en que se asignan los marcos de página, ya que las funciones del sistema Buddy siempre están vinculadas estáticamente al núcleo.