Visión General del Kernel Linux de Fedora

Taisei Washington, Lucas Fehlau Arbulu Version F38 Last review: 2023-06-21

Calendario de Actualización

Versiones Estables

Las versiones estables reciben dos tipos de actualizaciones de kernel.

Actualizaciones de kernel estables

La comunidad de desarrollo del kernel admite la última versión principal con actualizaciones estables (versiones 5.y.z). Estas actualizaciones se liberan aproximadamente una vez a la semana, aunque puede ser más o menos frecuentemente. Una vez que la comunidad de desarrollo del kernel hace una versión estable, Fedora la compila y la envía como actualización a Bodhi. Estas actualizaciones se dejan normalmente en Bodhi varios días para pruebas antes de ser enviadas al repositorio de actualizaciones estables.

Actualizaciones mayores del kernel

El kernel Linux libera versiones mayores nuevas (lanzamientos 5.y) cada pocos meses. Cuando esto ocurre, Fedora actualiza la nueva versión mayor después de un par de lanzamientos estables del desarrollador. Cuando las actualizaciones se envían a Bodhi se permite más tiempo para pruebas para asegurar que no hay regresiones serias.

Desarrollo de Versiones

El desarrollo de las versiones de Fedora incluyen las versiones Rawhide y Branched.

Rawhide

El kernel Rawhide es la última instantánea git del árbol de desarrollo kernel.org de Linus. Frecuentemente (diariamente), se construye una nueva instantánea.

Branched

Las versiones Branched reciben actualizaciones en intervalos menos frecuentes que los Rawhide. Al principio de la versión Branched, normalmente se utiliza una versión preliminar del kernel, por lo que cada Release Candidate (RC) (Versión Candidata) está diseñada para versiones Branched. Una vez que se ha liberado el kernel, recibe actualizaciones estables del mismo modo que las versiones estables de Fedora.

Depurar Kernels

El kernel Linux kernel ofrece diversas opciones de configuración que hacen más fáciles los problemas de depuración. Sin embargo, algunas de estas opciones tienen un coste de rendimiento de modo que Fedora no siempre pone estas opciones en funcionamiento. Cuando se han apagado las opciones de depuración en el paquete kernel, se produce un paquete kernel-debug separado con estas opciones levantadas.

Kernels Estables y Branched

Los kernels Estable y Branched deshabilitan siempre las opciones de depuración.

Rawhide

Los kernels Rawhide habilitan las opciones de depuración. Sin embargo, cada kernel de versión candidata se compila con las opciones de depuración deshabilitadas. Los kernels de las versiones candidatas se pueden reconocer por su campo de versión. Como ejemplo, kernel-5.19.0-0.rc7.20220722git68e77ffbfd06.56.fc37 ee el kernel de la versión candidata para Fedora 37.

Políticas

Controladores Fuera del árbol

El método más simple, con diferencia, es fusionar el controlador en el kernel de Linus. Fedora cambia constantemente su base a versiones más recientes, por lo que hereda estos cambios "gratis" con poca sobrecarga para los mantenedores del kernel de Fedora.

Añadir controladores externos al kernel de Fedora que no son aceptados en sentido ascendente requiere un esfuerzo continuo por parte del equipo de kernel de Fedora, por lo que, siempre que sea posible, intentamos evitarlo. En las pocas situaciones donde tiene sentido hacerlo, hay varios criterios que se debe cumplir.

  • Debe haber una demanda razonable de la función para que asumamos la carga de transportar el código hasta que llegue al nivel superior.

  • Pasar comprobaciones sanitarias básicas (ha sido revisado por al menos un mantenedor del kernel de Fedora).

  • Tiene un desarrollador de nivel superior intentando fusionar su código en el árbol de Linus.

  • Tiene un desarrollador de Fedora responsable de mantenerlo actualizado en Fedora.

  • No causa ninguna sobrecarga discernible para los mantenedores del kernel de Fedora. El código que debe corregirse continuamente tiende a terminar siendo eliminado.

  • No añade nuevas llamadas al sistema o características similares de definición de ABI (Interfaz Binaria de Aplicación). Esto es para evitar una situación que pudiera terminar en incompatibilidades entre distribuciones/nivel superior.

  • Primero se debe aceptar en sentido ascendente como se exporta un símbolo. Esto incluye:

    • Añadir un EXPORT_SYMBOL para exportar algo que anteriormente no era exportado

    • Cambiar un EXPORT_SYMBOL_GPL a EXPORT_SYMBOL

    • Cambiar un EXPORT_SYMBOL a EXPORT_SYMBOL_GPL

  • En los raros casos en los que añadimos exportaciones que no están en el nivel superior, somos precavidos y usamos EXPORT_SYMBOL_GPL para exportarlos. Esto se hace en parte como disuasivo para que los módulos de terceros no los utilicen. (Ya que pueden desaparecer en el futuro). La única excepción a todo lo anterior es el nuevo código ascendente aún no fusionado que se está agregando. Los nuevos símbolos se pueden exportar como lo pretendía el autor.

Staging

The drivers in the staging directory of the Linux kernel are known to be in a rough and incomplete state. For the vast majority of these drivers, the kernel team considers it unsafe to build and ship them. We do not have the confidence in the existing code, nor do we have the time to debug issues in known problematic drivers.

As with every policy, there are exceptions. Fedora ships a few staging drivers at the moment for various pieces of hardware. For the Fedora kernel team to enable a staging driver, the following conditions must be satisfied:

  • There must be substantive code review and improvement upstream. This means actual fixes, and not just stylistic changes.

  • There must be a contributor willing to be assigned bug reports and deal with upstream.

  • The contributor must be actively involved improving the driver upstream.

  • The driver must not result in an undue burden on the kernel team. This means that if a large number of bug reports result from the driver, then fixes are not occurring upstream quickly enough.

  • It must be understood that if any of these conditions are not met, or eventually fail to be met, the driver will be disabled.

Builtin Features

From time to time, the Fedora kernel maintainers get asked to build something into the kernel. That is, the functionality is included in the vmlinux binary that every Fedora machine runs as opposed to being built as a module that is only loaded if needed. Given that it is loaded on every machine, we tend to build functionality as modules as much as possible. While one person might need the driver for an ATI card, another will not and having that built into the kernel is wasteful for really no reason.

There are no set criteria that map exactly to whether something is built-in or not, but they generally follow these guidelines:

  • The option cannot be built as a module and is widely used

  • The option is not a driver/filesystem and used by something that is a Fedora default

  • The option is a driver and used by a wide variety of machines (keyboard/mouse drivers, VT support)

  • The option is a filesystem and is used by all machines or is the default Fedora filesystem (tmpfs, ext4).

Again, the above are general guidelines but for the most part we try and limit the overall size of the vmlinux that is loaded to a core set of functionality.

If you find that the Fedora configuration options are not sufficient for your needs, you can rebuild the kernel and change options as you see fit. See the documentation on building a custom kernel.

Getting Involved

If you’re interested in contributing to the development and maintenance of the Fedora kernel, check out the kernel wiki for more information.

Mailing Lists

The Fedora kernel mailing list is for Fedora-related kernel topics only. This includes Fedora-specific packaging and kernel configuration settings. For discussions about Linux itself see the Kernelnewbies mailing lists or the Linux Kernel mailing lists.

You can subscribe to the Fedora kernel mailing list and view the archive on Hyperkitty.

IRC

Users interested in the Fedora kernel hang out in the #fedora-kernel channel on freenode.


See a typo, something missing or out of date, or anything else which can be improved? Edit this document at https://pagure.io/fedora-docs/quick-docs.