XIP ( eng.execute -in-place -ejecución en el lugar ) es una tecnología que brinda la capacidad de ejecutar el código del programa directamente desde el dispositivo de almacenamiento persistente en el que se encuentra, sin cargarlo primero en la RAM . Es muy utilizado para la carga inicial de las computadoras, en sistemas embebidos por la necesidad de ahorrar recursos RAM, en algunos casos también se usa para sistemas grandes . Desde la década de 2010, para su uso en sistemas Linux de servidor con memoria no volátil direccionable por bytes , ha sido reemplazado por una tecnología más general: DAX .
Para que la tecnología funcione, su soporte debe implementarse en tres niveles: almacenamiento , en el sistema operativo , y los propios programas ejecutables .
Por primera vez, el soporte explícito para la tecnología en el lado del dispositivo de almacenamiento, así como su abreviatura y decodificación, se describen en la especificación PCMCIA de 1990 , y están más destinados al uso con dispositivos que no se pueden escribir [1] . Inicialmente, la tecnología se asoció solo con PCMCIA y su especificación especial, que definía las reglas para colocar un código binario y el orden en que se leía y ejecutaba [2] , pero como tal técnica se implementó para otras interfaces y unidades, se hizo más fuerte para todos los dispositivos de almacenamiento.
Para que el modo XIP funcione en la unidad en la que se encuentra el programa, se debe implementar una interfaz similar a la que usa el procesador central para acceder a la RAM. El soporte para esto se implementa en el nivel de middleware o por medio del sistema de archivos . Entre las herramientas intermedias que brindan trabajo en modo XIP se encuentra el subsistema MTD ( Memory Technology Device ) , respectivamente, los sistemas de archivos que trabajan en MTD más allá del nivel de bloque deben admitir las llamadas apropiadas para que XIP funcione. Al mismo tiempo, no todos los sistemas de archivos que funcionan a través de MTD admiten XIP, ya que muchos de ellos, originalmente enfocados en tecnología portátil, implementaron compresión , en este sentido, la implementación de XIP en ellos no es trivial, dichos sistemas de archivos incluyen JFFS2 , YAFFS2 , LogFS , UBIFS [ 3 ] . Sin embargo, hay sistemas de archivos de compresión habilitados para XIP que funcionan en MTD, como AXFS , que destaca la operación del modo XIP como una característica definitoria ( sistema de archivos XIP avanzado ) [3] . Los principales sistemas de archivos de compresión a nivel de bloque para almacenamiento persistente, cramfs y squashfs , no son compatibles con XIP, pero hay un parche para que cramfs admita XIP sin comprimir, y la mayoría de los teléfonos móviles basados en Linux utilizan esta variante de cramfs [3] .
Entre los sistemas de archivos de propósito general que se ejecutan en la parte superior del nivel de bloque, se proporciona soporte en Ext2 y Ext3 ; Ext4 comenzó a portar la compatibilidad con XIP, pero en 2014 fue reemplazada por métodos de acceso directo más generales: DAX [ [4] .
A pesar de que la tecnología se usó en sistemas integrados, firmware y varios sistemas operativos en tiempo real mucho antes de la década de 2000 [5] , en el lado de los sistemas operativos de uso general, el soporte se implementó por primera vez en la versión 2.6 del kernel de Linux . en 2005 [6] .
En 2006, la tecnología fue compatible con mainframes IBM zSeries , donde era necesario ejecutar muchas instancias diferentes de z/Linux desde un entorno z/VM con un kernel común y bibliotecas compartidas , pero con diferentes regiones de datos [7 ] . Si antes existiera una función similar para z/OS , entonces su implementación directa para Linux requeriría cambios significativos en el código del kernel del sistema operativo, por lo que el soporte de XIP se movió a la rama del kernel para la arquitectura s390 y una serie de funciones adicionales. fueron compatibles, incluido el soporte para el lado Ext2 [8] . Además, se cree que la necesidad de IBM de dar soporte a la tecnología mainframe ha sido la fuerza impulsora detrás de la implementación de XIP en Linux [9] .
En 2010, la tecnología fue soportada en NetBSD [5] , donde la implementación resultó ser relativamente simple debido a las características del subsistema de gestión de memoria virtual y el caché de búfer, además, es transparente para los sistemas de archivos (es decir, no no requiere apoyo especial por su parte).
Para que el programa funcione en modo XIP, se requiere en la etapa de compilación informar sobre la posibilidad de separar áreas para segmentos de datos y segmentos de código (ya que el segmento de datos debe crearse en RAM, y el segmento de código debe permanecer en el sistema de archivos). GCC usa la opción -msep-data para esto y , además, los programas XIP generalmente requieren la opción -mid-shared-library para generar código que permita llamar a las bibliotecas por identificador [10] . Establecer cualquiera de estas opciones hace que se establezca el indicador -fPIC , que significa compilación independiente de la posición .
El objetivo principal de la tecnología es guardar la memoria RAM del dispositivo. El efecto más significativo de ahorrar RAM se logra cuando es necesario ejecutar varias instancias del programa, en cuyo caso se usa el mismo espacio en el dispositivo de memoria de solo lectura para dar servicio a todos los lanzamientos, en lugar de asignar un área en RAM para cada uno. instancia. Otro efecto es reducir el consumo de energía del dispositivo al reducir el número de accesos a la memoria RAM volátil [11] .
Otro efecto de uso frecuente es un arranque rápido desde el almacenamiento persistente, en particular para un kernel de Linux monolítico lo suficientemente grande, que en las formas tradicionales debe copiarse inicialmente a la RAM, en XIP se puede ejecutar directamente desde la unidad.
Cuando se utilizan unidades flash , el mayor efecto de XIP se logra con dispositivos con direcciones de bytes como NOR flash [5] (mientras que NAND flash , como los discos duros , tienen direcciones de bloque , y acceder a una sola instrucción significa leer generalmente 4 KB, por lo menos ). menos 512 bytes). Esto también explica el uso de NOR flash para arrancar memorias de solo lectura y sistemas embebidos, a pesar de su mayor costo y menor densidad de grabación (en las condiciones de la década de 2010).
Otro efecto es la capacidad de utilizar dispositivos de almacenamiento persistente como memoria compartida para ejecutar programas sin utilizar los recursos de memoria principal del host y separar los segmentos de datos y programas, tal como se implementa en los mainframes .
En 2014, basado en el código XIP en el kernel de Linux (desde la versión 3.14), se implementó una tecnología más general: DAX ( acceso directo ), que combina ambas capacidades XIP y proporciona las llamadas necesarias para el acceso directo a los datos sin pasar por el caché de la página [9] . De los sistemas de archivos, la tecnología se implementó primero para Ext4 , luego apareció el soporte para XFS .
El motivo principal de tal generalización fue la aparición a mediados de la década de 2010 de dispositivos NVDIMM y 3D XPoint no volátiles y direccionables por bytes de gran capacidad para sistemas de servidor, en relación con los cuales la relevancia de ejecutar el código del programa sin transferir al principal memoria y acceso directo a datos sin copia intermedia a RAM. En los sistemas de archivos enfocados en dichos dispositivos, como NOVA , PMFS , SCMFS , Aerie [12] , la compatibilidad con DAX se implementa desde el principio y esta característica se considera una de sus características clave.