¿Qué significa m en el archivo de configuración del kernel?

Question

CONFIG_UNIX=m 

Sé lo que significa y y n, pero ¿qué pasa con m?

Answer 1

Supongo que esto se refiere a lo mismo que el aviso (y, n, m) cuando se ejecuta make config; en ese caso, sería "módulo".

Tenga en cuenta que la compilación de sockets de dominio Unix (CONFIG_UNIX) como módulo es probablemente no una buena idea. Muchos de los componentes y programas del sistema dependen de ellos, y es posible que algunos servicios no se inicien si el módulo no se ha cargado en ese momento.

La mayoría de las funcionalidades en el kernel de Linux pueden compilarse en ("y") o excluirse ("n"), y gran parte de ellas también se pueden compilar como un módulo cargable. Esto tiene sentido cuando no sabes con certeza si necesitarás alguna función en el futuro.

Si lo compila como módulo y resulta que es necesario, funcionará, pero hasta entonces no hinchará el kernel.

Sin embargo, no tiene sentido configurar los sockets de dominio de Unix como un módulo, porque se necesitan en casi todas partes (por ejemplo, udev no se iniciará al inicio).

Si sabe que va a necesitar algo de todos modos, que debería ser "y", no "m"

Answer 2

Leer los extractos debajo de "Comprensión del núcleo Linux":

algún código de Linux necesariamente debe estar vinculado estáticamente, lo que significa que o el componente correspondiente está incluido en el kernel o no está compilado en absoluto. Esto sucede típicamente cuando el componente requiere una modificación a alguna estructura de datos o función enlazada estáticamente 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 usa su versión modificada de la estructura de datos, todos los códigos vinculados estáticamente continúan viendo la versión anterior. La corrupción de datos ocurre fácilmente. Una solución parcial al problema consiste en agregar "estáticamente" los nuevos campos al descriptor del proceso, de modo que estén disponibles para el componente kernel sin importar cómo se haya vinculado. Sin embargo, si nunca se utiliza el componente kernel, dichos campos extra replicados en cada descriptor de proceso son una pérdida de memoria. Si el nuevo componente kernel aumenta mucho el tamaño del descriptor del proceso, se obtendría un mejor rendimiento del sistema agregando los campos requeridos en la estructura de datos solo si el componente está vinculado estáticamente al kernel.

Como segundo ejemplo, considere un componente kernel que tiene que reemplazar el código vinculado estáticamente. Está bastante claro que no se puede compilar tal componente como un módulo, porque el kernel no puede cambiar el código de la máquina que ya está en la RAM al vincular el módulo. Por ejemplo, no es posible vincular un módulo que cambie la forma en que se asignan los marcos de página, porque las funciones del sistema Buddy siempre están vinculadas estáticamente al kernel.