¿Por qué el kernel de Linux tiene más de 15 millones de líneas de código? [cerrado]

¿Cuáles son los contenidos de esta base de código monolítico?

Entiendo el soporte de la arquitectura del procesador, la seguridad y la virtualización, pero no puedo imaginar que sean más de 600,000 líneas más o menos.

¿Cuáles son los motivos históricos y actuales por los que se incluyen los controladores en la base del código del núcleo?

¿Esos más de 15 millones de líneas incluyen cada controlador para cada pieza de hardware? Si es así, entonces surge la pregunta, ¿por qué los controladores están integrados en el kernel y no paquetes separados que se detectan automáticamente e instalan desde las ID de hardware?

¿Es el tamaño de la base del código un problema para dispositivos con almacenamiento limitado o con memoria?

Parece que aumentaría el tamaño del kernel para dispositivos ARM con espacio limitado si todo eso estuviera incrustado. ¿Hay muchas líneas seleccionadas por el preprocesador? Llámame loco, pero no puedo imaginar una máquina que necesite tanta lógica para ejecutar lo que entiendo son los roles de un núcleo.

¿Hay evidencia de que el tamaño será un problema en más de 50 años debido a su naturaleza aparentemente cada vez mayor?

La inclusión de controladores significa que crecerá a medida que se haga el hardware.

EDITAR : Para aquellos que piensan que esta es la naturaleza de los núcleos, después de algunas investigaciones me di cuenta de que no siempre es así. No se requiere que un núcleo sea tan grande, ya que el microkernel Mach de Carnegie Mellon se enumeró como un ejemplo 'generalmente bajo 10,000 líneas de código'

Los controladores se mantienen en el núcleo, por lo que cuando un cambio en el núcleo requiere una búsqueda y reemplazo global (o modificación de búsqueda y mano) para todos los usuarios de una función, la persona que realiza el cambio lo hace. Hacer que su controlador sea actualizado por personas que realizan cambios en la API es una ventaja muy buena, en lugar de tener que hacerlo usted mismo cuando no se compila en un kernel más reciente.

La alternativa (que es lo que sucede para los controladores mantenidos fuera del árbol), es que el parche debe ser sincronizado nuevamente por sus mantenedores para mantenerse al día con cualquier cambio.

Una búsqueda rápida generó un debate sobre el desarrollo de controladores dentro del árbol o fuera del árbol .

La forma en que se mantiene Linux es principalmente manteniendo todo en el repositorio principal. La construcción de pequeños núcleos despojados es compatible con las opciones de configuración para controlar #ifdefs. Por lo tanto, puede construir absolutamente pequeños núcleos despojados que compilan solo una pequeña parte del código en todo el repositorio.

El uso extensivo de Linux en sistemas embebidos ha llevado a un mejor soporte para dejar de lado las cosas que Linux tenía años antes cuando el árbol de fuentes del núcleo era más pequeño. Un núcleo súper mínimo 4.0 es probablemente más pequeño que un núcleo súper mínimo 2.4.0.

De acuerdo con cloc ejecutado contra 3.13, Linux tiene aproximadamente 12 millones de líneas de código.

• 7 millones de LOC en conductores /
• 2 millones de LOC en arco /
• solo 139 mil LOC en kernel /

lsmod | wc en mi computadora portátil Debian se muestran 158 módulos cargados en tiempo de ejecución, por lo que cargar módulos dinámicamente es una forma muy utilizada de soportar hardware.

El sistema de configuración robusto (p make menuconfig. Ej. ) Se utiliza para seleccionar qué código compilar (y más a su punto, qué código no compilar). Los sistemas integrados definen su propio .configarchivo con el soporte de hardware que les interesa (incluido el soporte de hardware integrado en el núcleo o como módulos cargables).

Para cualquier persona curiosa, aquí está el desglose del recuento de líneas para el espejo GitHub:

=============================================
    Item           Lines             %
=============================================
  ./usr                 845        0.0042
  ./init              5,739        0.0283
  ./samples           8,758        0.0432
  ./ipc               8,926        0.0440
  ./virt             10,701        0.0527
  ./block            37,845        0.1865
  ./security         74,844        0.3688
  ./crypto           90,327        0.4451
  ./scripts          91,474        0.4507
  ./lib             109,466        0.5394
  ./mm              110,035        0.5422
  ./firmware        129,084        0.6361
  ./tools           232,123        1.1438
  ./kernel          246,369        1.2140
  ./Documentation   569,944        2.8085
  ./include         715,349        3.5250
  ./sound           886,892        4.3703
  ./net             899,167        4.4307
  ./fs            1,179,220        5.8107
  ./arch          3,398,176       16.7449
  ./drivers      11,488,536       56.6110
=============================================

driverscontribuye a gran parte del recuento de líneas.

Las respuestas hasta ahora parecen ser "sí, hay mucho código" y nadie está abordando la pregunta con la respuesta más lógica: ¿ 15M +? ¿Y QUÉ? ¿Qué tienen que ver las 15 millones de líneas de código fuente con el precio del pescado? ¿Qué hace que esto sea tan inimaginable?

Linux claramente hace mucho. Mucho más que cualquier otra cosa ... Pero algunos de sus puntos muestran que no respeta lo que sucede cuando se construye y usa.

• No todo está compilado. El sistema de compilación Kernel le permite definir rápidamente configuraciones que seleccionan conjuntos de código fuente. Algunos son experimentales, algunos son viejos, algunos simplemente no son necesarios para todos los sistemas. Mire /boot/config-$(uname -r)(en Ubuntu) make menuconfigy verá cuánto está excluido.

  Y esa es una distribución de escritorio de destino variable. La configuración para un sistema incrustado solo atraerá las cosas que necesita.

