Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
El Núcleo y las Versiones

Kernel
Por man ls
departamento contando por números , Sección Desarrolladores
Puesto a las Mon Dec 13th, 2004 at 03:22:35 PM CET
Por algún motivo, a la gente nos gusta restregar lo que sabemos a los demás; sobre todo esos pequeños detalles que los legos desconocen. Hasta hace poco, las versiones de Linux (del kernel o núcleo, me refiero) era una de ésas cosas: versiones pares estables, versiones impares desarrollo. Vale, listillos, La versión 2.6 salió hace ya casi un año, ¿dónde está la versión 2.7? ¿Se ha acabado el desarrollo?

 


historia

Por esta vez no voy a empezar con el rollo de "en 1992 un estudiante finlandés..." (el equipo-A me dejó más marcado de lo que yo pensaba); vosotros mismos.

Sin embargo, hay una cosa que me llama la atención acerca del famoso estudiante: su orientación científica (y de esta disquisición no os libráis). Por ejemplo, en el artículo de la wikipedia enlazado arriba Linus cita a Newton, y el aforismo de "Dado el suficiente número de ojos, todos los errores son poco profundos" suena a ley natural. Pero hay ejemplos más interesantes.

Si alguna vez habéis tenido que perfilar código Java en Linux sabréis que la famosa precisión de nanosegundos (milésimas de millonésima de segundo, o 10^-9 segundos) es completamente utilizable; cuando en otros sistemas operativos hasta los milisegundos son poco fiables. No hay en realidad ningún motivo para no disponer de esta información, ya que la inversa de un nanosegundo es, curiosamente, un GigaHerzio; por tanto, cualquier procesador que vaya a 1 GHz o más ya tiene la capacidad de contar nanosegundos, y sólo hay que preguntarle. Pero además resulta que la base primera de la ciencia es la medida; si tu instrumentación es pobre, tus conclusiones lo serán también. Y la tecnología no es otra cosa que las viejas artes de siempre a las que se les aplica un poco de ciencia.

ramas

Como parte de esta orientación científica veo yo la práctica de separar las ramas estable y de desarrollo, que no es muy común en la industria. Normalmente, las versiones van saliendo según están listas, y la rama de desarrollo es solamente la avanzadilla de la última versión.

Para los que no sois desarrolladores: una rama es un camino por el cual evoluciona el código de un programa, mientras que cada versión es una especie de instantánea del estado de un programa en un momento dado a lo largo de su rama. Puede haber varias ramas activas en un proyecto; por ejemplo, en Apache la rama 2.0 apareció hace tiempo ya y se ha adoptado en muchísimos entornos de producción; pero la rama 1.3 se sigue manteniendo ya que también sigue en uso activo.

En numerosos proyectos de software libre la versión en desarrollo se conoce como HEAD (testimonio de la terminología en cvs), o punto-equis. Como ejemplo, veamos cómo funciona en Audacity, ya que estoy suscrito a la lista de correo: el desarrollo que sigue a la versión 1.2 se llama 1.2.X, o sea que todo lo que hay en la 1.2.X acabará por aparecer en alguna versión de la rama 1.2: 1.2.1, 1.2.2... que son mejoras incrementales sobre el código de la 1.2. Poco después de que saliera la versión 1.2, se comenzó a trabajar en la rama 1.3: un sitio donde introducir las mejoras radicales y que pueden romper funcionalidades existentes. Mientras está abierta, los errores deben corregirse en ambas ramas, 1.2 y 1.3. Tan pronto como salga la versión 1.3.0, primera de la rama 1.3, probablemente alguien abra la rama 1.4; lo contrario querría decir que el programa ha alcanzado un estado satisfactorio para todo el mundo, y/o que ya hay poco interés por el desarrollo.

Por último, otro detalle que nos hace falta: las ramas (como 1.2) suelen tener número mayor (en este caso 1) y número menor (el 2 que va tras el punto). Las versiones pueden tener tres números (como 1.2.3); tienen número mayor y menor, y el tercer número no estoy seguro de cómo se llama; creo que puede ser número de revisión o de parches, dependiendo del desarrollador. Otra gente lleva la versionitis al máximo y le coloca hasta 5 números a las versiones, como Oracle 6.0.3.11.0; a veces se controlan las versiones de desarrollo por fecha (build date), como eclipse.org; y otras veces por número de build, como el infame "build 1381" de Windows NT 4.

