Soy un novato, ¿qué es un kernel?
Estrictamente hablando, el kernel no es una parte necesaria del sistema informático. Los programas se pueden llamar directamente a la computadora para su ejecución. Este diseño muestra que el diseñador no desea proporcionar ninguna abstracción de hardware o soporte de sistema operativo, esto es común en el diseño de los primeros sistemas informáticos. Con el tiempo, los programas auxiliares, como cargadores y depuradores de programas, se diseñaron en el núcleo de la máquina o se solidificaron en una memoria de sólo lectura. Cuando se producen estos cambios, el concepto de núcleo del sistema operativo queda claro.
Una pregunta más importante es quién debería conocer el núcleo. En otras palabras, ¿qué impacto tiene la comprensión del núcleo en su trabajo? Después de todo, el núcleo es complejo.
[editar] Clasificación del kernel
Núcleo único Proporciona una gran cantidad de operaciones completas de abstracción de hardware para hardware potencial.
Microkernel Sólo proporciona una pequeña parte de la abstracción del hardware, y la mayoría de las funciones las realiza un programa especial en modo de usuario (es decir, el servidor).
Kernel híbrido Es muy similar a la estructura del microkernel, excepto que la mayoría de sus componentes se ejecutan en estado central para acelerar la ejecución.
Kernel externo Este kernel no proporciona ninguna abstracción de hardware, pero permite agregar bibliotecas de tiempo de ejecución adicionales al kernel a través de las cuales las aplicaciones pueden operar el hardware directamente, o casi directamente.
Núcleo único
La arquitectura de núcleo único define una interfaz abstracta de alto nivel sobre el hardware y aplica un conjunto de primitivas (o llamadas al sistema) para implementar funciones del sistema operativo. como gestión de procesos, sistema de archivos y gestión de almacenamiento, etc. Estas funciones se completan mediante varios módulos que se ejecutan en el estado del kernel.
Aunque cada módulo proporciona servicios para estas operaciones de forma independiente, el código del núcleo está muy integrado y es difícil de escribir correctamente. Dado que todos los módulos se ejecutan en el mismo espacio del kernel, un pequeño error puede provocar que todo el sistema falle. Sin embargo, si el desarrollo va bien, las arquitecturas de un solo núcleo pueden beneficiarse de la eficiencia operativa.
Muchos kernels modernos con arquitectura de un solo núcleo (como los kernels de Linux y FreeBSD) tienen la función de llamar a la ejecución del módulo en tiempo de ejecución, lo que facilitará la extensión de las funciones del kernel y también hará que el núcleo del kernel se convierta en más conciso.
Ejemplos de arquitectura de un solo núcleo:
1. Kernel UNIX tradicional, como la versión lanzada por la Universidad de Berkeley
2 Kernel de Linux
.Microkernel
La arquitectura del microkernel consta de una capa de abstracción de hardware muy simple y un conjunto más crítico de primitivas o llamadas al sistema que contienen solo unos pocos componentes necesarios para construir el sistema, como la gestión de subprocesos, la dirección comunicación espacial y entre procesos.
El objetivo de un microkernel es separar la implementación de los servicios del sistema de las reglas operativas básicas del sistema. Por ejemplo, los servicios de bloqueo de entrada/salida de un proceso pueden ser proporcionados por un componente de servicio que se ejecuta fuera del microkernel. Estos servidores en modo de usuario muy modulares se utilizan para completar operaciones más avanzadas en el sistema operativo. Este diseño simplifica el diseño de la parte central del kernel. La falla de un componente de servicio no causa que todo el sistema falle; todo lo que el kernel necesita hacer es reiniciar el componente sin afectar a otros componentes.
El microkernel coloca muchos servicios del sistema operativo en procesos independientes, como el archivo. sistema, controladores de dispositivos, estos procesos llaman a los servicios del sistema operativo mediante el paso de mensajes.
La estructura del microkernel debe ser de subprocesos múltiples. La primera generación de microkernel proporciona más servicios en el kernel, por lo que se llama "microkernel gordo". Su representante típico es MACH, que es el sistema operativo GNU HURD y APPLE SERVER. Se puede decir que está prosperando. La segunda generación es un microkernel, que solo proporciona los servicios de sistema operativo más básicos. El sistema operativo típico es QNX, que es muy famoso en los círculos teóricos y se considera un sistema operativo avanzado.
Ejemplos de microkernels:
1.AIX
2.BeOS
Serie de microkernels 3.L4
4.MACH, utilizado en GNU HURD, también es el núcleo del sistema operativo APPLE SERVER. Se puede decir que está en auge. Mach, utilizado en GNU Hurd y Mac OS X
5.Minix
6.MorphOS
7.QNX
8.
9.VSTa
Un solo núcleo versus microkernel
La arquitectura de un solo núcleo es un diseño muy atractivo porque todas las operaciones subyacentes se implementan en la misma dirección espacio. La complejidad del código de control del sistema que implementa todas las operaciones de bajo nivel en el mismo espacio de direcciones es mayor en comparación con diferentes espacios de direcciones.
A principios de los años 90, las arquitecturas de un solo núcleo se consideraban obsoletas. Diseñar Linux como una arquitectura de un solo núcleo en lugar de un microkernel ha causado numerosas controversias.
Hoy en día, las arquitecturas de un solo núcleo tienden a ser más fáciles de diseñar correctamente, por lo que se desarrollarán más rápido que las arquitecturas de microkernel. Hay historias de éxito en ambos campos. Los micronúcleos se utilizan a menudo en diseños integrados para robótica y dispositivos médicos porque las partes críticas del sistema residen en un almacenamiento protegido separado. Esto no es posible en un diseño de un solo núcleo, incluso si emplea la carga de módulos en tiempo de ejecución.
Aunque se sabe que Mach es un micronúcleo versátil, se han desarrollado varios otros micronúcleos además de él. Su sucesor, L4, puede incluso ejecutar el kernel de Linux como uno de sus procesos en un espacio de direcciones separado.
QNX es un sistema microkernel diseñado desde los años 80. Está más cerca del concepto de microkernel que Mach. Se utiliza en áreas especiales donde no se permiten fallas del sistema debido a errores de software. Los ejemplos incluyen robots en el transbordador espacial y máquinas que pulen lentes de telescopios, donde el más mínimo error puede costar miles de dólares.
Mucha gente cree que la tecnología de microkernel es inútil porque Mach no puede resolver algunos de los problemas para los que se propuso la teoría de microkernel. Los entusiastas de Mach han demostrado que esta visión es extremadamente estrecha y, desgraciadamente, todo el mundo parece empezar a aceptarla.
Kernel híbrido
El kernel híbrido es esencialmente un microkernel, excepto que permite que parte del código de la estructura del microkernel se ejecute en el espacio del usuario para ejecutarse en el espacio del kernel, mejorando así el funcionamiento del kernel. eficiencia. Se trata de un compromiso y los diseñadores se basaron en la teoría de que los sistemas con arquitectura de micronúcleo no funcionan bien. Sin embargo, experimentos posteriores demostraron que los sistemas de micronúcleos puros eran realmente eficientes. La mayoría de los sistemas operativos modernos siguen esta categoría de diseño, siendo Microsoft Windows un buen ejemplo. Además, el kernel XNU de Mac OS X de Apple también es un kernel híbrido.
Ejemplos de kernels híbridos:
kernel BeOS
DragonFly BSD
kernel ReactOS
Windows NT, Windows 2000, Windows XP, Windows Server 2003 y Windows Vista, así como otros sistemas operativos basados en tecnología NT
No hay diferencia en el sistema del kernel. Esto es incorrecto.
Un sistema de kernel híbrido significa que extrae ciertos patrones de diseño de sistemas de un solo núcleo y de microkernel, por ejemplo, parte del código no crítico se ejecuta en el espacio del usuario y otro código se ejecuta en el espacio del kernel, simplemente por razones de eficiencia.
Núcleo extra
Los sistemas extra-núcleo, también conocidos como sistemas operativos de estructura vertical, son un enfoque de diseño más extremo.
El concepto de diseño es dejar que el diseñador del programa de usuario decida el diseño de la interfaz del hardware. El núcleo externo en sí es muy pequeño y normalmente sólo es responsable de los servicios relacionados con la protección del sistema y la reutilización de recursos del sistema.
El diseño tradicional del kernel (incluidos los de un solo núcleo y los micronúcleos) abstrae el hardware y oculta los recursos de hardware o los controladores de dispositivos bajo la capa de abstracción de hardware. Por ejemplo, en estos sistemas, si se asigna un bloque de espacio de almacenamiento físico, la aplicación no conoce su ubicación real.
Por otro lado, el objetivo del núcleo externo es permitir que las aplicaciones soliciten directamente un espacio físico específico, bloques de disco específicos, etc. El propio sistema sólo garantiza que el recurso solicitado está actualmente libre y permite que la aplicación acceda al recurso directamente. Dado que el sistema central externo solo proporciona operaciones de hardware de nivel relativamente bajo y no proporciona abstracción de hardware de alto nivel como otros sistemas, es necesario agregar bibliotecas de tiempo de ejecución adicionales para admitirlo. Estas bibliotecas de tiempo de ejecución se ejecutan sobre el kernel y brindan una funcionalidad completa a los programas de usuario.
En teoría, este diseño permitiría que una variedad de sistemas operativos, como Windows y Unix, se ejecuten sobre el kernel y permitiría a los diseñadores ajustar la funcionalidad de varias partes del sistema según el sistema operativo. eficiencia.
Actualmente, el diseño del núcleo externo aún se encuentra en etapa de investigación y ningún sistema comercial ha adoptado este diseño. Se están desarrollando varios sistemas operativos conceptuales, como el sistema Nemesis de la Universidad de Cambridge, el sistema Citrix de la Universidad de Glasgow y un sistema de la Academia Suiza de Ciencias de la Computación. Este tipo de investigaciones también se están llevando a cabo en el MIT.
[editar] Kernelless
Tanto el proyecto TUNES como UnununiumOS han hecho intentos sin kernel. Los sistemas sin kernel no se limitan a un único punto de entrada centralizado.
[Editar este párrafo] Referencia
Sistema operativo
[Editar este párrafo] Mejoras en el desarrollo del kernel
Red Flag 5 es un Kernel 2.6, en anticipación de
Turno: El tan esperado kernel 2.6 finalmente está aquí, y Paul Larson de IBMLinuxTechnologyCenter está echando un vistazo secreto a las herramientas, pruebas y técnicas que hacen de 2.6 el mejor kernel de todos los tiempos. desde el control de revisiones hasta las pruebas de regresión, el seguimiento de defectos y el guardado de listas.
El nuevo kernel de Linux 2.6 fue lanzado recientemente después de tres años de desarrollo activo, tiempo durante el cual ha habido algunos cambios interesantes en la forma en que se desarrolla y prueba el kernel de Linux. El enfoque actual para desarrollar núcleos no es, en muchos aspectos, tan diferente al de hace tres años. Sin embargo, algunos cambios clave han resultado en estabilidad general y mejoras de calidad.
Gestión del código fuente
Históricamente, el kernel de Linux nunca ha tenido una gestión formal del código fuente o un sistema de control de revisiones. De hecho, muchos desarrolladores han implementado sus propios controladores de corrección, pero no existe un archivo LinuxCVS oficial para que LinusTorvalds revise el código y lo ponga a disposición de otros. La falta de correcciones a menudo crea una "brecha generacional" entre las versiones, sin que nadie sepa realmente qué cambios se agregaron, si se integran bien o qué hay de nuevo en las próximas versiones. A menudo, algunos de estos problemas podrían evitarse si más desarrolladores fueran tan conscientes de los cambios como lo son de los suyos propios.
Debido a la falta de controladores de revisión oficiales y herramientas de administración de código fuente, muchas personas han sugerido usar un producto llamado BitKeeper, un sistema de administración de control de código fuente en el que muchos desarrolladores de kernel han trabajado para su propio desarrollo de kernel. El sistema se ha utilizado con éxito.
Poco después de que se lanzara el kernel 2.5 inicial, Linus Torvalds comenzó a experimentar con BitKeeper para ver si se adaptaba a sus necesidades. El código fuente principal del kernel de Linux 2.4 y 2.5 ahora se administra mediante BitKeeper. Esto puede parecer irrelevante para la mayoría de los usuarios a quienes les importa poco o nada el desarrollo del kernel. Sin embargo, en algunos casos, los usuarios pueden beneficiarse de los cambios en los métodos de desarrollo del kernel de Linux provocados por el uso de BitKeeper.
Uno de los mayores beneficios de usar BitKeeper es la convergencia de parches. Pueden surgir problemas de convergencia si se aplican varios parches al mismo código subyacente y algunos de ellos afectan a las mismas partes. Un buen sistema de gestión de código fuente puede automatizar algunas de estas tareas más complejas, permitiendo que los parches se fusionen más rápido y se agreguen más parches al kernel. A medida que crece la comunidad de desarrolladores del kernel de Linux, existe una gran necesidad de controladores de revisión para ayudar a rastrear todos los cambios. Dado que todos pueden incorporar estos cambios en el kernel principal de Linux, herramientas como BitKeeper son fundamentales para garantizar que los parches no se olviden y se incorporen y administren fácilmente.
Necesitamos desesperadamente un archivo centralizado en tiempo real de las últimas actualizaciones del kernel de Linux. Cada cambio o parche aceptado por el kernel se rastrea como un conjunto de cambios. Los usuarios finales y los desarrolladores pueden guardar sus propios archivos de origen y actualizarlos con los últimos conjuntos de cambios cuando sea necesario mediante comandos simples. Para los desarrolladores, esto significa tener siempre disponible la copia más actualizada del código. Los evaluadores pueden utilizar estos conjuntos de cambios lógicos para determinar qué cambios causan problemas, reduciendo así el tiempo necesario para la depuración. Incluso aquellos que deseen utilizar el kernel más reciente pueden aprovechar directamente el archivo centralizado en vivo, ya que pueden actualizar tan pronto como se agreguen al kernel los componentes o las correcciones de errores que necesitan. A medida que el código se fusiona con el kernel, cualquier usuario puede proporcionar inmediatamente comentarios e informes de errores sobre el código.
Desarrollo paralelo
A medida que el kernel de Linux crecía, aumentaba en complejidad y atraía a más desarrolladores para especializarse en aspectos específicos del kernel, sucedió otra cosa interesante con los cambios en el enfoque de desarrollo de Linux. Durante el desarrollo de la versión 2.3 del kernel, hubo muchos árboles del kernel además del árbol del kernel principal lanzado por Linus Torvalds.
Durante el desarrollo de la versión 2.5, la cantidad de árboles de kernel proliferó. Esto hace posible el desarrollo parcialmente paralelo porque el uso de herramientas de gestión de código fuente permite que el trabajo de desarrollo avance en paralelo. Para permitir que otros prueben los cambios antes de aceptarlos, es necesario realizar algún trabajo de desarrollo en paralelo. Los mantenedores del kernel mantienen sus propios árboles del kernel y trabajan en componentes y objetivos específicos, como administración de memoria, partes NUMA, escalabilidad mejorada y código específico de la arquitectura.
Figura 1. Árbol de desarrollo de Linux 2.5
La ventaja de este modelo de desarrollo paralelo es que permite a los desarrolladores que necesitan realizar cambios importantes, o a aquellos que realizan una gran cantidad de cambios similares. Para un objetivo específico, los desarrolladores tienen la libertad de desarrollar en un entorno controlado sin afectar la estabilidad del kernel utilizado por otros. Cuando los desarrolladores hayan completado su trabajo, podrán lanzar parches para la versión actual del kernel de Linux para implementar las modificaciones que realizaron hasta ese momento. De esta manera, los evaluadores de la comunidad pueden probar fácilmente los cambios y proporcionar comentarios. Una vez que se demuestra que cada parte es estable, las partes se pueden fusionar en el kernel principal de Linux individualmente o incluso todas a la vez.
Pruebas en el mundo real
En el pasado, los métodos de prueba del kernel de Linux giraban en torno al modelo de desarrollo de código abierto. Debido a que el código está abierto a la revisión de otros desarrolladores tan pronto como se publica, nunca existe un ciclo de verificación formal similar a otras formas de desarrollo de software.
La teoría detrás de este enfoque es lo que se llama "Ley de Linus" en La Catedral y el Bazar (ver Referencias), que establece que "el ojo del espectador es el ojo del espectador". En otras palabras, un alto nivel de escrutinio puede descubrir la mayoría de los problemas realmente grandes.
Sin embargo, en realidad, los núcleos tienen muchas interconexiones complejas. Incluso con un escrutinio suficiente, se pasarán por alto muchos defectos graves. Además, una vez que se lanza el último kernel, los usuarios finales pueden (y a menudo lo hacen) descargarlo y utilizarlo. Cuando se lanzó 2.4.0, muchos en la comunidad sugirieron pruebas más organizadas para garantizar la solidez de pruebas específicas y revisiones de código. Las pruebas organizadas incluyen el uso de planes de prueba, la repetibilidad del proceso de prueba, etc. El uso de estos tres métodos dará como resultado una mayor calidad del código que el uso inicial de solo dos métodos.
Proyecto de prueba de Linux
El Proyecto de prueba de Linux (LTP) es el primer contribuyente al lanzamiento de pruebas organizadas de Linux. El propósito de este proyecto es mejorar la calidad de Linux a través de un enfoque de prueba más organizado. El principal conjunto de pruebas desarrollado por LTP también se conoce como Proyecto de prueba de Linux. Cuando se lanzó el kernel 2.4.0, el conjunto de pruebas LTP sólo tenía unas 100 pruebas. A medida que las versiones Linux 2.4 y 2.5 continúan evolucionando y madurando, también lo hace el conjunto de pruebas LTP. Actualmente, el programa de pruebas de Linux incluye más de 2000 pruebas, ¡y ese número está creciendo!
Análisis de cobertura de código
Las nuevas herramientas actualmente en uso proporcionan análisis de cobertura de código del kernel. El análisis de cobertura nos dice qué líneas de código en el kernel se ejecutan cuando se ejecuta una prueba determinada. Más importante aún, el análisis de cobertura también puede señalar qué partes del núcleo no se prueban en absoluto. Estos datos son importantes porque indican qué nuevas pruebas deben escribirse para probar estas partes del kernel, lo que permite probar el kernel más exhaustivamente.
Pruebas continuas de regresión del kernel de varios días
Otro proyecto utilizado por los evaluadores de Linux durante el ciclo de desarrollo 2.5 fue la prueba de regresión continua de varios días del kernel de Linux utilizando el conjunto de pruebas LTP. Usamos BitKeeper para crear un archivo centralizado en vivo para proporcionar una instantánea del kernel de Linux en cualquier momento. Sin BitKeeper y las instantáneas, los evaluadores tendrían que esperar hasta que se lance el kernel antes de comenzar las pruebas. Los evaluadores ahora pueden probar el kernel tan pronto como cambie.
Otra ventaja de utilizar herramientas automatizadas para realizar pruebas de regresión de varios días es que esta vez se realizarán menos cambios en comparación con la última prueba. Si se descubre un nuevo defecto de regresión, normalmente es fácil detectar qué cambio puede haber sido causado por el defecto.
Además, dado que este es el cambio más reciente, todavía está fresco en la mente de los desarrolladores y, con suerte, esto les facilitará recordar y modificar su código en consecuencia. Quizás la ley de Linus debería concluir que algunos defectos son más fáciles de encontrar que otros porque estos son los que se pueden encontrar y resolver mediante pruebas de regresión del núcleo de varios días. Poder ejecutar estas pruebas todos los días durante el ciclo de desarrollo y antes del lanzamiento real permitiría a los evaluadores que solo se centran en el lanzamiento oficial centrarse en los defectos más graves y que consumen más tiempo.
ScalableTestPlatform
Otro grupo llamado OpenSource Development Labs (OSDL) también ha hecho contribuciones significativas a las pruebas de Linux. Poco después del lanzamiento del kernel 2.4, OSDL creó un programa llamado ScalableTestPlatform. Poco después del lanzamiento del kernel 2.4, OSDL creó un sistema llamado Scalable Test Platform (STP), una plataforma de pruebas automatizada que permitía a los desarrolladores y evaluadores ejecutar las pruebas proporcionadas por el sistema sobre el hardware OSDL.
Los desarrolladores pueden incluso utilizar el sistema para probar sus propios parches desarrollados contra el kernel. La plataforma de prueba extensible simplifica los pasos de prueba porque STP puede construir el kernel, configurar las pruebas, ejecutarlas y recopilar los resultados. Luego obtenga los resultados para una comparación en profundidad. Mucha gente no tiene acceso a sistemas grandes como una máquina SMP con ocho procesadores, y con STP cualquiera puede ejecutar pruebas en un sistema tan grande, lo cual es otra ventaja de este sistema (STP).
Seguimiento de defectos
Una de las mayores mejoras en las pruebas organizadas del kernel de Linux desde el lanzamiento de la versión 2.4 es el seguimiento de defectos. En el pasado, los errores descubiertos en el kernel de Linux se informaban a la lista de correo del kernel de Linux, a las listas de correo específicas del componente o del sistema, o directamente a la persona que mantenía la parte del código donde residía la falla. A medida que aumentó el número de personas que desarrollaban y probaban Linux, rápidamente se hicieron evidentes las fallas en el sistema. En el pasado, los errores a menudo se pasaban por alto, se olvidaban o se ignoraban a menos que los informes de errores se mantuvieran de manera sorprendente.
OSDL ahora instala un sistema de seguimiento de defectos (consulte Recursos para obtener un enlace) para informar y rastrear defectos en el kernel de Linux. El sistema está configurado de tal manera que cuando se informa un defecto en un componente, se notifica al responsable de ese componente. El mantenedor puede aceptar y arreglar el defecto, o reasignar el defecto (si se determina que en realidad es un defecto en otra parte del núcleo), o excluir el defecto (si se determina que no es un defecto real, como como una mala configuración del sistema). A medida que más y más correos electrónicos inundan las listas de correo, los defectos reportados en las listas de correo también corren el riesgo de perderse. Sin embargo, cada defecto y su estado actual siempre se registran en el sistema de seguimiento de defectos.
Una gran cantidad de información
Además de estos métodos automatizados de gestión de información, varios miembros de la comunidad de código abierto recopilan y rastrean una gran cantidad de información en el proceso de apertura de la versión 2.6. Kernel de Linux para el futuro.
Por ejemplo, se ha creado una lista de estado en el sitio web KernelNewbies para realizar un seguimiento de las nuevas partes propuestas del kernel. Las entradas de esta lista están ordenadas por estado, mostrando en qué núcleo se ha incluido si se ha completado, o cuánto tiempo ha tardado si aún no se ha completado. Muchas entradas de la lista apuntan a sitios web para proyectos grandes o, cuando las entradas son más pequeñas, los enlaces conducen a copias de correos electrónicos que explican los componentes correspondientes.
Historial de versiones del kernel
Muchos de nosotros ahora estamos familiarizados con el sistema de numeración de versiones del kernel de Linux, pero AndriesBrouwer nos recuerda que el sistema en realidad es irregular.
La primera versión pública de Linux fue la versión 0.02, lanzada en octubre de 1991. Dos meses después, en diciembre de 1991, Linus lanzó la versión 0.11, el primer núcleo independiente que se utilizó sin Minix.
En marzo, un mes después del lanzamiento de la versión 0.12, el número de versión saltó a 0.95, lo que refleja la maduración del sistema. No sólo eso, sino que la histórica versión 1.0.0 no se completó hasta dos años después, en marzo de 1994.
Por esta época, el desarrollo del kernel comenzó a utilizar numeración bidireccional. Las versiones pares del kernel (como 1.0, 2.2, 2.4 y ahora 2.6) son modelos de "producción" estables. Las versiones impares del kernel (1.1, 2.3) son kernels de vanguardia o "en desarrollo". Más recientemente, el desarrollo de nuevos núcleos comenzó meses después del lanzamiento del núcleo estable. Sin embargo, el trabajo de desarrollo de 2.5 comenzó varios meses después de que se completara 2.4.
Entonces, ¿cuándo veremos la versión 2.7? Es difícil decirlo, pero KernelTrap ha iniciado la discusión.
Hasta entonces, puedes leer el artículo de RagibHasan para conocer en profundidad la historia de Linux.
Mientras tanto, la "Documentación posterior a Halloween" les dirá a los usuarios qué esperar del próximo kernel 2.6 (consulte Recursos para obtener un enlace). Gran parte de la discusión en la "Documentación posterior a Halloween" trata sobre los principales cambios que los usuarios deben conocer y las herramientas del sistema que deben actualizarse (para aprovechar estos cambios). Los interesados en esta información son principalmente distribuidores de Linux que quieren saber de antemano qué viene con el kernel 2.6 y usuarios finales que quieren determinar si algún programa necesita ser actualizado para aprovechar los nuevos componentes.
El proyecto KernelJanitors mantuvo (y de hecho aún mantiene) una lista de errores menores y soluciones que debían corregirse. La mayoría de estas soluciones a fallas requieren cambiar muchas partes del código cuando se aplica un parche más grande al kernel, como algo que afecta un controlador de dispositivo. Los recién llegados al desarrollo del kernel pueden comenzar con algunas de las entradas de la lista, que les permiten aprender a escribir código del kernel a través de proyectos pequeños y al mismo tiempo tener la oportunidad de contribuir a la comunidad.
Además, en otro proyecto previo al lanzamiento, JohnCherry realizó un seguimiento de los errores y advertencias encontradas al compilar cada versión del kernel lanzada. Estas estadísticas recopiladas han ido disminuyendo constantemente con el tiempo, y publicar estos resultados en un formato sistemático permite ver de un vistazo el progreso que se está realizando. En muchos casos podemos aprovechar algunos de estos mensajes de advertencia y error así como la lista de KernelJanitors, ya que los errores de compilación suelen estar causados por pequeños defectos que requieren cierto esfuerzo para solucionarlos.
Finalmente, la lista de "Debe arreglarse" de Andrew Morton. Dado que fue elegido para ser mantenedor después del lanzamiento del kernel 2.6, usó su privilegio para resumir aquellos problemas que sentía que necesitaban abordarse con mayor urgencia antes de que se lanzara el kernel 2.6 final. La lista de tareas pendientes contiene defectos en el sistema kernel Bugzilla, piezas que deben completarse y otros problemas conocidos que impedirán el lanzamiento de la versión 2.6 si estos problemas no se resuelven. Esta información ayuda a ilustrar qué pasos se deben seguir antes de que se lance un nuevo kernel, y al mismo tiempo proporciona información valiosa para aquellos usuarios preocupados por cuándo se completará el tan esperado kernel 2.6.
Parte de este material aparentemente no ha sido mantenido desde que se lanzó el kernel 2.6 a finales del año pasado. El trabajo en otro material continúa después del lanzamiento principal y se seguirá actualizando en una fecha posterior. Será interesante ver qué se recupera, qué innovaciones se realizan y qué tan cerca estamos de un lanzamiento importante.
Conclusión
Al considerar lanzar una nueva versión estable del kernel, la primera pregunta que la mayoría de la gente hace suele ser: "¿Qué hay de nuevo en esta versión? La realidad es que, excepto, más allá de las nuevas funciones y correcciones , hay un proceso detrás del kernel que continúa mejorando con el tiempo.
El desarrollo de código abierto prospera en la comunidad de Linux entre los programadores que trabajan en el kernel de Linux y más allá y están muy poco conectados, lo que permite al equipo lograrlo con éxito. adaptarse a los cambios En muchos sentidos, el enfoque del desarrollo y las pruebas de Linux (especialmente uno que mejora con el tiempo) tiene un mayor impacto en la confiabilidad de un nuevo kernel que muchas mejoras individuales que son más profundas. >[editar] Núcleo en el sentido astronómico
En el sentido astronómico, un planeta (o estrella) tiene dos núcleos: el núcleo interno y el núcleo externo, el núcleo estelar La temperatura puede ser tan alta como. varios miles de grados centígrados.