Las llamadas al sistema, que son el principal interfaz que el núcleo muestra a los procesos, generalmente permanecen igual de versión a versión. Se puede añadir una nueva llamada al sistema, pero normalmente las antiguas se comportarán igual que de costumbre. Esto es necesario para la compatibilidad regresiva; una versión nueva del núcleo se supone que no romperá con los procesos regulares. En la mayoría de los casos, los ficheros de dispositivo también permanecerán igual. En cambio, las interfaces internas dentro del núcleo pueden y de hecho sufren cambios entre las versiones.
Las versiones del núcleo Linux están divididas entre las versiones estables
(n.
número par
.m) y las versiones en desarrollo (n.número impar.m).
Las versiones en desarrollo incluyen todas las ideas nuevas, incluyendo aquellas
que serán consideradas un error, o reimplementadas, en la siguiente versión. Como
resultado, no puedes confiar en que la interfaz permanecerá igual en estas
versiones (es por lo que no las tratamos en este libro, es mucho trabajo
y caducarán rápidamente). En las versiones estables, por otro lado, podemos
esperar que el interfaz permanezca sin cambios sin importar la versión
de corrección de fallos (el número m).
Esta versión de la GPMNL incluye soporte para la versión 2.0.x y la versión
2.2.x del núcleo Linux. Como hay diferencias entre las dos, esto requiere
compilación condicional dependiendo de la versión del núcleo. La forma con
la que hacemos esto es usando la macro LINUX_VERSION_CODE. En la versión
a.b.c. del núcleo, el valor de esta macro debería ser
.
Para obtener el valor específico de una versión específica del núcleo, podemos
usar la macro KERNEL_VERSION. Como no está definida en 2.0.35, la
definiremos nosotros mismos si es necesario.