pares o nones

Linux fue un poco especial para las versiones desde el principio; se declaró que las versiones con número menor par (como 2.2) serían estables, y aquéllas con número menor impar (como 2.3) pertenecerían a la rama de desarrollo. ¿Qué significa esto en la práctica? Pues que dentro de la rama de desarrollo habrá sucesivas versiones distintas, que irán incluyendo cada vez más funcionalidades, todas inestables. Sólo cuando la rama de desarrollo se estabilice lo suficiente, saldrá la versión estable (en nuestro ejemplo la 2.4.0); e inmediatamente se creará la nueva rama de desarrollo (2.5). La antigua rama inestable es subsumida completamente dentro de la nueva rama estable (2.3.99 -> 2.4.0 -> 2.4.1...). De hecho, como puede verse en su página de kernel.org, el kernel 2.3.51 pasó a convertirse en las distintas versiones 2.3.99-preX, hasta dar lugar por fin a la versión 2.4.0.

El tener que mantener una rama de desarrollo, con sus versiones y todo, es probablemente testimonio de lo crítico que es el código del núcleo: se supone que las mejoras que se introducen tardan un montón de tiempo en estabilizarse; cuando por fin están bien pulidas y se llevan bien con todas las nuevas modificaciones que se hayan introducido, pasan a la próxima versión estable. Como se ve en la rama 2.3, el proceso en ese tiempo tardó poco más de un año. Tiempo después, en noviembre de 2001, se creó la rama 2.5, que tardaría casi dos años en estabilizarse (hasta julio de 2003); más en realidad si tenemos en cuenta que la versión 2.6.0 no salió hasta diciembre de 2003. En este intervalo se pasó a la versión 2.6-test, puramente de estabilización.

¿Estamos ahora en un período de bonanza y mejoras graduales en 2.6.X, a lo que seguirá una nueva rama inestable 2.7; o ha cambiado algo fundamental?

revoluciones evolutivas

Tradicionalmente, se ve que Linus Torvalds era el encargado de guiar el desarrollo de la rama inestable; mientras que Marcelo Tosatti mantenía la rama estable. Ahora mismo ambos mantienen ramas estables, 2.4 y 2.6; sí hay un par de ramas colaterales mantenidas por Alan Cox y Andrew Morton, una especie de campo de pruebas para nuevos conceptos. Se conocen como "árboles" o trees: -ac el de Cox, -am el de Morton, y así. (Creo que hay una rama mantenida por Andrea Arcangeli, el árbol -aa, pero no lo siguen en la página de LWN.net.)

Se supone que, eventualmente, Linus creará una nueva rama inestable (la 2.7); probablemente cuando haya que meter cambios demasiado gordos para una rama estable. Sin embargo, el problema está en que dos años para estabilizar un nuevo desarrollo son demasiado. Además, Linus sigue introduciendo nuevos cambios en la rama 2.6 a buen ritmo, con alguna que otra pifia (como la version 2.6.8, que parece especialmente odiada). En principio, la gran ventaja es que los núcleos que se incluyen en las distribuciones no necesitan estar tan parcheados; en la práctica los distribuidores siguen metiendo cientos de parches a medida en sus núcleos.

Podría pensarse que esto siga así indefinidamente, con la rama estable 2.6 dando paso a una rama también estable 2.7; y la rama de Morton aceptando cambios importantes. Pero ya el mes pasado Andrew Morton avisó de que no: en cualquier momento llegará un cambio importante, que pueda potencialmente desestabilizar múltiples partes del núcleo e imposible por tanto de acomodar dentro de la rama 2.6; ni siquiera en el árbol -am.

ni del No-Do

Como curiosidad, la reacción de este imbécil, Paul Krill: llama bifurcación o fork a la creación de una rama inestable 2.7; y luego lo compara al fork que ocurrió entre versiones comerciales de Unix y llevó a su paulatino desmembramiento como mercado. Como respuesta se armó un cierto revuelo, difícil de creer si no se ve; hasta Morton respondió a las alegaciones diciendo que era parte del proceso normal de desarrollo del núcleo, y parece que los cuatro que habían picado se tranquilizaron.

