¿Cuáles son las cosas buenas y malas en el diseño del kernel de Linux?

Question

No soy un maestro del código del kernel, pero tengo una idea básica de su estructura de código. En este post podemos discutir cuáles son las cosas buenas y malas en el diseño del kernel.

Actualización: No, esto no es para la tarea. Lo habría mencionado si ese fuera el caso.

ver esto: https://stackoverflow.com/questions/1548442/i-know-how-to-program-now-how-do-i-learn-to-design

Todo el mundo elogia el diseño del núcleo de Linux. Tengamos una lista de las decisiones de diseño buenas y malas que se tomaron en el diseño del kernel.

Answer 1

existen algunos artículos denominados "patrones de diseño de Kernel de Linux". usted puede encontrar varios patrones de kernel de diseño para Linux. un artículo que continúa es "Linux Kernel Design Patterns - Part 1", comience con esto y busque en google artículo adicional para Kernel Design Pattern.

Answer 2

Creo que este http://linuxhelp.blogspot.com/2006/05/monolithic-kernel-vs-microkernel-which.html debería arrojar algo de luz sobre su pregunta.

Answer 3

Lo peor:

El sistema de construcción, (sí, ya sé que no es nada que ver con el diseño del propio núcleo).
Es una pesadilla absoluta, como ninguna otra en existencia, y si por alguna razón (agregando una nueva arquitectura, tal vez) necesita cambiarla, entonces tiene que aprender un idioma completamente nuevo para hacerlo.

Lo mejor:

Casi todo es configurable. Es sorprendente que básicamente el mismo kernel se usa en pequeños dispositivos integrados sin MMU, y en supercomputadores con grandes recuerdos y miles de procesadores.

Answer 4

No directamente sobre el diseño de Linux, pero creo que el proceso de desarrollo detrás de él es el más notable. El kernel mismo está en constante evolución, y lo hace a una velocidad increíble. Esto solo es posible gracias al control de versión descentralizado (git), que permite que un gran número de desarrolladores trabajen de forma simultánea.

Además, con git bisect lograron algo notable; ahora es posible para los no desarrolladores rastrear errores. Aquí es una cita de David Miller:

Lo que las personas no entienden es que esta es una situación en la aplica el "nodo final principio". Cuando tiene recursos limitados (aquí: desarrolladores) no carga la mayor parte de la carga sobre ellos. En su lugar, saca las cosas al del recurso que tiene muchos, los nodos finales (aquí: usuarios), de modo que la situación realmente se escala.

Personas Comunicación de errores tienen acceso al entorno en el que ocurre el fallo, y "git bisect" extraer automáticamente información relevante de este entorno . Esta es también una buena forma de obtener nuevos contribuyentes.

Además, siempre que los desarrolladores quieran contribuir con código, tienen que dividir su código en parches pequeños, que se pueden aplicar por separado, para que cada cambio se pueda revisar fácilmente. De esta manera, muchas personas pueden comprender una gran parte de su código.

El Linux Management Style es una lectura interesante. Linus trata de vivir una atmósfera en la que no te escondas detrás de la cortesía, pero claramente declaras lo que piensas. Esto podría ser grosero algunas veces, pero estoy seguro de que mantiene la calidad del código en un nivel alto.

Answer 5

cosas malas:

1. nueva tasa característica es alta y el ciclo de corrección de errores para esta cuenta es poco.
2. sistema de configuración debe ser inteligente. y categorizado para algunas necesidades generales. si tiene un sistema de configuración parecido a un asistente y más interacciones e información al hacer config.
3. bloqueo de kernel grande y otros bloqueos en cualquier lugar sin un buen mecanismo de comprobación.

cosas buenas: controladores de modo

1. usuario: modo de usuario del sistema de archivos, controlador de bloque en modo de usuario, controladores bloque de modo de usuario, escondidos en bruto, ...
2. buena inclusión conductor. en la actualidad, una gran gama de dispositivos tiene soporte en Linux Kernel.
3. virtualización de luz en kernel.
4. buenos mecanismos de comunicación entre espacio de usuario y kernel (dev, proc, sys, debugfs, ...)
5. muy buen uso del lenguaje C con punteros a las estructuras para simular algunas funciones orientadas a objetos.
6. modo de usuario linux para la depuración.
7. buen soporte de los sistemas embebidos
8. muy buenos mecanismos de seguridad: selinux, apparmor, verificación de la integridad, ...

Answer 6

creo que el desarrollo del núcleo, en lugar de ser un problema de diseño con antecedentes filosóficos y debates (tales como micro núcleo versus kernel monolítico), es un problema de código práctico que funciona de manera confiable. La variedad de periféricos y protocolos que debe soportar un kernel además de la amplia gama de versiones y fabricantes de hardware y también problemas complejos que surgen en el desarrollo de modo protegido (versus el desarrollo en modo usuario que utilizan las aplicaciones) justifican esta afirmación. Además, no se olvide de la cuestión de la compatibilidad con versiones anteriores que es vital para un sistema operativo en la práctica, pero que principalmente se descuida en la filosofía del diseño.

Linux kernel es un buen ejemplo de esto: un kernel monolítico (aunque muy modular) con muchos ataques pragmáticos que supera a muchos sistemas operativos académicos o comerciales bien diseñados en popularidad y rendimiento en servidores y áreas de sistemas integrados.

Una ventaja superior de Linux es que muchos aspectos de su kernel pueden estar incrustados en la imagen del kernel (principalmente bzImage) o pueden agregarse como un módulo kernel más adelante. Puede configurarlo antes de crear la imagen del kernel usando la herramienta de configuración y luego cualquier módulo del núcleo puede eliminarse o agregarse fácilmente en tiempo de ejecución (por privilegio de root, por supuesto) sin necesidad de reiniciar el sistema operativo. Esto hace que el desarrollo y mantenimiento del kernel sea realmente más fácil.(Solo piense en el sistema operativo Windows que necesita un reinicio para casi todas las actualizaciones, muchas veces en programas no relacionados con el kernel)