• No todo está incorporado. En mi configuración, la mayoría de las características del Kernel se crean como módulos:

  grep -c '=m' /boot/config-`uname -r`  # 4078
  grep -c '=y' /boot/config-`uname -r`  # 1944
  

  Para ser claros, todos estos podrían incorporarse ... Así como podrían imprimirse y convertirse en un sándwich de papel gigante. Simplemente no tendría sentido a menos que estuviera haciendo una compilación personalizada para un trabajo de hardware discreto (en cuyo caso, ya habría limitado el número de estos elementos).

• Los módulos se cargan dinámicamente. Incluso cuando un sistema tiene miles de módulos disponibles, el sistema le permitirá cargar solo lo que necesita. Compare las salidas de:

  find /lib/modules/$(uname -r)/ -iname '*.ko' | wc -l  # 4291
  lsmod | wc -l                                         # 99
  

  Casi nada está cargado.

• Los microkernels no son lo mismo. Solo 10 segundos mirando la imagen principal de la página de Wikipedia que vinculaste destacaría que están diseñados de una manera completamente diferente.

  

  Los controladores de Linux están internalizados (principalmente como módulos cargados dinámicamente), no en el espacio de usuario, y los sistemas de archivos son igualmente internos. ¿Por qué es peor que usar controladores externos? ¿Por qué es micro mejor para la informática de propósito general?

Los comentarios nuevamente resaltan que no lo estás entendiendo. Si desea implementar Linux en hardware discreto (por ejemplo, aeroespacial, un TiVo, tableta, etc.) , configúrelo para construir solo los controladores que necesita . Puede hacer lo mismo en su escritorio con make localmodconfig. Terminas con una pequeña construcción de Kernel con cero flexibilidad.

Para distribuciones como Ubuntu, se acepta un solo paquete Kernel de 40 MB. No, elimine eso, en realidad es preferible al archivado masivo y al escenario de descarga que mantendría más de 4000 módulos flotantes como paquetes. Utiliza menos espacio en disco para ellos, es más fácil de empaquetar en tiempo de compilación, es más fácil de almacenar y es mejor para sus usuarios (que tienen un sistema que simplemente funciona).

El futuro tampoco parece ser un problema. La velocidad de la CPU, la densidad / fijación de precios del disco y las mejoras en el ancho de banda parecen mucho más rápidas que el crecimiento del Kernel. Un paquete de Kernel de 200 MB en 10 años no sería el final si el mundo fuera.

Tampoco es una calle de sentido único. El código se expulsa si no se mantiene.

svg de gráfico de burbuja tinyconfig (violín)

script de shell para crear el json desde la compilación del núcleo, úselo con http://bl.ocks.org/mbostock/4063269

Editar : resultó unifdeftener alguna limitación ( -Ise ignora y -includeno es compatible, este último se usa para incluir el encabezado de configuración generado) en este punto, el uso catno cambia mucho:

274692 total # (was 274686)

guión y procedimiento actualizado.

Además de los controladores, el arco, etc., hay una gran cantidad de código condicional compilado o no, dependiendo de la configuración elegida, código no necesariamente en módulos dinámicos cargados sino integrados en el núcleo.

Entonces, descargué las fuentes de linux-4.1.6 , elegí el tinyconfig , no habilita los módulos y honestamente no sé qué habilita o qué puede hacer un usuario con él en tiempo de ejecución, de todos modos, configure el kernel:

# tinyconfig      - Configure the tiniest possible kernel
make tinyconfig

construido el núcleo

time make V=1 # (should be fast)
#1049168 ./vmlinux (I'm using x86-32 on other arch the size may be different)

el proceso de compilación del kernel deja los archivos ocultos llamados *.cmdcon la línea de comando utilizada también para compilar .oarchivos, procesar esos archivos y extraer el objetivo y las dependencias que se copian a script.shcontinuación y usarlo con find :

find -name "*.cmd" -exec sh script.sh "{}" \;

Esto crea una copia para cada dependencia del objetivo .ollamado.o.c

código .c

find -name "*.o.c" | grep -v "/scripts/" | xargs wc -l | sort -n
...
   8285 ./kernel/sched/fair.o.c
   8381 ./kernel/sched/core.o.c
   9083 ./kernel/events/core.o.c
 274692 total

.h encabezados (desinfectados)

make headers_install INSTALL_HDR_PATH=/tmp/test-hdr
find /tmp/test-hdr/ -name "*.h" | xargs wc -l
...
  1401 /tmp/test-hdr/include/linux/ethtool.h
  2195 /tmp/test-hdr/include/linux/videodev2.h
  4588 /tmp/test-hdr/include/linux/nl80211.h
112445 total

Las compensaciones de los granos monolíticos se debatieron entre Tananbaum y Torvalds en público desde el principio. Si no necesita cruzar al espacio de usuario para todo, entonces la interfaz al núcleo puede ser más simple. Si el núcleo es monolítico, entonces puede ser más optimizado (¡y más desordenado!) Internamente.

Hemos tenido módulos como compromiso durante bastante tiempo. Y continúa con cosas como DPDK (mover más funciones de red fuera del núcleo). Cuantos más núcleos se agregan, más importante es evitar el bloqueo; así que más cosas se moverán al espacio de usuario y el núcleo se reducirá.

Tenga en cuenta que los núcleos monolíticos no son la única solución. En algunas arquitecturas, el límite del núcleo / espacio de usuario no es más costoso que cualquier otra llamada de función, lo que hace que los microkernels sean atractivos.