- El bus GPIB, creado por HP en 1972 y estandarizado como IEEE 488, fue clave para conectar instrumentación de laboratorio con ordenadores gracias a su diseño paralelo de 8 bits y capacidad multi-maestro.
- Durante años el soporte GPIB en Linux existió solo como código externo y proyectos comunitarios, hasta entrar en la rama staging del kernel como paso previo a su depuración y modernización.
- Con Linux 6.19 el driver de GPIB abandona la zona staging y se integra en el árbol principal, garantizando mantenimiento estable y compatibilidad a largo plazo para equipos de medida clásicos.
- Esta integración refuerza el papel de Linux como sistema capaz de convivir con hardware muy antiguo y tecnologías actuales, y facilita el control de instrumentación profesional en laboratorios y centros de investigación.
Hablar hoy de que el kernel Linux estrena unstrong>driver estable para el bus GPIB puede sonar casi a chiste interno entre frikis del hardware, pero es una noticia muy real y con bastante miga histórica detrás. Estamos ante la consolidación en el árbol principal del kernel de un subsistema que da soporte directo a un bus paralelo nacido nada menos que en 1972, es decir, un estándar de más de medio siglo que todavía sigue dando guerra en laboratorios y entornos de medida.
Este movimiento supone que, después de pasar por la famosa zona de pruebas del kernel conocida como staging, los controladores de GPIB (también llamado HP-IB o IEEE 488) se consideran lo bastante pulidos y mantenibles como para formar parte del núcleo “oficial” de Linux. Puede parecer algo anecdótico frente a USB, Ethernet o PCIe, pero para quienes siguen utilizando instrumentación de laboratorio clásica es una auténtica bendición… y un guiño precioso a la historia de la informática.
Qué es exactamente el bus GPIB y por qué importó tanto
El General Purpose Interface Bus, más conocido por sus siglas GPIB o por el nombre original de HP-IB, nació en Hewlett-Packard en 1972 con un objetivo muy concreto: conectar de forma fiable y flexible equipos de medida y prueba electrónica con ordenadores. En aquella época no existía una interfaz estándar realmente robusta para este tipo de aplicaciones, así que HP se inventó la suya.
Estamos hablando de los años en los que Intel acababa de presentar su primer microprocesador de 8 bits, el 8008, y el concepto de “PC” doméstico aún no había aterrizado. El mítico Altair 8800 llegaría unos años más tarde, y el IBM PC no aparecería hasta 1981. En ese contexto, GPIB aportó un bus paralelo de 8 bits, de corto alcance y multi-maestro, capaz de alcanzar tasas de transferencia de hasta 8 MB/s, una cifra muy respetable para la época.
El diseño del conector GPIB se hizo pensando en la robustez física: era un conector ancho, macizo, con un aspecto muy industrial y la peculiaridad de que los conectores podían apilarse entre sí. Esto facilitaba encadenar varios instrumentos sin necesidad de cajas intermedias ni inventos raros, algo muy apreciado en bancos de pruebas con multitud de dispositivos.
Con el tiempo, la interfaz se estandarizó bajo la denominación IEEE 488, y se convirtió en el método clásico para interconectar osciloscopios, multímetros de precisión, analizadores lógicos, plotters e incluso periféricos peculiares utilizados por máquinas como la Commodore 64 o algunos ordenadores Acorn. Hasta la llegada de interfaces más rápidas y versátiles, GPIB fue el rey de los laboratorios.
El estándar permitía conectar hasta 15 dispositivos a un único bus físico con una longitud total de cable de unos 20 metros (unos 66 pies). Para muchos entornos de medida era más que suficiente, y la posibilidad de controlar y automatizar la captura de datos desde un ordenador resultó revolucionaria. Años después, la aparición de SCSI, y posteriormente de USB, Ethernet o FireWire, fue relegando a GPIB a un segundo plano, hasta quedar en buena parte como un bus “vintage” pero muy querido.
Del olvido a la primera integración en el kernel Linux
Durante mucho tiempo, el soporte para GPIB en Linux vivió en una especie de limbo: existían drivers fuera del árbol oficial, mantenidos por entusiastas y comunidades muy concretas, que se encargaban de adaptar el código a las versiones del kernel disponibles. En los tiempos de auge de SourceForge era relativamente fácil encontrar proyectos pensados para los kernels 2.4.x, con parches y módulos que había que compilar y cargar a mano.
Este enfoque funcionaba, pero tenía varios inconvenientes: dependencia fuerte de voluntarios, riesgo de que el código quedara obsoleto con cada gran salto del kernel, y una experiencia de usuario poco amigable para quienes simplemente querían enchufar su instrumentación antigua a un PC con Linux actual y ponerse a trabajar. No era precisamente el tipo de soporte que se espera en entornos profesionales.
Con el paso del tiempo, algunos desarrolladores se animaron a intentar llevar este soporte GPIB al árbol principal del kernel. El primer gran hito se produjo cuando el código fue aceptado en la rama staging del kernel Linux. Esta zona es, básicamente, un área de pruebas donde puede residir código que todavía no está del todo maduro, pero que se considera lo bastante útil como para formar parte del proyecto y recibir revisiones y limpiezas.
La inclusión inicial en staging fue importante por dos razones: por un lado, ponía el foco de la comunidad de desarrolladores sobre el código GPIB; por otro, abría la puerta a que se modernizasen estilos, APIs internas y mecanismos de mantenimiento para ajustarse a los estándares de calidad que exige el kernel principal. A partir de ahí comenzó un periodo de pulido continuo a lo largo de distintas versiones.
En este tiempo, el objetivo era ir reduciendo advertencias, simplificando estructuras, eliminando trozos heredados de épocas muy antiguas y adaptando el driver a las prácticas actuales del desarrollo del kernel. Todo ello sin romper la compatibilidad con instrumentación que en muchos casos tiene décadas a sus espaldas, algo que tampoco es trivial, porque muchos laboratorios siguen operando con equipos que costaron una fortuna y que siguen funcionando de maravilla.
La graduación en Linux 6.19: de staging al árbol “real”
Tras aproximadamente un año de trabajo intenso en la zona staging, el código de GPIB alcanzó el punto en el que los responsables del subsistema lo consideraron suficientemente maduro y estable como para dar el salto definitivo. Esa graduación llega con la serie 6.19 del kernel Linux, donde los drivers de GPIB pasan al árbol principal, es decir, a la parte “oficial” y mantenida de forma estándar dentro del proyecto.
El anuncio de este cambio llegó integrado en una petición de integración (pull request) de la rama staging, dirigida a la ventana de fusión de Linux 6.19-rc1. En ese mensaje, Greg Kroah-Hartman —uno de los desarrolladores más reconocidos y responsable de buena parte del mantenimiento de drivers y del propio árbol staging— destacaba que lo más relevante de ese conjunto de cambios era que dos subsistemas, gpib y vc04, abandonaban por fin la zona de pruebas.
En palabras de Kroah-Hartman, lo realmente “gordo” de esas actualizaciones era precisamente ese doble movimiento desde staging hacia la parte estable del kernel. El resto de cambios en la rama staging, según explicaba, se limitaban a pequeñas limpiezas de estilo de código y ajustes menores, sin nada especialmente explosivo. Es decir, la noticia potente era que tanto GPIB como el subsistema VC04 (relacionado con Raspberry Pi) se habían ganado su plaza fija.
Además, el desarrollador recalcaba que todos estos cambios llevaban ya tiempo circulando en linux-next, la rama donde se van integrando las novedades antes de que entren en el kernel principal, y que durante ese periodo no se habían reportado problemas relevantes. Este es uno de los criterios clave para que una funcionalidad deje de considerarse experimental.
Con este movimiento, el driver de GPIB abandona su antigua vida como código externo, herdado de la época de los kernels 2.4.x y mantenido por pequeños grupos de aficionados, y pasa a formar parte de un subsistema integrado y con mantenimiento asegurado. Para los amantes del hardware antiguo, se trata literalmente de un día grande, porque se blinda el futuro de su equipamiento dentro del ecosistema Linux.
El papel de la zona staging y la filosofía de mantenimiento en Linux
Para entender por qué esta “graduación” es tan relevante, conviene repasar qué es y cómo funciona exactamente el staging tree del kernel Linux. A grandes rasgos, se trata de un área donde se puede alojar código que aún no cumple con todos los requisitos de calidad, estilo y mantenibilidad que se exigen al resto del árbol, pero que se considera interesante o prometedor.
La idea es que en staging haya espacio para experimentos, nuevos drivers y subsistemas que todavía tienen esquinas sin pulir. Allí pueden recibir revisiones, correcciones y refactorizaciones por parte de la comunidad sin que el código forme parte todavía de la interfaz “prometida” hacia los usuarios. Es una especie de zona de cuarentena donde se va decidiendo qué merece pasar al siguiente nivel y qué no.
Cuando un proyecto lleva tiempo en staging, se usa activamente sin problemas graves y se limpia hasta ajustarse a los estándares de desarrollo del kernel, se toma la decisión de moverlo al árbol principal. En ese momento, pasa a tener un mantenimiento más formal, se le asignan responsables claros y su API interna se estabiliza, de forma que los usuarios puedan confiar más en que no habrá cambios rupturistas sin justificación.
En el caso de GPIB, este proceso ha sido especialmente simbólico, porque hablamos de un estándar que en la práctica se considera obsoleto frente a buses modernos como USB, FireWire, Ethernet o PCIe. Sin embargo, la comunidad de usuarios que aún depende de él, sobre todo quienes manejan instrumentación de alto coste, ha demostrado ser lo bastante activa como para impulsar esa limpieza y garantizar su futuro.
La moraleja es clara: aunque un estándar esté superado técnicamente, mientras haya gente motivada y casos de uso reales, Linux sigue abriendo la puerta al soporte, siempre que alguien esté dispuesto a mantenerlo. Esa es una de las razones por las que el kernel puede convivir con tecnologías punteras y con interfaces que rozan ya la categoría de arqueología informática.
GPIB en contraste con USB, Ethernet y otros buses actuales
Visto desde 2025, puede resultar casi chocante hablar de un bus paralelo de los años 70 cuando el día a día de la mayoría de sistemas se apoya en USB, Ethernet, PCIe o incluso Thunderbolt. En entornos de trabajo modernos, tanto en oficina como en muchos laboratorios, la mayor parte de la instrumentación reciente se controla a través de interfaces de red, USB o incluso conexiones serie más tradicionales.
De hecho, muchos profesionales reconocen que para encontrar dispositivos que sigan utilizando GPIB o buses similares muy antiguos hay que rebuscar en los rincones más polvorientos del laboratorio o almacén. Lo habitual hoy es que los equipos “viejos” se conecten por RS-232 o RS-485, y los “muy viejos” o especialmente especializados recurran a GPIB e interfaces parecidas.
Este contraste también se ve en el tipo de hardware que se ha ido retirando. No es raro ver cómo se desechan discos duros de tipo “lavadora” (aquellas unidades enormes y pesadas de los mainframes antiguos) o sistemas de cinta magnética del tamaño de un armario, piezas que literalmente pertenecen a otra era. Frente a eso, contar hoy con soporte directo en Linux para hablar con un osciloscopio de los 80 mediante GPIB es casi un lujo nostálgico.
Aun así, hay que tener en cuenta que muchos de estos equipos antiguos siguen ofreciendo unas prestaciones y una calidad espectaculares. Un multímetro de precisión o un analizador de espectros clásico pueden seguir siendo perfectamente válidos para trabajos actuales, y sustituirlos por modelos nuevos puede suponer inversiones enormes. De ahí que mantenerlos integrados en flujos de trabajo modernos gracias a drivers actualizados tenga tanto sentido.
En cierto modo, la llegada del driver estable de GPIB a Linux 6.19 refuerza la idea de que el sistema es capaz de tender puentes entre generaciones de hardware: desde periféricos conectados por buses de los años 70 hasta dispositivos de altas prestaciones que hablan por Ethernet o PCIe en la misma máquina.
El otro protagonista del cambio: VC04 y VCHIQ en Raspberry Pi
En el mismo paquete de cambios donde se anunciaba la salida de GPIB de la rama staging, también se mencionaba otro subsistema que daba el salto definitivo: el relacionado con VC04 y la interfaz VCHIQ usada en las placas Raspberry Pi. Aunque el foco de este artículo es GPIB, este detalle ayuda a entender el contexto general del desarrollo del kernel.
La interfaz VCHIQ (VideoCore Host Interface Queue) actúa como un canal de comunicación hacia servicios de audio y gráficos acelerados suministrados por el firmware propietario de la Raspberry Pi. Durante mucho tiempo, el código que manejaba ese enlace se mantenía como algo relativamente independiente, con una fase en staging mientras se modernizaba y se limpiaba a nivel interno.
Con la integración definitiva de este código en el árbol principal, se facilita también la tarea de subir a mainline otros drivers de periféricos de Raspberry Pi en el futuro. En la práctica, esto significa mejor soporte a largo plazo para la plataforma, menos parches externos y una experiencia más coherente entre distintas versiones del kernel.
El paralelismo con GPIB es curioso: por un lado tenemos un bus de 1972 pensado para instrumentos de laboratorio, por otro una interfaz relativamente moderna y muy ligada a un ecosistema popular como Raspberry Pi. Sin embargo, ambos comparten el mismo camino dentro del kernel: tiempo en staging, limpieza, pruebas en linux-next y, finalmente, graduación al árbol estable.
Este doble movimiento demuestra cómo el proyecto Linux es capaz de avanzar simultáneamente en soporte para hardware muy antiguo y hardware relativamente reciente, siempre bajo la misma filosofía de calidad y mantenimiento continuo.
Impacto práctico para usuarios de instrumentación y hardware clásico
Más allá de lo llamativo de ver un bus de hace más de 50 años recibiendo cariño en pleno 2025, la pregunta clave es: ¿qué ganan realmente los usuarios con este nuevo driver Linux estable para GPIB? La respuesta tiene varias aristas interesantes, sobre todo para quienes trabajan con equipos de medida o automatización.
En primer lugar, al estar en el árbol principal del kernel, el soporte GPIB pasa a beneficiarse automáticamente de las actualizaciones regulares, correcciones de seguridad y revisiones que forman parte del ciclo de vida normal de Linux. Ya no depende de un tarball externo, de un proyecto olvidado en SourceForge o de un parche que alguien publicó en un foro hace años.
Esto implica que instalar una distribución moderna con un kernel 6.19 o superior debería bastar para tener soporte razonable para adaptadores y controladoras GPIB soportadas por el driver, sin tener que compilar módulos a mano. A partir de ahí, las capas de usuario (librerías, herramientas de automatización, software de medida, etc.) pueden apoyarse en una base mucho más estable.
En segundo lugar, tener el código integrado facilita que otros desarrolladores puedan añadir compatibilidad con más dispositivos, corregir errores específicos o adaptar el driver a nuevas necesidades sin tener que reinventar la rueda. La transparencia del desarrollo del kernel ayuda a que tanto empresas como particulares contribuyan con parches que beneficien al conjunto de usuarios.
Por último, este tipo de soporte oficial envía un mensaje claro a universidades, centros de investigación y laboratorios industriales: si su parque de instrumentación sigue dependiendo de equipos con interfaz GPIB, Linux se mantiene como una plataforma viable para controlarlos durante muchos años más. Es un argumento de peso para elegirlo como sistema de referencia en bancos de pruebas y sistemas de adquisición de datos.
Todo ello se traduce en algo muy concreto: quien tenga un osciloscopio, un multímetro de alta precisión o cualquier otro instrumento conectado por GPIB, verá ahora mucho más sencillo integrarlo en un flujo de trabajo moderno basado en Linux sin miedo a que un cambio de kernel le deje tirado.
Que el kernel Linux incorpore de forma estable un driver para un bus con más de medio siglo de historia no es solo una curiosidad técnica: también es la prueba de que la comunidad se toma muy en serio no dejar atrás hardware que todavía es útil, por veterano que sea, y de que en una misma máquina pueden convivir tecnologías puntas con auténticas piezas de museo, todas hablando el mismo idioma gracias al núcleo del sistema operativo.
