¿Qué beneficio podría ver compilando yo mismo un kernel de Linux? ¿Hay alguna eficiencia que pueda crear al personalizarla para su hardware?
¿Qué beneficio podría ver compilando yo mismo un kernel de Linux? ¿Hay alguna eficiencia que pueda crear al personalizarla para su hardware?
Respuestas:
En mi opinión, el único beneficio que realmente obtienes de compilar tu propio kernel de Linux es:
Aprende a compilar su propio kernel de Linux.
No es algo que deba hacer para obtener más velocidad / memoria / xxx. Es algo valioso si esa es la etapa en la que te sientes en tu desarrollo. Si desea tener una comprensión más profunda de lo que se trata todo este tema de "código abierto", sobre cómo y cuáles son las diferentes partes del núcleo, entonces debe intentarlo. Si solo está buscando acelerar su tiempo de arranque en 3 segundos, entonces ... cuál es el punto ... vaya a comprar un SSD. Si tiene curiosidad, si desea aprender, compilar su propio núcleo es una gran idea y probablemente obtendrá mucho de él.
Dicho esto, hay algunas razones específicas por las cuales sería apropiado compilar su propio núcleo (como varias personas han señalado en las otras respuestas). En general, estos surgen de una necesidad específica que tiene para un resultado específico, por ejemplo:
El problema radica en pensar que hay algún beneficio intrínseco para compilar su propio núcleo cuando todo ya funciona como debería, y no creo que lo haya. Aunque puede pasar innumerables horas deshabilitando cosas que no necesita y ajustando las cosas que son ajustables, el hecho es que el kernel de Linux ya está bastante bien ajustado (por su distribución) para la mayoría de las situaciones de usuario.
La mayoría de los usuarios no necesitan compilar su propio núcleo, su distribución ha hecho este trabajo por ellos. Por lo general, las distribuciones incluirán un conjunto de parches para integrarse con ciertas partes de la forma en que funciona la distribución, backports de controladores de dispositivos y correcciones de versiones más nuevas pero inéditas del núcleo o características que son pioneras con sus usuarios.
Cuando compila su propio núcleo, tiene un par de opciones, puede compilar un núcleo oficial de Linus Torvalds, esto no incluirá ninguno de los parches o personalizaciones que agregó su distribución (que puede ser bueno o malo) o puede use su herramienta de reconstrucción de distribución para construir su propio núcleo.
Las razones por las que puede querer reconstruir su núcleo incluyen:
Muchos desarrolladores lo usan para crear también versiones personalizadas del kernel para sistemas embebidos o decodificadores donde necesitan controladores de dispositivos especiales, o quieren eliminar funcionalidades que no necesitan.
bisect
para encontrar dónde se introdujo un error ...
Compilar el núcleo usted mismo le permite incluir solo las partes relevantes para su computadora, lo que lo hace más pequeño y potencialmente más rápido, especialmente en el momento del arranque. Los núcleos genéricos deben incluir soporte para la mayor cantidad de hardware posible; en el momento del arranque, detectan qué hardware está conectado a su computadora y carga los módulos apropiados, pero lleva tiempo hacer todo eso y necesitan cargar módulos dinámicos, en lugar de tener el código directamente en el núcleo. No hay ninguna razón para que su núcleo admita 400 CPU diferentes cuando solo hay una en su computadora, o para admitir ratones bluetooth si no tiene una, todo es espacio desperdiciado que puede liberar
No puedo creer que la respuesta aceptada aquí comience diciendo "No es algo que debas hacer para obtener más velocidad / memoria / xxx lo que sea".
Esto es totalmente falso. Rutinariamente construyo mis Kernels para eliminar el código innecesario, así como incluir el código de mejora del rendimiento relacionado principalmente con el hardware. Por ejemplo, ejecuto un hardware más antiguo y puedo obtener algunas mejoras de rendimiento al habilitar controladores de kernel rara vez habilitados, como la compatibilidad con el conjunto de chips HPT36x en algunos MoBos más antiguos que tienen esto incorporado.
Otro ejemplo, BIG SMP bajo Slackware es el predeterminado y en un Dell 2800, por ejemplo, consumirá una huella considerable para ejecutar cosas como GFSD (no como un módulo de kernel) que, por cierto, también consume tics de CPU para algo I no necesito Del mismo modo, para NFSD y otros aspectos generales para complacer a todas las mentalidades, lo cual está bien si solo está tratando de tener un Linux en una caja y funcionando, pero si le importa "velocidad / memoria / xxx lo que sea", entonces estas cosas importan y funcionan .
Todas mis cajas de producción son Kernels personalizados. Si utilizo hardware común, como un hardware de la serie Dell (2800, 2850, 2900, etc.), es simple copiar el archivo .config del kernel en cada caja y compilar el kernel e instalarlo.
Aquí hay algunas situaciones en las que compilar su propio núcleo lo beneficiará:
Un núcleo con la carga del módulo deshabilitada es más seguro. Esto requerirá que seleccione los módulos que sabe que necesita y los incluya como parte del núcleo, en lugar de compilarlos como módulos.
Deshabilitar el soporte para / dev / kmem, o paralizarlo con la opción de compilador adecuada es algo bueno para la seguridad. Creo que la mayoría de las distribuciones hacen esto por defecto ahora.
Prefiero no usar initrd cuando sea posible. La personalización de su kernel al hardware desde el que arranca elimina el initrd.
A veces, una versión posterior del kernel tendrá las características que necesita, pero esto es muy raro hoy en día. Recuerdo que cuando comencé a usar Debian, estaba usando kernel 2.4, pero necesitaba un kernel 2.6 para el soporte de udev.
Deshabilitar los protocolos / opciones de red que no necesita puede acelerar su rendimiento TCP / IP.
Deshabilitar las opciones que no necesita disminuye la huella de memoria del núcleo, lo cual es importante en entornos con poca RAM. Cuando utiliza un sistema de RAM de 256 MB como enrutador, esto ayuda.
Encuentro todos los dispositivos "tty" en / dev molestos en los sistemas en los que generalmente solo inicio sesión a través de serie o ssh.
Compilar su propio kernel le permite participar en el proceso de desarrollo del kernel, ya sea que se trate de cosas simples como el suministro de ID de dispositivo PCI / USB para un controlador existente que puede hacer que un dispositivo más nuevo funcione para usted, para involucrarse profundamente en la refriega del núcleo desarrollo de kernel.
También le permite probar los núcleos de desarrollo en su hardware y proporcionar comentarios si nota alguna regresión. Esto puede ser particularmente útil para usted y para otros si tiene una pieza de hardware poco común. Si espera un kernel de distribución, puede tomar algún tiempo para que las correcciones de sus informes de problemas se filtren en una nueva versión del kernel de distribución.
Personalmente, también me gusta compilar mis propios núcleos para incluir soporte solo para el hardware que tengo. Cuando ejecuta kernels de distribución y mira la salida de lsmod(8)
, ve muchos módulos cargados para hardware que no tiene. Esto puede contaminar la lista de módulos, / proc, / sys y sus registros, de modo que cuando esté buscando algo se pueda ocultar entre el ruido; Tampoco puede estar 100% seguro de que esos módulos no contribuyen a un problema que está tratando de diagnosticar.
Segundo la respuesta de gabe. (Mi comentario es demasiado largo, así que publico como respuesta).
A menos que tenga un propósito altamente especializado (por ejemplo, máquinas incrustadas, perfiles de seguridad estrictos), no veo ningún beneficio práctico para compilar su propio kernel que no sea ver cómo se hace. Al revisar metódicamente las opciones, ver cómo interactúan entre sí para construir el sistema es una excelente manera de comprender cómo funciona su sistema. Es sorprendente lo que descubres cuando intentas eliminar componentes que no parecen tener ningún propósito para las tareas que intentas realizar.
Sin embargo, ten en cuenta: por qué saltar por la madriguera del conejo es sin duda estimulante, ¡absorberá más noches y fines de semana de lo que creías posible!
En el trabajo, utilizamos núcleos enrollados a mano para aplicar parches fuera del árbol, como vserver y unionfs.
En casa, estoy compilando núcleos enrollados a mano para encontrar qué commit introdujo un error que estoy experimentando. Una vez que haya terminado eso, probablemente me quedaré con un kernel enrollado a mano hasta que el error se solucione en mi distribución (Debian), momento en el cual volvería a sus kernel nuevamente.
¡Este hilo es antiguo y todavía es válido hoy como lo fue cuando se hizo la pregunta!
La respuesta es: compila el kernel de Linux de su elección según sus necesidades y requisitos.
Muchos escenarios son válidos:
Usted es un ingeniero y requiere que su compilación cumpla con los requisitos / demandas de rendimiento y seguridad de su sistema; recompila para cumplir y / o superar los criterios especificados.
Usted es un usuario normal y tiene un sistema antiguo que desea mantener en funcionamiento todo el tiempo que pueda, recompila agregar / quitar componentes para mantener su sistema antiguo optimizado.
Eres un usuario normal con el último hardware más rápido y tiene memoria / RAM más que suficiente. No es necesario volver a compilar, pero aún puede hacerlo si está interesado en aprender un poco más sobre su sistema.
Solo desea ser como un usuario cotidiano de Microsoft y / o Mac, no vuelva a compilar y simplemente siga las actualizaciones de su distribución aguas arriba.
Sigue llegando los escenarios :-)
A diferencia de los usuarios de Mac / Windows, Linux ofrece opciones. La opción de tomarlo con calma u optimizar el sistema según sus requisitos.
Para la mayoría de los usos, los núcleos genéricos son buenos para prácticamente cualquier hardware. Además, generalmente contienen parches específicos de distribución (ed), por lo que compilar su propio núcleo puede (podría) causar problemas.
Los reson para compilar su propio núcleo son:
Si no estuviera usando la distribución basada en la fuente, no compilaría el núcleo en absoluto.
Otro caso, además de los muchos mencionados aquí para tener núcleos compilados personalizados, es configurar entornos de arranque de red especializados donde la carga de módulos no es factible y hay que pasar núcleos completamente funcionales a máquinas específicas para tareas específicas.
Me sorprende que nadie haya mencionado esta razón para compilar un kernel personalizado:
porque quieres usar un compilador C / c ++ diferente. GCC es bastante bueno para compilar el kernel de Linux. ¡Pero hay compiladores muy superiores por ahí! Las optimizaciones de GCC están un poco por detrás del compilador C / C ++ de Intel. Intel proporciona las bibliotecas de primitivas de rendimiento y la herramienta vtune, que son indispensables para producir un kernel de Linux de alto rendimiento. Solo puede llegar tan lejos con GCC y G ++. Prácticamente no importa lo que hagas, el resultado estará limitado por el compilador. Por lo tanto, utilizo el compilador Intel y las bibliotecas de rendimiento. Es un poco grande: descarga de 1.5GB, pero eso da una idea de lo que está contenido en un buen compilador.
El compilador C / C ++ de Intel está disponible de forma gratuita para uso no comercial. Pero es más fácil googlear la página de descarga del compilador Intel c ++ de licencia no comercial que buscar en el sitio web de Intel. No suelo usar GCC / G ++ para nada. Y no necesitas ser programador. Simplemente configura su entorno y cambia dos líneas en el archivo make para apuntar al compilador de Intel.
¡Entonces puedes obtener algo de velocidad seria!
What are the pros and cons of compiling your own kernel?
Cons = no es fácil, muchas situaciones no tienen valor agregado. Pros = seguridad, rendimiento, si sabe lo que está haciendo, dispositivos NAS, por ejemplo, que usan Linux para hacer que algún hardware funcione y tenga capacidad gráfica y de red.