Aunque la mayor parte del código en el kernel de Linux está escrito en C, todavía hay muchas partes de ese código que son muy específicas de la plataforma en la que se ejecuta y deben tenerse en cuenta.
Un ejemplo particular de esto es la memoria virtual, que funciona de manera similar en la mayoría de las arquitecturas (jerarquía de tablas de páginas) pero tiene detalles específicos para cada arquitectura (como la cantidad de niveles en cada arquitectura, y esto ha ido aumentando incluso en x86 con introducción de nuevos chips más grandes.) El código del kernel de Linux introduce macros para manejar el recorrido de estas jerarquías que el compilador puede eludir en arquitecturas que tienen menos niveles de tablas de páginas (de modo que el código está escrito en C, pero toma los detalles de la arquitectura en consideración.)
Muchas otras áreas son muy específicas para cada arquitectura y deben manejarse con un código específico del arco. Sin embargo, la mayoría de estos involucran código en lenguaje ensamblador. Algunos ejemplos son:
-
Cambio de contexto :El cambio de contexto implica guardar el valor de todos los registros del proceso que se está cambiando y restaurar los registros del conjunto guardado del proceso programado en la CPU. Incluso el número y conjunto de registros es muy específico para cada arquitectura. Este código generalmente se implementa en ensamblaje, para permitir el acceso completo a los registros y también para garantizar que se ejecute lo más rápido posible, ya que el rendimiento del cambio de contexto puede ser crítico para el sistema.
-
Llamadas al sistema :El mecanismo por el cual el código del espacio de usuario puede desencadenar una llamada al sistema suele ser específico de la arquitectura (y, a veces, incluso del modelo de CPU específico; por ejemplo, Intel y AMD introdujeron diferentes instrucciones para eso, las CPU más antiguas pueden carecer de esas instrucciones, por lo que los detalles para esos seguirá siendo único.)
-
Controladores de interrupciones :Los detalles sobre cómo manejar las interrupciones (interrupciones de hardware) suelen ser específicos de la plataforma y, por lo general, requieren un poco de pegamento a nivel de ensamblaje para manejar las convenciones de llamada específicas en uso para la plataforma. Además, las primitivas para habilitar/deshabilitar interrupciones suelen ser específicas de la plataforma y también requieren código ensamblador.
-
Inicialización :Los detalles de cómo debe ocurrir la inicialización también suelen incluir detalles que son específicos de la plataforma y, a menudo, requieren algún código ensamblador para manejar el punto de entrada al kernel. En las plataformas que tienen varias CPU (SMP), los detalles sobre cómo conectar otras CPU suelen ser también específicos de la plataforma.
-
Primitivas de bloqueo :La implementación de primitivos de bloqueo (como spinlocks) generalmente también involucra detalles específicos de la plataforma, ya que algunas arquitecturas proporcionan (o prefieren) diferentes instrucciones de CPU para implementarlas de manera eficiente. Algunos implementarán operaciones atómicas, algunos proporcionarán un cmpxchg que puede probar/actualizar atómicamente (pero fallará si otro escritor entró primero), otros incluirán un modificador de "bloqueo" para las instrucciones de la CPU. Esto a menudo implicará escribir código ensamblador también.
Probablemente hay otras áreas en las que se necesita código específico de plataforma o arquitectura en un kernel (o, específicamente, en el kernel de Linux). Mirando el árbol fuente del kernel, hay subárboles específicos de arquitectura bajo arch/ y bajo include/arch/ donde puedes encontrar más ejemplos de esto.
Algunas son realmente sorprendentes, por ejemplo, verá que la cantidad de llamadas al sistema disponibles en cada arquitectura es distinta y algunas llamadas al sistema existirán en algunas arquitecturas y no en otras. (Incluso en x86, la lista de llamadas al sistema difiere entre un kernel de 32 bits y uno de 64 bits).
En resumen, hay muchos casos que un kernel debe tener en cuenta que son específicos de una plataforma. El kernel de Linux intenta abstraer la mayoría de ellos, por lo que los algoritmos de nivel superior (como el funcionamiento de la gestión y la programación de la memoria) se pueden implementar en C y funcionan igual (o casi igual) en todas las arquitecturas.
Además de portar el kernel de Linux, deberá definir la interfaz binaria de la aplicación (ABI) para programas de "espacio de usuario" y portar las capas más bajas de la pila de software de espacio de usuario. Linux se usa típicamente con componentes de espacio de usuario de bajo nivel del proyecto GNU, de los cuales los más críticos son:
- El compilador, ensamblador y enlazador de C:GCC y GNU Binutils. Para una arquitectura de CPU completamente nueva, debe portar este software incluso antes de comenzar a portar el kernel, ya que el kernel en sí mismo es un programa C y debe compilarse. Si ya hay soporte de "back-end" para la CPU de su plataforma, pero no con Linux como el kernel del sistema operativo, tiene mucho menos trabajo por hacer y puede salirse con la suya posponiendo la mayor parte del trabajo hasta que el kernel esté listo y listo. corriendo.
- La biblioteca de tiempo de ejecución de C:"GNU libc". Esta biblioteca incluye el código que hace llama al sistema e interactúa directamente con el kernel.
- La biblioteca de "interfaz de funciones externas", libffi, que es un componente esencial de muchos intérpretes de idiomas de alto nivel y realiza una de las pocas tareas restantes que requiere una pequeña cantidad de lenguaje ensamblador escrito a mano.
Muchas otras piezas de software tienen componentes opcionales que dependen de la plataforma; por ejemplo, la navegación web será sustancialmente más rápida si escribe primitivas criptográficas optimizadas a mano para NSS y OpenSSL para su nueva arquitectura de CPU, y back-end de compilación justo a tiempo para IonMonkey y V8. Pero estos no son esenciales para crear una nueva plataforma.