que haya calma

Vamos, que todo esto es parte del desarrollo normal del kélmer de Sánex: hay que cambiarlo todo para que todo siga igual. A la mayoría de los usarios esto ni nos afecta; ya se encarga nuestra distribución de parchear el núcleo de kernel.org y presentárnoslo con un lacito. La mayoría de las veces no tendremos ni que preocuparnos de compilar algo en el kernel o dejarlo como módulo.

Esto es, en mi opinión, una buena cosa. A mí me sirve de poco el código hot-plug del núcleo 2.6; si no dispongo además del paquete discover de Debian que me auto-detecta los dispositivos nuevos al enchufarlos. En contra de lo que la mayoría de la gente se piensa, el núcleo de un sistema operativo no es tan importante; es más bien un área esotérica de infraestructura, y es muy curioso que en los sistemas GNU/Linux sea tan llamativo para los usuarios (entre los que por supuesto me incluyo).

En definitiva, que el desarrollo del kernel de Linux sigue como siempre, ahora en la rama estable y, probablemente, dentro de un tiempo en la inestable. La mayor ventaja de que disponemos con Linux (aunque no todo el mundo lo vea así) es que el desarrollo es flexible y se adapta a las necesidades de cada momento; no hay planificación a largo plazo que cumplir. ¡El paraíso tecnológico!

