El kernel "anteriormente conocido como Linux 3.20" acaba de debutar.
Como ya sabréis a estas alturas, Linus Torvalds hizo una encuesta a ver
que opinaba la gente de saltar a la rama 4.X y llamarlo 4.0, o seguir en
la rama 3.X y llamarlo 3.20. Al final hizo lo que le salió de las
narices, que casualmente coincidió con la opción que iba ganando, y aquí
tenemos el flamante kernel 4.0, listo para descargar de
kernel.org.
Uno podría pensar que un cambio de número de versión mayor
significaría importantes novedades, o tal vez alguna rotura de la
compatibilidad hacia atrás. Ni lo uno, ni lo otro. Como dice el propio
Linus Torvalds en su mensaje de anuncio:
It definitely matches the "v4.0 is supposed to be a stable
release", and very much not about new experimental features etc. I'm
personally so much happier with time-based releases than the bad old
days when we had feature-based releases.
Tal vez algún día acabe este sinsentido actual de que los números de
versión importan un pito, pero hoy no es ese día.
¿Novedades de este kernel? Como decíamos, pocas. Se ha intentado
justificar el cambio de versión como que el kernel por fin iba a poder
parchearse en caliente con el mecanismo de kGraft/kpatch. Pero lo que se
ha integrado es sólo un principio que en próximas
versiones tendrá que completarse hasta que pueda considerarse terminado,
por lo que es algo que difícilmente podría justificar el cambio a 4.0.
En LWN.net destacan como novedades de esta versión el borrado de la
llamada al sistema remap_file_pages()
, mejoras en el soporte de
sistemas de ficheros en memoria persistente, la nueva
opción lazytime de mount
y el Kernel Address
Sanitizer (KASan). Los artículos sobre la merge window
(1, 2, 3) tienen más información y
KernelNewbies tendrá una lista más exhaustiva en el
futuro (cuando esté terminada).
Tiempos de compilación
Hay importantes novedades en este apartado. Pero primero, por
completitud, voy a poner los tiempos de los kernels de la rama 3.18.x
desde el último reporte:
Compilando 3.18.7-amd64 desde 3.18.6-amd64 con -j4:
$ time fakeroot make-kpkg -j4 --initrd --revision=3.18.7+1 --append-to-version=-amd64 kernel_image kernel_headers
real 10m18.580s
user 24m51.120s
sys 1m38.232s
Compilando 3.18.8-amd64 desde 3.18.7-amd64 con -j4:
$ time fakeroot make-kpkg -j4 --initrd --revision=3.18.8+1 --append-to-version=-amd64 kernel_image kernel_headers
real 10m17.546s
user 24m45.700s
sys 1m33.312s
Compilando 3.18.9-amd64 desde 3.18.8-amd64 con -j4:
$ time fakeroot make-kpkg -j4 --initrd --revision=3.18.9+1 --append-to-version=-amd64 kernel_image kernel_headers
real 9m58.847s
user 24m32.116s
sys 1m34.192s
En el kernel 3.18.8 quité todo el soporte de I2O (que desaparecía
completamente en la rama 3.19.x, no sé porqué los de Debian todavía lo
estaban compilando si no se usaba desde hace muchísimos años) más
algunos drivers serie que también sobraban. Eso significó una mínima
ganancia. Pero lo importante estaba por venir.
Primero, me entero que construir los kernels de Debian con el paquete
kernel-package está obsoleto y ya no se recomienda
su uso. Resulta que ahora se construyen directamente con el objetivo
deb-pkg que viene en los propios makefiles del kernel estándar. No sólo
eso, es que encima make deb-pkg
es más rápido que make-kpkg
construyendo los paquetes .deb
, a pesar de que hace un par de paquetes
adicionales (linux-firmware-image-VERSION
y linux-libc-dev
). He
compilado todos los kernels a partir del 3.19.1 así, y la verdad que la
diferencia en tiempo se nota.
Segundo, he quitado la opción CONFIG_DEBUG_INFO
, con lo que
definitivamente no compilo con opciones de debug (anteriormente había
reducido el tamaño de la información de debug pero no
la había eliminado). Con ello no sólo ha disminuido el tamaño del
directorio del kernel compilado de 2,2 GB a 1,2 GB, sino que también se
ha reducido el tiempo compilación, gracias a no tener que compilar y
generar la información de debug. La importante ganancia de velocidad la
podéis notar abajo entre el primer kernel 3.19.1 (con información de
debug aún) y el segundo 3.19.1 (sin información de debug). A partir de
ese, todos los los kernels compilados no llevan info de debug.
Tercero, he quitado de la configuración del kernel las opciones de los
módulos de seguridad (Linux Security Modules) SELinux, AppArmor y
TOMOYO. Debian los compila por defecto en su versión del kernel, pero
resulta que en realidad no se usan (hay que activarlos aparte e instalar
paquetes adicionales si se desean usar). Así que ¡fuera! (al menos de
momento). Este cambio es a partir de la compilación del kernel 3.19.2.
En conjunto los tres cambios han reducido un 30% el tiempo de
compilación y generación de los paquetes, bajándolo de los 7
minutos:
Compilando 3.19.1-amd64 desde 3.18.9-amd64 con -j4:
$ time make -j4 deb-pkg LOCALVERSION=-amd64 KDEB_PKGVERSION=1
real 8m55.484s
user 24m57.876s
sys 1m15.820s
Compilando 3.19.1-amd64 desde 3.19.1-amd64 con -j4: (quitando CONFIG_DEBUG_INFO)
$ time make -j4 deb-pkg LOCALVERSION=-amd64 KDEB_PKGVERSION=3.19.1-1
real 7m26.924s
user 21m11.156s
sys 1m5.256s
Compilando 3.19.2-amd64 desde 3.19.1-amd64 con -j4: (quitando SELinux, AppArmor y TOMOYO)
$ time make -j4 deb-pkg LOCALVERSION=-amd64 KDEB_PKGVERSION=3.19.2-1
real 6m52.244s
user 21m5.788s
sys 1m5.428s
Compilando 3.19.3-amd64 desde 3.19.2-amd64 con -j4:
$ time make -j4 deb-pkg LOCALVERSION=-amd64 KDEB_PKGVERSION=3.19.3-1
real 6m53.320s
user 20m56.484s
sys 1m3.664s
Compilando 3.19.4-amd64 desde 3.19.3-amd64 con -j4:
$ time make -j4 deb-pkg LOCALVERSION=-amd64 KDEB_PKGVERSION=3.19.4-1
real 6m49.564s
user 20m57.152s
sys 1m4.132s
Aunque seguro que se puede bajar más, de momento me doy por satisfecho.
Así que, a partir de ahora, se acabó esta sección (¡ohhhh...!). Salvo
que haya cambios significativos en los tiempos de compilación que
merezca la pena reseñar, no volveré a daros la tabarra con esto. Gracias
por vuestra paciencia. :-)
¿Qué pasó con...?
En la entrada sobre la anterior versión 3.19 comentaba un
par de bugs "nuevos" con el kernel, uno respecto a un dispositivo PCI
(SMBus) para el que no se cargaba el driver por culpa de un problema de
la BIOS (ACPI), y el otro unas bonitas excepciones del módulo DRM
del driver propietario de NVIDIA.
El bug del módulo de NVIDIA se corrigió en cuanto salió una nueva
versión más reciente del driver (la 346.47), no hizo falta ni siquiera
esperar al nuevo kernel 3.19.
En cambio, respecto al bug de la ACPI la nueva versión no ha resuelto
nada. Tampoco ha funcionado (la verdad es que era un tiro a ciegas)
engañar a la BIOS cambiándole la versión de ACPI soportada a 2,
inspirado en este comentario de Matthew Garrett. Tiene
toda la pinta de ser uno más de los innumerables bugs que pueblan las
BIOS, y salvo que al fabricante le dé por arreglarlo (dudoso), no hay
mucho más que hacer.
:wq