< II Jornadas sobre Software Libre y Desarrollo Humano (0 comments) | Impresiones sobre el instalador de Sarge (4 comments) >
Enlaces Relacionados
· escomposlinux.org
· versión 2.6 salió hace ya casi un año
· vosotros mismos
· Apache
· cvs
· Audacity
· Oracle 6.0.3.11.0
· eclipse.org
· en su página de kernel.org
· rama 2.5
· Marcelo Tosatti
· página de LWN.net
· la rama de Morton aceptando cambios importantes
· Andrew Morton avisó de que no
· este imbécil, Paul Krill
· Morton respondió a las alegaciones
· kernel.org
· no todo el mundo lo vea así
· More on Kernel
· Also by man ls

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
El Núcleo y las Versiones | 8 comentarios (8 temáticos, editoriales, 0 ocultos)
OT: ¿nanosegundos? (none / 0) (#1)
por jorginius ("jorginius" en Google Mail) a las Sun Dec 12th, 2004 at 08:17:48 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Si alguna vez habéis tenido que perfilar código Java en Linux sabréis que la famosa precisión de nanosegundos (milésimas de millonésima de segundo, o 10^-9 segundos) es completamente utilizable; cuando en otros sistemas operativos hasta los milisegundos son poco fiables.

¿A qué te refieres exactamente?. La precisión del tiempo está restrigida a la duración del jiffie, de uno a diez milisegundos en Linux, dependiendo de la versión del kernel y de la planificación.

Ya le puedes pedir al kernel que duerma al proceso un microsegundo o un nanosegundo (o 10 o 100... Tanto usleep como con nanosleep) que estará durmiendo al menos un milisegundo. Eso sin contar el tiempo del cambio de contexto.

Si te refieres a consultar el contador de tiempo real del PC (que genera pulsitos de frecuencia máxima de 8192 Hz, con lo que tienes una resolución del orden de microsegundos) o los registros de perfilado del Pentium (rdtsc, para llevar la cuenta de los ciclos de reloj, con lo que podrías tener resolución de nanos), es igual de fácil hacerlo en Linux que en cualquier otro SO, más aún cuando no hablamos de RTOS.

Si la medida del tiempo no funciona en alguna de las plataformas soportadas por Java será por un bug de Java. De la precisión se ocupa el hardware.

En Windows, los temporizadores tienen una resolución máxima de 10 ms. (o lo que marque GetSystemTimeAdjustment) por la misma razón que ya he comentado para Linux. Puedes recurrir al contador de tiempo real si precisas de más resolución con QueryPerformanceCounter. A través de /dev/rtc en Linux



[OT]Qué casualidad (none / 0) (#2)
por Draco a las Sun Dec 12th, 2004 at 09:08:41 PM CET
(Información Usuario)

Es curioso pero este tema últimamente nos llevó de cabeza en el trabajo. Como bien has dicho, la resolución máxima en Windows por defecto son 10ms. El caso es que en Java tú puedes designar intervalos menores para dormir un thread. Lo que hace la JVM en ese caso, es realizar la llamada timeBeginPeriod(1L) y así poner la resolución a 1ms. Al salir del sleep llama a timeEndPeriod(1L) restaurando el valor inicial (que es un valor de sistema).

El problema es que estas funciones(que internamente llaman a NtSetTimerResolution), no deben ser thread-safe o tienen algún problema dependiendo del hardware porque su uso en aplicaciones multihilo puede hacer que el reloj del sistema se desincronize completamente. Doy fe de que el efecto depende totalmente del puesto, ya que una aplicación que no había dado problemas de ese tipo en año y medio comenzó a darlos al instalarla en un puesto nuevo.

En cualquier caso, ésto es algo que no creo que se pueda hacer en Linux en ejecución (si no recuerdo mal el número de interrupciones de reloj por segundo se define en la macro HZ). En Solaris parece que sí puede hacerse.
There are two major products to come out of Berkeley: LSD & BSD Unix. I don't believe this to be a coincidence.
[ Padre ]


Nop, en Linux no (none / 0) (#3)
por jorginius ("jorginius" en Google Mail) a las Sun Dec 12th, 2004 at 10:20:28 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

En cualquier caso, ésto es algo que no creo que se pueda hacer en Linux en ejecución

El jiffie es fijo. Linux tampoco implementa la llamada POSIX sched_rr_set_interval, con lo que podrías ajustar el timer del sistema de los procesos planificados como SCHED_RR (Round Robin).

En el 2.4, llamando a nanosleep se simulaban esperas menores en procesos de tiempo real blando evitando la planificación y haciendo espera activa, pero en el 2.6 no nos mienten de esa manera y no puedes dormir menos que el tick del reloj del kernel.

Lo que sí puedes hacer en Linux en planificar un proceso como tiempo real, reprogramar el reloj vía ioctl y hacer read y select de /dev/rtc. Al menos no es espera activa.

El problema es que estas funciones(que internamente llaman a NtSetTimerResolution), no deben ser thread-safe o tienen algún problema dependiendo del hardware porque su uso en aplicaciones multihilo puede hacer que el reloj del sistema se desincronize completamente.

Deja vu del tiempo de DOS :-). Si andas reprogramando el canal 0 del (A)PIC, que es lo que parece que hace ese NtSetTimerResolution, la función para obtener la hora del día no funcionará durante el cambio. También puedes tener problemas con algún dispositivo, como (especialmente) la disquetera.

Si en DOS, que no era multiprogramado, aquello ya era un mundo: tenías que guardar el tiempo antes de reprogramar el PIC, ir actualizando para restaurarlo a la salida, re-reprogramar el PIC cada vez que usabas un dispositvo, etc. Lo raro es funcione alguna vez en Java :-)

De todas formas, aunque toques el reloj, no puedes tener intervalos de mayor frecuencia que 8.192 Hz (más cambio de contexto: registros y pila al menos) así que de nanos nada.

[ Padre ]


Corrección (none / 0) (#6)
por jorginius ("jorginius" en Google Mail) a las Mon Dec 13th, 2004 at 12:13:16 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Lo que sí puedes hacer en Linux en planificar un proceso como tiempo real, reprogramar el reloj vía ioctl y hacer read y select de /dev/rtc.

Esto sirve para leer tiempo con más resolución que con gettimeofday, no para dormir menos. Por mucho que el proceso sea de tiempo real en el momento que hay una petición de E/S sobre /dev/rtc se va a bloquear y, hasta que no pase el/los ms de rigor, nada.

Perdón :-).

[ Padre ]


 
Sí, nanosegundos (none / 0) (#4)
por man ls a las Sun Dec 12th, 2004 at 10:47:52 PM CET
(Información Usuario)

Yo usaba EJP, que utiliza el profiler JVMPI de la máquina virtual. Y es cierto que la precisión es de nanosegundos, lo pude comprobar midiendo el tiempo de varias llamadas.

Por otro lado, he leído (por ejemplo aquí) que Java te da la precisión del sistema operativo con que trabajes; en Windows NT parece que es 10 milisegundos. Si se programa uno mismo el contador parece que se pueden conseguir mejores resultados, pero aún en el rango de microsegundos. No hay color.

Supongo que si escribes el código para leer el registro adecuado de la CPU, podrás conseguir el resultado que tenga en ese momento. Pero yo no me refiero a eso, sino a preguntarle al sistema operativo "¿qué hora tienes?" y ver la precisión que te da.

[ Padre ]


Los misterios del reloj (none / 0) (#5)
por jorginius ("jorginius" en Google Mail) a las Mon Dec 13th, 2004 at 12:03:35 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Yo usaba EJP, que utiliza el profiler JVMPI de la máquina virtual.

Imagino que habrá una parte nativa y que EJP hará uso de los registros de profiling para dar resolución de nanos. ¿No?. ¿En un 486 también da nanos? :-P

JVMPI no es un profiler sino una interfaz para comunicarse con perfiladores que es prácticamente obsoleta, además.

Por otra parte, he visto un System.nanoTime en Java 1.5 que tiene toda la pinta de estar implementado sobre rdtsc en Pentium.

Supongo que si escribes el código para leer el registro adecuado de la CPU, podrás conseguir el resultado que tenga en ese momento. Pero yo no me refiero a eso, sino a preguntarle al sistema operativo "¿qué hora tienes?" y ver la precisión que te da.

A ver, todos los sistemas operativos de PC leen la hora del mismo sitio y, si programamos el reloj de tiempo real para que genere interrupciones cada 1ms, la precisión nunca puede ser mejor que un 1ms... Por mucho que las llamadas al sistema juren y perjuren que devuelven microsegundos o nanosegundos por seguir un estándar. Esto vale tanto para Linux como para Windows. Por debajo de eso hay que redondear.

A lo que voy es que, si con EJP obtienes resultados incoherentes en Windows, es o bien por un bug en el EJP/Java o bien por fallo de hardware porque para el conteo no estás usando las llamadas al sistema.

Podrías forzar más resolución en el sistema operativo:
  • El quantum en Windows 2000 es configurable en alguna parte. Me parece que sólo era corto/largo (workstation/servidor) además de fijo y varible, pero a lo mejor en una clave esotérica del registro puedes afinar más. O si no puedes echar mano de la llamada indocumentada que comentaba Draco.
  • En Linux puedes cambiar la duración del jiffie y recompilar.


... Pero en ambos casos vas a freir a la máquina a interrupciones.

Resumen: si los nanos son usables en Linux, entonces son usables en Windows, en la misma máquina y utilizando el mismo truco que estén usando en Linux (porque por los servicios del kernel no es). No hay más.

[ Padre ]


 
Más OT: completando (none / 0) (#7)
por jorginius ("jorginius" en Google Mail) a las Mon Dec 13th, 2004 at 10:52:56 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Se podría añadir que hay varios proyectos en Linux para mejorar la resolución temporal. Lo más común es usar el APIC (local) y rdtsc para obtener timers de resolución de microsegundos (lejos de los nanos). Aparte de los conocidos RTLinux y RTAI, también se pueden usar:

El discontinuado APIC timer Module, un parche poco intrusivo que da soporte a timers con bajas latencias en kernels 2.4. En su web hay una comparativa entre el reloj estándar, el reloj trabajando a su máxima frecuencia (8.192 Hz) y este parche. Interesantes las de la carga del sistema y de la varianza de las latencias, que ha mejorado mucho en los 2.6 con lo del kernel interrumpible (preemptive kernel) siempre que no se use ACPI o similar.

Otro es el parche Linux real time interrupts. Se integra muy bien con el sistema de interrupciones normales que use Linux: es elegante, en mi opinión. Igual que el anterior no funciona en SMP pero éste sí que puede mandar las interrupciones por el IO-APIC así que, en teoría, sería fácil de implementar.

En todo caso, a interrupciones más frecuentes hace falta más máquina para no perder alguna. No son parches de uso general.

[ Padre ]


 
primer post mmv (none / 0) (#8)
por truman a las Sat Jan 1st, 2005 at 12:02:26 AM CET
(Información Usuario)

primer post del MMV : ), segun hora española ----- Truman Burbank



 
El Núcleo y las Versiones | 8 comentarios (8 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda