• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Karma Linux
 

Karma Linux

on

  • 461 views

Karma Linux is a Linux distribution for deterministic application performance evaluation. It has been successfully used in a Computer Engineering Processor Design and Configuration Assessment course ...

Karma Linux is a Linux distribution for deterministic application performance evaluation. It has been successfully used in a Computer Engineering Processor Design and Configuration Assessment course at the University of Cordoba.

The evaluation of performance is driven by GLPerfex, a graphical tool that provides access to a set of performance counters—using the PAPI library [1]—and allows the task to have exclusive use of the CPU—using RTAI [2]. As a result, the system provides a deterministic environment to perform a non intrusive evaluation of applications.

GLPerfex and LPerfex are free software under the GNU GPL v3 license.

[1] Performance Application Programming Interface (PAPI), http://icl.cs.utk.edu/papi/
[2] Real Time Application Interface (RTAI), https://www.rtai.org/less

Statistics

Views

Total Views
461
Views on SlideShare
457
Embed Views
4

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 4

http://www.linkedin.com 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Karma Linux Karma Linux Document Transcript

    • PROYECTO FIN DE CARRERA INGENIER´IA T´ECNICA EN INFORM´ATICA DE SISTEMAS Karma Linux 2008 Distribuci´on de Linux para la Evaluaci´on de Rendimiento en Sistemas Computacionales Modernos Autor Fernando Garc´ıa Aranda Directores Ezequiel Herruzo G´omez Jos´e Ignacio Benavides Ben´ıtez ESCUELA POLIT´ECNICA SUPERIOR UNIVERSIDAD DE C´ORDOBA Junio - 2008
    • D. Ezequiel Herruzo G´omez, Profesor Colaborador de Primer Nivel del ´Area de Arquitectura y Tecnolog´ıa de Computadores del Departamento de Arquitectura de Computadores, Electr´onica y Tecnolog´ıa Electr´onica de la Universidad de C´ordoba. D. Jos´e Ignacio Benavides Ben´ıtez, Catedr´atico de Escuelas Universitarias del ´Area de Arquitectura y Tecnolog´ıa de Computadores del Departamento de Arquitectura de Computadores, Electr´onica y Tecnolog´ıa Electr´onica de la Universidad de C´ordoba. Informan: Que el proyecto de fin de carrera de Ingenier´ıa T´ecnica en Inform´atica de Sistemas titulado ((Distribuci´on de Linux para la Evaluaci´on de Rendimiento en Sistemas Computacionales Modernos)) ha sido realizado bajo su direcci´on por Fernando Garc´ıa Aranda en la Escuela Polit´ecnica Superior de la Universidad de C´ordoba, reuniendo, a su juicio, las condiciones exigidas a este tipo de trabajos. Y para que conste, firman el presente informe en C´ordoba a 10 de julio de 2008. Los directores: D. Ezequiel Herruzo G´omez D. J. Ignacio Benavides Ben´ıtez
    • Copyright c 2008 Fernando Garc´ıa, Ezequiel Herruzo, J. Ignacio Benavides Se otorga permiso para copiar, distribuir y/o modificar este docu- mento bajo los t´erminos de la Licencia de Documentaci´on Libre de GNU, Versi´on 1.2 o cualquier otra versi´on posterior publicada por la Free Software Foundation; sin Secciones Invariantes ni Textos de Cubierta Delantera ni Textos de Cubierta Trasera. Una copia de la licencia est´a incluida en la secci´on titulada “GNU Free Documentation License” del Ap´endice de Licencias.
    • Karma Linux 2008 Distribuci´on de Linux para la Evaluaci´on de Rendimiento en Sistemas Computacionales Modernos Autor Fernando Garc´ıa Aranda Directores Ezequiel Herruzo G´omez Jos´e Ignacio Benavides Ben´ıtez
    • ´Indice general 1. Introducci´on 1 1.1. Eventos del Procesador . . . . . . . . . . . . . . . . . . . . . 2 1.1.1. Perfctr y Performance API . . . . . . . . . . . . . . . 3 1.1.2. Ruidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Sistemas Operativos en Tiempo Real . . . . . . . . . . . . . . 4 1.2.1. Planificaci´on de tareas . . . . . . . . . . . . . . . . . . 4 1.2.2. Manejo de Interrupciones . . . . . . . . . . . . . . . . 5 1.2.3. Comunicaci´on y Sincronizaci´on . . . . . . . . . . . . . 6 1.2.4. Gesti´on de la memoria . . . . . . . . . . . . . . . . . . 6 2. Definici´on del Problema 9 2.1. Identificaci´on del Problema Real . . . . . . . . . . . . . . . . 9 2.2. Identificaci´on del Problema T´ecnico . . . . . . . . . . . . . . 10 2.2.1. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . 10 2.2.2. Entorno . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.3. Vida Esperada . . . . . . . . . . . . . . . . . . . . . . 12 2.2.4. Ciclo de Mantenimiento . . . . . . . . . . . . . . . . . 12 2.2.5. Competencia . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.6. Aspecto Externo . . . . . . . . . . . . . . . . . . . . . 13 2.2.7. Estandarizaci´on . . . . . . . . . . . . . . . . . . . . . . 13 2.2.8. Calidad y Fiabilidad . . . . . . . . . . . . . . . . . . . 14 2.2.9. Programa de Tareas . . . . . . . . . . . . . . . . . . . 14 2.2.10. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2.11. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.1. Adaptaci´on de Karma a Procesadores Multin´ucleo . . 16 2.3.2. Mejora de la Usabilidad . . . . . . . . . . . . . . . . . 16 2.3.3. Autonom´ıa de la Plataforma . . . . . . . . . . . . . . 17 2.4. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.1. Antecedentes a Lperfex y Glperfex . . . . . . . . . . . 18 2.4.2. Antecedentes de Planificadores en Tiempo Real . . . . 19 2.4.3. Antecedentes de la Distribuci´on . . . . . . . . . . . . . 19 2.4.4. Antecedentes a Sistemas de Benchmarking . . . . . . . 19 iii
    • iv ´INDICE GENERAL 2.5. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.1. Factores Dato . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.2. Factores Estrat´egicos . . . . . . . . . . . . . . . . . . . 21 2.6. Recursos para el Desarrollo . . . . . . . . . . . . . . . . . . . 23 2.6.1. Recursos Humanos . . . . . . . . . . . . . . . . . . . . 23 2.6.2. Recursos Hardware . . . . . . . . . . . . . . . . . . . . 24 2.6.3. Recursos Software . . . . . . . . . . . . . . . . . . . . 24 2.7. Recursos para la Ejecuci´on . . . . . . . . . . . . . . . . . . . 25 2.7.1. Recursos Humanos . . . . . . . . . . . . . . . . . . . . 26 2.7.2. Recursos Hardware . . . . . . . . . . . . . . . . . . . . 26 2.7.3. Recursos Software . . . . . . . . . . . . . . . . . . . . 26 3. An´alisis del Sistema 27 3.1. Identificaci´on de Requisitos . . . . . . . . . . . . . . . . . . . 27 3.2. Modelado Est´atico . . . . . . . . . . . . . . . . . . . . . . . . 28 3.2.1. Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.2. An´alisis de Clases del Sistema . . . . . . . . . . . . . . 32 3.3. Modelado Din´amico . . . . . . . . . . . . . . . . . . . . . . . 34 3.3.1. Diagramas de Secuencia . . . . . . . . . . . . . . . . . 34 3.4. Descripci´on de la Informaci´on . . . . . . . . . . . . . . . . . . 38 3.4.1. El Formato CSV . . . . . . . . . . . . . . . . . . . . . 39 3.4.2. Nuestro Uso de CSV . . . . . . . . . . . . . . . . . . . 40 3.5. Requisitos de la Interfaz . . . . . . . . . . . . . . . . . . . . . 41 3.6. Descripci´on y Especificaciones del Resto del Sistema . . . . . 43 3.6.1. Planificaci´on de Procesos . . . . . . . . . . . . . . . . 43 3.6.2. Descripci´on de Componentes . . . . . . . . . . . . . . 45 3.6.3. Requisitos Funcionales . . . . . . . . . . . . . . . . . . 54 3.6.4. Requisitos No Funcionales . . . . . . . . . . . . . . . . 56 4. Dise˜no del Sistema 59 4.1. Dise˜no del Entorno de Ejecuci´on . . . . . . . . . . . . . . . . 59 4.1.1. Compilaci´on y Preparaci´on del Kernel . . . . . . . . . 60 4.1.2. Creaci´on del Entorno en Tiempo Real . . . . . . . . . 61 4.1.3. Creaci´on del Entorno de Medici´on de Eventos . . . . . 62 4.1.4. Integraci´on del Sistema de Medici´on en el kernel de Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.2. Dise˜no de la Aplicaci´on . . . . . . . . . . . . . . . . . . . . . 63 4.2.1. Clase MainFrame . . . . . . . . . . . . . . . . . . . . . 63 4.2.2. Clase Configuration . . . . . . . . . . . . . . . . . . . 64 4.2.3. Clase Counters . . . . . . . . . . . . . . . . . . . . . . 65 4.2.4. Clase CheckListCtrl . . . . . . . . . . . . . . . . . . . 66 4.2.5. Clase Results . . . . . . . . . . . . . . . . . . . . . . . 66 4.2.6. Clase ResultsPanel . . . . . . . . . . . . . . . . . . . . 67 4.2.7. Clase IOInterface . . . . . . . . . . . . . . . . . . . . . 68
    • ´INDICE GENERAL v 4.3. Dise˜no de la Interfaz . . . . . . . . . . . . . . . . . . . . . . . 69 4.3.1. Generar Medici´on . . . . . . . . . . . . . . . . . . . . 69 4.3.2. Cargar Resultado . . . . . . . . . . . . . . . . . . . . . 72 4.4. Dise˜no del Sistema Aut´onomo . . . . . . . . . . . . . . . . . . 73 4.4.1. Instalaci´on de Live Helper . . . . . . . . . . . . . . . . 74 4.4.2. Configuraci´on del Live CD B´asico . . . . . . . . . . . 74 4.4.3. A˜nadiendo Funcionalidades al Live CD B´asico . . . . 75 4.4.4. El entorno chroot . . . . . . . . . . . . . . . . . . . . . 77 4.4.5. Cerrando el Live CD . . . . . . . . . . . . . . . . . . . 78 5. Pruebas 79 5.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.2. Pruebas de Unidad . . . . . . . . . . . . . . . . . . . . . . . . 80 5.2.1. Pruebas de Casos de Uso . . . . . . . . . . . . . . . . 80 5.2.2. Pruebas de Escenarios de la Aplicaci´on . . . . . . . . 82 5.3. Pruebas de la Aplicaci´on . . . . . . . . . . . . . . . . . . . . . 84 5.3.1. Procedimiento Seguido . . . . . . . . . . . . . . . . . . 84 5.3.2. Ejecuci´on de los Casos de Prueba de la Aplicaci´on . . 85 5.4. Pruebas de Rendimiento de la Aplicaci´on . . . . . . . . . . . 87 5.4.1. Pruebas No Exclusivas Sin Ruido . . . . . . . . . . . . 88 5.4.2. Pruebas No Exclusivas Con Ruido . . . . . . . . . . . 89 5.4.3. Pruebas Bajo el Entorno Exclusivo . . . . . . . . . . . 89 6. Conclusiones y Futuras Mejoras 93 6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 6.1.1. Conclusiones personales . . . . . . . . . . . . . . . . . 94 6.2. Futuras mejoras . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Bibliograf´ıa 97 A. Manual de Usuario 101 A.1. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 A.1.1. Requisitos del Sistema Completo . . . . . . . . . . . . 102 A.1.2. Requisitos de Glperfex . . . . . . . . . . . . . . . . . . 102 A.2. Instalaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 A.2.1. Instalaci´on de Karma Linux 2008 . . . . . . . . . . . . 103 A.2.2. Instalaci´on de la Aplicaci´on . . . . . . . . . . . . . . . 105 A.3. Uso de la Aplicaci´on . . . . . . . . . . . . . . . . . . . . . . . 106 A.3.1. Abrir Glperfex . . . . . . . . . . . . . . . . . . . . . . 106 A.3.2. Generar Medici´on con Planificador Est´andar . . . . . 106 A.3.3. Generar Medici´on Exclusiva . . . . . . . . . . . . . . . 110 A.3.4. Guardar Resultados de una Medici´on . . . . . . . . . 111 A.3.5. Guardar Gr´afica de una Medici´on . . . . . . . . . . . . 111 A.3.6. Cargar una Medici´on Previa . . . . . . . . . . . . . . . 112
    • vi ´INDICE GENERAL A.4. Ayuda y Licencia . . . . . . . . . . . . . . . . . . . . . . . . . 113 B. Manual de C´odigo 115 B.1. Referencia de la Clase glperfex::MainFrame . . . . . . . . . . 116 B.1.1. Descripci´on detallada . . . . . . . . . . . . . . . . . . 117 B.1.2. Documentaci´on de las funciones miembro . . . . . . . 117 B.2. Referencia de la Clase configuracion::Configuration . . . . . . 124 B.2.1. Descripci´on detallada . . . . . . . . . . . . . . . . . . 125 B.2.2. Documentaci´on de las funciones miembro . . . . . . . 125 B.3. Referencia de la Clase contadores::Counters . . . . . . . . . . 130 B.3.1. Descripci´on detallada . . . . . . . . . . . . . . . . . . 131 B.3.2. Documentaci´on de las funciones miembro . . . . . . . 132 B.4. Referencia de la Clase contadores::CheckListCtrl . . . . . . . 135 B.4.1. Descripci´on detallada . . . . . . . . . . . . . . . . . . 136 B.4.2. Documentaci´on de las funciones miembro . . . . . . . 137 B.5. Referencia de la Clase resultados::Results . . . . . . . . . . . 137 B.5.1. Descripci´on detallada . . . . . . . . . . . . . . . . . . 138 B.5.2. Documentaci´on de las funciones miembro . . . . . . . 139 B.6. Referencia de la Clase resultados::ResultsPanel . . . . . . . . 144 B.6.1. Descripci´on detallada . . . . . . . . . . . . . . . . . . 144 B.6.2. Documentaci´on de las funciones miembro . . . . . . . 145 B.7. Referencia de la Clase io::IOInterface . . . . . . . . . . . . . . 149 B.7.1. Descripci´on detallada . . . . . . . . . . . . . . . . . . 150 B.7.2. Documentaci´on de las funciones miembro . . . . . . . 150 C. Licencias 161 C.1. GNU General Public License . . . . . . . . . . . . . . . . . . 163 C.2. GNU Free Documentation License . . . . . . . . . . . . . . . 178
    • ´Indice de figuras 3.1. Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . 29 3.2. Diagrama de Clases . . . . . . . . . . . . . . . . . . . . . . . 32 3.3. Diagrama de Secuencia: Generar Medici´on . . . . . . . . . . . 35 3.4. Diagrama de Secuencia: Cargar Medici´on . . . . . . . . . . . 38 3.5. Ejemplo de Fichero CSV: Una medici´on . . . . . . . . . . . . 41 3.6. Ejemplo de Fichero CSV: Tres mediciones . . . . . . . . . . . 42 3.7. Cuantos de tiempo en el planificador de Linux . . . . . . . . . 44 3.8. Estructura de Componentes de Karma GNU/Linux . . . . . . 45 3.9. Posicionamiento de ADEOS en el sistema operativo . . . . . 46 3.10. Composici´on RTAI y Linux . . . . . . . . . . . . . . . . . . . 48 3.11. Arquitectura del sistema PAPI . . . . . . . . . . . . . . . . . 53 4.1. Glperfex: ventana principal . . . . . . . . . . . . . . . . . . . 70 4.2. Glperfex: pesta˜na de contadores . . . . . . . . . . . . . . . . . 71 4.3. Glperfex: pesta˜na de resultados con siete ejecuciones . . . . . 72 4.4. Glperfex: pesta˜na de resultados con una ejecuci´on . . . . . . 73 4.5. Glperfex: opciones del men´u archivo . . . . . . . . . . . . . . 74 4.6. Glperfex: abriendo una prueba . . . . . . . . . . . . . . . . . 75 4.7. Glperfex: resultados cargados de un fichero CSV . . . . . . . 76 A.1. Manual de Usuario: abrir glperfex . . . . . . . . . . . . . . . . 106 A.2. Manual de Usuario: Medici´on con Planificador Est´andar . . . 107 A.3. Manual de Usuario: Medici´on con Planificador Est´andar . . . 108 A.4. Manual de Usuario: Medici´on con Planificador Est´andar 1 . . 111 A.5. Manual de Usuario: Resultados con Planificador Est´andar 2 . 112 A.6. Manual de Usuario: Ejecuci´on en Modo Exclusivo . . . . . . . 113 A.7. Manual de Usuario: Men´u Archivo . . . . . . . . . . . . . . . 114 vii
    • ´Indice de cuadros 3.1. Plantilla para la Definici´on de Casos de Uso . . . . . . . . . . 30 3.2. Ejemplo de Fichero CSV resultado de una medici´on . . . . . 40 3.3. Ejemplo de Fichero CSV resultado de tres mediciones . . . . 40 4.1. Configuraci´on del Entorno en Tiempo Real . . . . . . . . . . 61 4.2. Configuraci´on de perfctr dentro del kernel de Linux . . . . . . 62 4.3. Configuraci´on previa del kernel del Live CD . . . . . . . . . . 76 5.1. Resultados de las mediciones est´andar sin ruido . . . . . . . . 88 5.2. Resultados obtenidos para las pruebas est´andar con ruido . . 90 5.3. Resultados de las mediciones bajo entorno exclusivo . . . . . 91 A.1. Manual de Usuario: caracter´ısticas v´alidas de un ejecutable . 107 ix
    • Cap´ıtulo 1 Introducci´on En ciertas ocasiones, la ejecuci´on de programas se ve condicionada por la necesidad de una respuesta instant´anea. Un ejemplo de ello puede encon- trarse en programas que supervisan la din´amica de un sistema f´ısico, como el control de inyecci´on de combustible de un motor, que debe realizar la mezcla en un intervalo de tiempo determinado. A este tipo de computaci´on se le denomina computaci´on en tiempo real. Karma Linux es una distribuci´on de GNU/Linux en tiempo real dise˜nada para la medici´on de eventos de procesador. En nuestro caso, las exigencias de tiempo real vienen dadas por la necesidad de ejecutar programas en un procesador de manera que la medici´on de su ejecuci´on se vea condicionada por la menor cantidad posible de ruido, es decir, que el proceso lanzado pueda ejecutarse de forma exclusiva sobre el procesador, obteniendo as´ı el mayor rendimiento. En los ´ultimos a˜nos, los objetivos en el dise˜no de procesadores ha cam- biado radicalmente. La b´usqueda de la m´axima frecuencia, del mayor rendi- miento para un solo procesador se ha visto desbordada por el viejo concepto de la computaci´on paralela, estamos en la era de los multicore. La primera versi´on de Karma Linux fue desarrollada en septiembre de 2006 como proyecto fin de carrera del alumno de Ingenier´ıa T´ecnica en Inform´atica de Sistemas Pedro Navajas Modelo [1] bajo la direcci´on de Ezequiel Herruzo G´omez, profesor del Departamento de Arquitectura de Computadores, Electr´onica y Tecnolog´ıa Electr´onica. Esta primera versi´on estaba dise˜nada para la ejecuci´on en sistemas monoprocesador de la arquitectura x86, lo que implicaba que los programas ejecutados en Karma no pudieran aprovechar la capacidad de todas las tecnolog´ıas emergentes en paralelizaci´on de carga de procesador. Ejemplos de estas tecnolog´ıas podemos encontrar en HyperThreading de Intel (que simula dos 1
    • 2 1.1. Eventos del Procesador procesadores l´ogicos dentro de un ´unico procesador f´ısico, lo que supone una mejora en el uso del procesador de un 30 % [3]) implementado en algunos modelos de Pentium IV o en los casi ´ultimos procesadores de Intel, los Dual Core y Core 2 Duo. Por este motivo surgi´o la motivaci´on de realizar una nueva versi´on de Karma, que pudiese lograr ejecuciones ´optimas en estos ´ultimos procesadores, haciendo hincapi´e tambi´en en un dise˜no intuitivo de la aplicaci´on, de manera que pudiera ser utilizada f´acilmente con fines docentes. A continuaci´on vamos a realizar un enfoque de los conceptos necesarios para abordar la tarea. En el primer p´arrafo se defin´ıa a Karma Linux como una distribuci´on en tiempo real para la medici´on de eventos de procesa- dor. Por ello, en la introducci´on al proyecto es necesario definir estos dos conceptos que confluyen e introducir as´ı al lector de lleno en la tem´atica del mismo, de manera que la lectura de los subsiguientes cap´ıtulos sea lo m´as sencilla posible. En primer lugar haremos un enfoque sobre los even- tos del procesador, para mostrar c´omo se miden estos eventos a trav´es de contadores hardware que proporcionan los procesadores, y en segundo lugar realizaremos una introducci´on a los sistemas operativos en tiempo real y los conceptos fundamentales para la comprensi´on de los mismos. 1.1. Eventos del Procesador Los eventos del procesador son todas las operaciones at´omicas produci- das dentro del mismo. Nos referimos con at´omicas a las operaciones que al dividirse pierden su condici´on. Por ejemplo, una instrucci´on de procesador es divisible, pero cada una de sus divisiones no forman una instrucci´on. Dichos eventos est´an asociados a uno o varios recursos hardware (de- pendiendo de la arquitectura y modelo de procesador) y nos servir´an para obtener informaci´on acerca de la ejecuci´on de procesos y su rendimiento. Los contadores de monitorizaci´on de rendimiento (Performance Monito- ring Counters o PMC) son contadores hardware inclu´ıdos en la mayor´ıa de procesadores existentes en el mercado. Estos contadores registran un gran n´umero de eventos relacionados con el rendimiento de una aplicaci´on duran- te la ejecuci´on, por ejemplo, el n´umero de instrucciones ejecutadas, fallos de cach´e o cualquier evento propio de la familia del procesador. El objetivo de los PMCs es identificar problemas de rendimiento a bajo nivel, de manera que sea posible solucionar futuros problemas en la puesta en marcha de pro- yectos sensibles a la optimizaci´on del uso del dispositivo sobre el que ser´an ejecutados.
    • Introducci´on 3 1.1.1. Perfctr y Performance API Linux Performance-Monitoring Counters Driver (Perfctr) es una biblio- teca desarrollada por Mikael Pettersson, profesor del Departamento de Tec- nolog´ıas de la Informaci´on de la Universidad de Uppsala, que modifica el kernel de Linux para permitir el acceso a los contadores hardware de la m´aquina. El acceso a estos contadores se realiza a trav´es de un conjunto de PMCs virtuales accesibles desde el dispositivo /dev/perfctr, de esta ma- nera cada proceso pueda obtener, a trav´es de una llamada al sistema, los resutados de la medici´on de su ejecuci´on. La Performance Application Programming Interface (PAPI) es un pro- yecto desarrollado por el Departamento de Ingenier´ıa El´ectrica y Ciencias de la Computaci´on de la Universidad de Tennessee que trata de especificar una interfaz de programaci´on est´andar para el acceso a los contadores hard- ware del procesador a trav´es del driver perfctr. Provee dos interfaces, una de alto nivel y f´acil uso, y otra completamente programable a bajo nivel para necesidades m´as espec´ıficas. PAPI presenta una gran portabilidad, un c´odigo escrito usando PAPI debe medir los mismos eventos en distintas plataforma sin la necesidad de realizar ning´un cambio. Por otro lado para el acceso a contadores espec´ıficos de una m´aquina simplemente habr´a que utilizar la interfaz de bajo nivel anteriormente mencionada. 1.1.2. Ruidos La mayor´ıa de sistemas operativos modernos de prop´osito general com- parten una caracter´ıstica fundamental, permiten la planificaci´on multitarea. Esto supone la necesidad de ejecuci´on de procesos sobre uno o varios proce- sadores al mismo tiempo, por lo que el sistema operativo necesita crear una concurrencia virtual entre dichos procesos, de forma que puedan convivir en el mismo entorno de forma transparente al usuario. El procedimiento que se sigue para conseguir el objetivo de la multitarea se basa en la asignaci´on de prioridades a los diferentes procesos, seg´un la cual el planificador del sistema crea una cola en la que de cada proceso activo se ejecutar´a un cuanto1 de determinado tama˜no (influido por la prioridad el proceso). Para evitar atascos en la ejecuci´on de tareas, el planificador contempla mecanismos de reemplazo, seg´un los cuales un proceso de mayor prioridad puede reemplazar la ejecuci´on de uno de menor prioridad. De acuerdo con las caracter´ısticas del planificador del kernel de Linux, 1 Tiempo que el proceso puede ejecutarse sin ser reemplazado.
    • 4 1.2. Sistemas Operativos en Tiempo Real si un proceso requiere 20000 ms de tiempo de procesador para llevar a cabo su ejecuci´on completa, dependiendo del uso y de la prioridad, el planificador lo dividir´a en cuantos de aproximadamente 100 ms y lo trasladar´a a la cola junto al resto de procesos activos. Cuando entre en competici´on un proceso de mayor prioridad, es pro- bable que ´este reemplace a nuestro proceso aunque estuviera activo en ese momento de acuerdo con la capacidad de reemplazo del planificador. Esta caracter´ıstica de los sistemas operativos de prop´osito general difi- culta enormemente la capacidad de medir el tiempo que tarda el proceso en ejecutarse. Dependiendo de la carga del sistema, nuestro proceso, que re- quer´ıa 20000 ms, puede llegar a durar hasta m´as de 100000 ms, consumiendo un mayor n´umero de ciclos, provocando m´as fallos en memoria cach´e, etc. Esta intrusi´on de c´odigo de otros procesos es el concepto que de ahora en adelante llamaremos ruido, ya que provoca interferencias en la medici´on de eventos imposibles de predecir. 1.2. Sistemas Operativos en Tiempo Real Para comprender la diferencia en la ejecuci´on exclusiva de Karma Li- nux con las ejecuciones est´andar de Linux debemos diferenciar los Sistemas Operativos en tiempo real de los Sistemas Operativos convencionales. Una manera muy intuitiva de hacer esto es describir las caracter´ısticas de im- portancia que debe cumplir un Sistema Operativo y comentar las diferentes maneras de enfocarlas de los RTOS2 y los Sistemas Operativos de Prop´osito General. Estas caracter´ısticas principales son: planificaci´on de tareas, ma- nejo de interrupciones, sincronizaci´on y comunicaci´on y la gesti´on de la memoria. 1.2.1. Planificaci´on de tareas La planificaci´on de tareas o hilos es el principal problema de un sistema operativo. Mientras el sistema est´a en funcionamiento deben crearse y eli- minarse tareas, ´estas pueden cambiar su nivel de prioridad, necesidades de memoria, etc. En un sistema en tiempo real, estas tareas son m´as peligrosas que en un sistema operativo de prop´osito general: si se crea una tarea en tiempo real, debe obtener la memoria que requiera reservar sin demoras. Dicha memoria deber´a ser almacenada de manera que no se produzcan re- 2 Real Time Operating Systems, Sistemas Operativos en Tiempo Real
    • Introducci´on 5 trasos debidos a swapping3, por lo que los datos deber´ıan ser almacenados en memoria principal. Adem´as, cambiar la prioridad en la ejecuci´on de un proceso influir´ıa al comportamiento de toda la ejecuci´on del sistema, y el determinismo del mismo, que es una caracter´ıstica de gran importancia en un Sistema Operativo en Tiempo Real. Por ello la planificaci´on de tareas es uno de los principales rompecabezas en los RTOS. Normalmente, sobre un sistema multitarea, existen m´ultiples tareas acti- vas al mismo tiempo, y el sistema operativo es responsable de suministrar de manera compartida los recursos disponibles, es decir, tiempo de CPU, me- moria, etc. A la decisi´on del sistema operativo sobre la manera de compartir los procesadores se le denomina planificaci´on. Para la planificaci´on existen una serie de algoritmos, valorados en funci´on de su eficiencia y simpleza, su optimalidad. En los Sistemas Operativos en Tiempo Real se tiende a utilizar algoritmos de planificaci´on simples, ya que se necesita un tiempo de computaci´on peque˜no y determin´ıstico, debemos apostar por soluciones que se consuman la menor cantidad de memoria. En los Sistemas Operativos de prop´osito general, la pol´ıtica de planifi- caci´on difiere en gran medida, se tienen en cuenta los mismos principios, sin embargo en estos sistemas se pretende obtener un rendimiento ´optimo en valores medios, mientras que en los RTOS se requiere un comportamiento determinista. 1.2.2. Manejo de Interrupciones Un sistema operativo debe ser capaz, adem´as de capaz de planificar tareas de acuerdo con un algoritmo determinista, de proporcionar acceso a dispositivos perif´ericos como motores, sensores, contadores de tiempo, discos externos, etc. Esto requiere una atenci´on del sistema operativo de manera as´ıncrona, cuando el proceso en ejecuci´on requiere esos servicios, el sistema operativo debe comprobar que est´a listo para complacer los requerimientos, estas llamadas al sistema se denominan interrupciones. Existen dos tipos de interrupciones: Interrupciones de hardware El perif´erico pone un bit en un canal par- ticular, que comunica al procesador en el cual se ejecuta el sistema operativo que necesita ser servido. Como resultado de esto, el proce- 3 Se denomina swapping al modo de interrelacionar la memoria principal (que contiene el programa en ejecuci´on, proceso inmediato y resultados intermedios) con la secunda- ria, ampliando as´ı la capacidad de la memoria principal bas´andose en la capacidad del almacenamiento secundario.
    • 6 1.2. Sistemas Operativos en Tiempo Real sador almacena el estado actual y salta a la direcci´on en su espacio de memoria que ha sido conectada a la inicializaci´on de la interrupci´on. Interrupciones de software Muchos procesadores disponen de instruc- ciones equivalentes a las interrupciones de hardware generadas por software. El resultado tambi´en hace que se salte a una direcci´on de memoria especificada previamente. El sistema operativo no se involucra en principio en la ejecuci´on de el c´odigo que genera la interrupci´on del hardware, de esto se encarga el proce- sador sin que se vea interferido por ning´un software. Sin embargo, el sistema operativo tiene influencia, primero, en la conexi´on de la direcci´on de memo- ria con cada l´ınea de interrupci´on y segundo en los momentos posteriores a la interrupci´on. En los Sistemas Operativos en Tiempo Real, l´ogicamente, se debe proceder a un manejo de las interrupciones de manera que se garantice que las tareas son servidas de manera determinista. 1.2.3. Comunicaci´on y Sincronizaci´on La tercera responsabilidad de un sistema operativo es conocida como co- municaci´on entre procesos (Inter-Process Communication o IPC). La IPC comprende una extensa cantidad de primitivas de programaci´on que el sis- tema operativo ofrece para la necesidad de intercambio de informaci´on con otras tareas y/o la sincronizaci´on en sus acciones. En los RTOS, debe obte- nerse una comunicaci´on y sincronizaci´on de manera determinista. Hay que recordar que la comunicaci´on y sincronizaci´on con otras tareas no se limita simplemente a aquellas que son ejecutadas en la misma m´aqui- na, sino que pueden aplicase tambi´en a la necesidad de comunicaci´on entre perif´ericos o dispositivos en red. 1.2.4. Gesti´on de la memoria La cuarta responsabilidad de un sistema operativo es la gesti´on de me- moria. Los diferentes procesos en el sistema requieren una parte de la memoria disponible. En ocasiones, esta memoria debe estar almacenada en una direcci´on espec´ıfica. Por lo tanto, el trabajo del sistema operativo es dar a cada proceso la memoria que necesita, memory allocation, realizar el mapeo de memoria real en los diferentes rangos de direcciones usadas por las tareas que requieren la memoria, memory mapping, y realizar la acci´on apropiada
    • Introducci´on 7 cuando una tarea utiliza memoria que no ha sido reservada4. A esto se le llama tambi´en protecci´on de memoria, que en ocasiones suele solucionarse simplemente matando el proceso que ha pedido el acceso no autorizado. Una vez introducidos los conceptos necesarios para comprender los di- ferentes conceptos en los que se basa la definici´on, dise˜no y soluci´on del proyecto, podemos comenzar el proceso de desarrollo del mismo. El estudio de dichos conceptos en las diferentes asignaturas que compo- nen el plan de estudios de la titulaci´on de Ingeniero T´ecnico en Inform´atica de Sistemas no cumple con los requisitos adecuados para la comprensi´on del mismo. Por ello, hemos considerado necesaria una introducci´on profunda en la materia, de manera que el alumno, o cualquier lector interesado en re- tomar el proyecto o simplemente estudiarlo, pueda inmiscuirse en el mismo desde el comienzo, con una curva de aprendizaje pronunciada al inicio pero m´as suave a medida que se avanza en la lectura. 4 Causas comunes de esto son punteros no conectados, o utilizaci´on de valores fuera de un array reservado.
    • Cap´ıtulo 2 Definici´on del Problema 2.1. Identificaci´on del Problema Real La informaci´on acerca del rendimiento es crucial en el desarrollo de cual- quier proyecto software. Los recursos inform´aticos reales no son infinitos, y este problema se convierte en excesivamente cr´ıtico si estamos tratando con sistemas empotrados y en definitiva toda clase de sistemas en tiempo real, donde la optimizaci´on de c´odigo debe enfocarse hacia el objetivo de una ejecuci´on r´apida que realice el menor n´umero de ciclos de procesador posible. Para obtener toda esa informaci´on en la ejecuci´on de un programa, son necesarias herramientas de detecci´on que nos proporcionen una interfaz con las capacidades de medici´on que ofrece el procesador sobre datos como ciclos de ejecuci´on, accesos o fallos de cach´e. El proceso de medici´on de cualquier magnitud debe entra˜nar la m´axima exactitud posible. En el caso que nos ocupa, la medici´on de eventos de procesador viene marcada por la condici´on de “convivencia” de procesos en un sistema operativo enfocado a la ejecuci´on concurrente de programas. Esta ejecuci´on en convivencia, puede provocar mediciones con un exceso evidente de ruido que nos lleve a conclusiones err´oneas a la hora de enfocar el dise˜no de nuestro programa si consideramos estas mediciones como propias de un contexto determinista1. Adem´as de controlar la fiabilidad de la medici´on, a la hora de la realiza- ci´on de pruebas es necesario mantener el enfoque de portabilidad del sistema, es decir, debemos ofrecer la capacidad de ejecutar las pruebas en el mayor 1 Un contexto determinista en este caso se trata de aquel entorno donde se obtiene el mismo resultado bajo unas condiciones iniciales similares. 9
    • 10 2.2. Identificaci´on del Problema T´ecnico n´umero de entornos posible. De esta manera, el dise˜no de nuestro sistema de pruebas no puede ce˜nirse a dispositivos monoprocesador, sino que debemos dar un paso adelante y permitir la entrada de la tecnolog´ıa emergente de procesadores multin´ucleo2, permitiendo aislar ejecuciones determin´ısticas en m´as de un n´ucleo o procesador. Por ´ultimo, el proceso de medici´on debe ser transparente al usuario, y a ser posible, lo m´as intuitivo posible. Esto hace necesario un entorno donde no sea necesario recompilar el c´odigo para lanzar ejecuciones, donde todos los elementos para la medici´on est´en ya disponibles, sin necesidad de instalar software adicional, y donde la facilidad de uso mediante una interfaz sencilla lleven a la persona encargada de realizar las pruebas al objetivo inicial de optimizaci´on del programa en un entorno fiable y, a pesar de no tratarse de una expresi´on de nuestro gusto, amigable. 2.2. Identificaci´on del Problema T´ecnico A continuaci´on se presentan los aspectos t´ecnicos relevantes a la hora de llevar a cabo la identificaci´on del problema t´ecnico haciendo uso de la t´ecnica de Especificaciones del Dise˜no del Producto (Product Design Specification o PDS), que nos permite realizar un an´alisis de los principales condicionantes t´ecnicos respondiendo a los siguientes apartados. 2.2.1. Funcionamiento El proyecto consta de cuatro apartados fundamentales definidos a con- tinuaci´on: lperfex Es la aplicaci´on encargada de realizar mediciones de procesador de cualquier tarea. lperfex dispone de una interfaz gr´afica llamada glperfex que incrementa las posibilidades de esa interfaz permitiendo extraer y guardar datos y gr´aficas de dichas ejecuciones. El funcionamiento de lperfex no es intrusivo, ya que realiza un proceso v´ırico (intercepta el inicio del proceso, colocando c´odigo al inicio y al fin con el objetivo de preparar y recoger los resultados de ejecuci´on del programa). 2 En la redacci´on del manual t´ecnico se utilizar´an indistintamente los conceptos de multin´ucleo, su equivalente en ingl´es multicore y multiprocesador para referirnos a la ejecuci´on de procesos del sistema operativo en m´aquinas con m´as de un procesador, ya sea real o virtual.
    • Definici´on del Problema 11 Dicho programa puede, por lo tanto, haber sido escrito en C, Fortran o cualquier lenguaje que permita generar un fichero ejecutable que cum- pla con los est´andares comentados en el apartado 2.2.7, dependiendo la medici´on simplemente de la existencia de un binario a ejecutar, faci- litando as´ı el proceso al usuario, que no deber´a recompilar el programa para realizar las pruebas. RTAI Como se describi´o en la identificaci´on del problema real, debe existir un elemento que permita la ejecuci´on del proceso a medir de forma independiente al planificador del kernel de Linux. Para realizar estas mediciones ser´a necesaria la utilizaci´on de una herramienta que se coloque por encima del propio n´ucleo, eludiendo as´ı los cambios de contexto provocados por las interrupciones software, el reemplazo en la cola de planificaci´on, etc. La herramienta que permite esta capacidad es el proyecto RTAI, que ofrece a nuestro sistema la capacidad de realizar operaciones en tiempo real. PAPI Este es el elemento en el que se basa lperfex para acceder a los contadores hardware que el usuario desee medir. Haciendo uso del driver perfctr, PAPI permite al programador me- diante una biblioteca sencilla y portable realizar mediciones de esos contadores. Live CD La aplicaci´on lperfex necesita un entorno de ejecuci´on que dispon- ga de unas caracter´ısticas especiales. Necesita acceso a los contadores hardware que ofrece el procesador para obtener las estad´ısticas soli- citadas de cada ejecuci´on as´ı como las caracter´ısticas de tiempo real que coment´abamos en la descripci´on de RTAI. Para ello es necesaria la instalaci´on de parches al kernel de Linux y carga de varios m´odu- los as´ı como la instalaci´on de varias bibliotecas. Para evitar la tediosa operaci´on de instalar todos los componentes en un sistema, la opci´on m´as sencilla es presentar todo el sistema empaquetado en un Live CD con herramientas b´asicas como un entorno gr´afico, navegador web, he- rramientas de oficina, desarrollo, etc. 2.2.2. Entorno Como se adelant´o a la hora de definir el funcionamiento, el entorno de ejecuci´on de nuestro sistema se forma en un Live CD. Un Live CD forma un sistema operativo ejecutado al arrancar la m´aqui- na sin realizar ninguna instalaci´on en el disco duro. Contiene una imagen
    • 12 2.2. Identificaci´on del Problema T´ecnico comprimida del sistema, en este caso con todas las caracter´ısticas requeri- das. Una vez arrancado, descomprime el sistema de ficheros del CDROM (squashfs) y comienza el arranque. Una de las caracter´ısticas de los Live CD es que adaptan la configuraci´on del sistema a la m´aquina sobre la que se est´an ejecutando. De esta manera, se detectar´an los dispositivos de los que dispone la misma y los configurar´a correctamente para el trabajo a realizar. Una vez cargada la configuraci´on y arrancado el sistema, nos encontrare- mos con el entorno tal y como fue dise˜nado para su uso. El kernel del sistema operativo, convenientemente parcheado, habr´a cargado los m´odulos necesa- rios tanto para la ejecuci´on exclusiva de tareas cuando esta sea requerida, como para acceder correctamente a los contadores hardware. La principal novedad de Karma Linux 2008, adem´as de la posibilidad de aislar en los procesadores deseados la carga del programa a ejecutar es la incorporaci´on de la interfaz gr´afica glperfex para realizar las mediciones. De esta manera, adem´as de facilitar el trabajo con nuevas opciones para el usuario, se pretende que la aplicaci´on pueda ser utilizada de forma sencilla con fines docentes, donde los alumnos no se tendr´an que enfrentar al impe- dimento de no tener un alto conocimiento de interacci´on con la terminal del sistema (modo de interacci´on original de lperfex). Por ello, con estas facili- dades, el entorno de ejecuci´on de la aplicaci´on se hace plenamente accesible sin necesidad de configuraci´on ni grandes conocimientos previos. No obstante, Karma sigue ofreciendo la capacidad de utilizar lperfex sin necesidad de interfaz gr´afica, mediante la interacci´on est´andar por consola de getopts. 2.2.3. Vida Esperada La capacidad de adaptaci´on a la medici´on de ejecuci´on, y a las carac- ter´ısticas de cualquier sistema (siempre teniendo en cuenta la arquitectura x86 para la que ha sido dise˜nada la distribuci´on) mediante la detecci´on de dispositivos, hace que el proyecto pueda seguir cubriendo las necesidades para las que se dise˜na a lo largo del tiempo. 2.2.4. Ciclo de Mantenimiento Karma est´a compuesto de una serie de herramientas libres, cuyo desarro- llo se lleva a cabo por una comunidad muy activa. Si se examinan art´ıculos provistos tanto en la p´agina web de RTAI [6] o en la de PAPI [7] existen una gran cantidad de proyectos afectados por el desarrollo de dichas bibliotecas,
    • Definici´on del Problema 13 que cada d´ıa ampl´ıan su soporte a nuevas arquitecturas o familias de proce- sadores. Este hecho hace que el futuro mantenimiento de Karma ampl´ıe los horizontes para los que ha sido dise˜nado de manera que se cubran nuevos procesadores y se adapte a la medici´on real en todo tipo de entornos. El dise˜no modular del sistema, hace posible la actualizaci´on sencilla de com- ponentes, de manera que el proyecto no ser´a dif´ıcil de retomar en futuras versiones. 2.2.5. Competencia La competencia a la aplicaci´on, tal y como se describir´a en el apartado 2.4 es escasa, existen escasos antecedentes que se puedan ajustar a las ca- racter´ısticas requeridas a la hora de concebir el proyecto y en caso de existir son obsoletos. 2.2.6. Aspecto Externo Como se ha comentado a lo largo del apartado 2.2, el aspecto externo ser´a el Live CD desde el que se ejecutar´a la aplicaci´on de medici´on. Este englobar´a la aplicaci´on lperfex y sus dependencias, incluyendo las bibliotecas encargadas de interceptar tareas y a˜nadir c´odigo al principio y final de las tareas interceptadas. La interfaz gr´afica lperfex ser´a dise˜nada usando el binding3 de la bibliote- ca gr´afica wxWidgets para el lenguaje de programaci´on Python, wxPython. Esta biblioteca se caracteriza por ser multiplataforma, por lo que su uso junto a Python permite el desarrollo r´apido de aplicaciones gr´aficas multi- plataforma. Puesto que ´esta se trata no se trata de una aplicaci´on de ´ambito comer- cial, las caracter´ısticas de presentaci´on y distribuci´on del soporte del sistema no se tendr´an en cuenta. 2.2.7. Estandarizaci´on El desarrollo de un proyecto software libre requiere un ´enfasis en la estan- darizaci´on del sistema, de manera que los potenciales desarrolladores puedan realizar futuros cambios y modificaciones de forma que se fomente la mejora del proyecto. 3 En el campo de la programaci´on, un binding es una adaptaci´on de una biblioteca para ser usada en un lenguaje de programaci´on distinto de aqu´el en el que ha sido escrita.
    • 14 2.2. Identificaci´on del Problema T´ecnico La distribuci´on sigue las indicaciones de la Linux Standard Base (LSB), con la salvedad del uso, impl´ıcito en distribuciones de tipo Debian, de empaquetado deb en lugar de rpm [8]. Esta excepci´on se podr´ıa salvar utilizando el programa alien en el empaquetado. Se pue- den consultar cr´ıticas sobre esta normativa en [9] y [10]. Las mediciones s´olo ser´an admitidas para ficheros ejecutables que sigan el formato de enlazado ELF4. Adem´as para el uso de lperfex por terminal se utilizar´a el est´andar definido por la GNU Libc getopts adem´as de utilizar las herramientas de edici´on de proyectos autotools. A la hora de desarrollar la interfaz gr´afica, el enfoque se dirige a Python en su versi´on 2.4, para guardar compatibilidades, mientras que por con respecto a wxPython se utilizar´an caracter´ısticas de la versi´on de 2.8 debido a las numerosas mejoras que presenta frente a versiones anteriores. 2.2.8. Calidad y Fiabilidad La calidad y fiabilidad del producto final ser´an evaluadas comprobando la mejora del sistema mediante tests realizados en caracter´ısticas norma- les de uso y los tests realizados aislando los procesos en los procesadores especificados en la prueba. Midiendo tambi´en la diferencia entre entornos con ruido y entornos sin ruido que demuestren la calidad y precisi´on de la soluci´on final. 2.2.9. Programa de Tareas A diferencia de la primera versi´on de Karma, el proyecto fin de carrera parte de una soluci´on dada y pretende una mejora de la misma. De esta manera, que la carga de investigaci´on del mismo se ha visto reducida sensi- blemente. Tambi´en debemos tener en cuenta que al tratarse de un proyecto fin de carrera, en principio, y adapt´andonos al caso que nos ocupa, no es necesario un c´alculo de costes o plazos de ejecuci´on. 4 El formato ELF (Executable and Linkable Format) es un formato de archivo para ejecutables, c´odigo objeto, librer´ıas compartidas y volcados de memoria. Fue desarrollado por el Unix System Laboratory (USL) como parte de la ABI. En principio fue desarrollado para plataformas de 32 bits, a pesar de que hoy en d´ıa se usa en gran variedad de sis- temas. Es el formato ejecutable usado mayoritariamente en los sistemas tipo Unix como GNU/Linux, BSD, Solaris, IRIX. Existen otros formatos soportados en algunos de estos sistemas como COFF o a.out, pero ELF es sin duda el m´as usado.
    • Definici´on del Problema 15 Las fases de desarrollo del proyecto ser´an: Fase de Preparaci´on Durante esta fase se reunir´a la informaci´on necesa- ria para abordar la realizaci´on del proyecto. Estudio de Karma Linux original en su conjunto desgranando los componentes. Estudio de la herramienta lperfex. Estudio de RTAI. Fase de Especificaci´on de Requisitos Durante esta etapa ha de reali- zarse una descripci´on del comportamiento del sistema y los objetos individuales que forman parte del mismo, analizando las condiciones que debe reunir el sistema final. Fase de Implementaci´on Como resultado de la fase de especificaci´on de requisitos se implementar´a la soluci´on final con los cambios y adiciones necesarias a Karma Linux. Fase de Pruebas Se analizar´an las mejoras realizadas con las condiciones iniciales planteadas respecto a la versi´on original de Karma Linux, de manera que en caso de ser positiva se construya una nueva versi´on de Karma Linux en un Live CD. Fase de Documentaci´on Se reunir´an los documentos generados en fases anteriores para la redacci´on de los documentos pertinentes. 2.2.10. Pruebas En la fase final del proyecto, como hemos visto en el apartado anterior, se someter´a al sistema a un conjunto de pruebas para comparar los resultados previos y poder extraer conclusiones de las mejoras. Adem´as de las pruebas propias de la mejora de la aplicaci´on, ser´an ne- cesarias pruebas de caja blanca durante la codificaci´on de las codificaciones y modificaciones de c´odigo. 2.2.11. Seguridad La seguridad del sistema est´a basada en la seguridad propia de los siste- mas tipo Unix. La cuenta de usuario del Live CD tiene una contrase˜na que impide el acceso al mismo desde fuera del ordenador. Es decir, el usuario
    • 16 2.3. Objetivos deber´a tener acceso f´ısico al mismo, o acceder por red conociendo el usuario y contrase˜na con protocolos como SSH. Por otro lado la aplicaci´on es software libre bajo licencia GNU GPL versi´on 3, esto quiere decir, que todo el c´odigo y la aplicaci´on estar´a dis- ponible para el desarrollo de cualquier desarrollador que desee mejorarlo o modificarlo. Por ello no existir´a ning´un m´etodo de protecci´on anticopia. 2.3. Objetivos Una vez identificado el problema real y t´ecnico se exponen los objetivos a alcanzar con el desarrollo del proyecto. Como hemos adelantado, Karma Linux 2008 se plantea como una actualizaci´on de Karma Linux que supla las carencias del mismo en materia de usabilidad y se adapte a los nuevos procesadores multin´ucleo. 2.3.1. Adaptaci´on de Karma a Procesadores Multin´ucleo Como se mencion´o en la introducci´on, la implantaci´on del procesadores multin´ucleo en el mercado es una realidad a d´ıa de hoy. El enfoque mono- procesador de Karma Linux hace que la distribuci´on no pueda aprovechar ni examinar las capacidades de estos nuevos sistemas. Por ello el primer objetivo a cumplir por el proyecto es habilitar la he- rramienta lperfex para la medici´on de ejecuciones exclusivas en multipro- cesador, de manera que el programa detecte el n´umero de procesadores de la m´aquina y permita elegir en qu´e procesador o procesadores realizar la medici´on. 2.3.2. Mejora de la Usabilidad Una de las posibles ´areas de aplicaci´on de Karma Linux es la docencia. La medici´on de eventos de procesador al ejecutar un programa nos permite observar la mejora de esa ejecuci´on en distintos procesadores y programas, siendo informaci´on ´util para la comprensi´on de materias relacionadas con Sistemas Operativos y Arquitectura de Computadores. lperfex es, como hemos comentado anteriormente, una aplicaci´on acce- sible s´olo a trav´es de terminal mediante la interfaz de uso getopts. Esto dificulta la interacci´on con el mismo para un usuario inexperto adem´as de
    • Definici´on del Problema 17 limitar la informaci´on expuesta al no poder a˜nadir, por ejemplo, gr´aficas para ilustrar la ejecuci´on. Por ello, otro de los objetivos del proyecto es dotar a lperfex de una in- terfaz sencilla capaz de mostrar los resultados correctamente, a˜nadir gr´aficas al mismo y ofrecer la capacidad de almacenar los resultados para posteriores visualizaciones y comparaciones de forma compatible con programas tales como hojas de c´alculo, etc. A partir de ahora nos referiremos a esta interfaz como glperfex. 2.3.3. Autonom´ıa de la Plataforma El objetivo de garantizar la autonom´ıa de la plataforma hereda del plan- teamiento de Karma Linux original. Debido a la necesidad de un entorno especial en el que el planificador permita un mayor control sobre el procesa- dor y la cola de procesos, de manera que podamos garantizar la ausencia de ruidos externos en la ejecuci´on del programa a medir, ser´a necesario crear una plataforma donde la aplicaci´on y el entorno puedan existir de forma aut´onoma, proveyendo al usuario todas las herramientas necesarias para el desarrollo de su tarea. Esto conlleva: La construcci´on de un sistema comprimido en una imagen grabable a un CDROM con todas las bibliotecas, m´odulos y parches necesarios para la ejecuci´on de nuestro entorno. Autodetecci´on de hardware durante el arranque de la imagen del siste- ma, de manera que se generen los ficheros de configuraci´on necesarios para la ejecuci´on del mismo en cualquier m´aquina de la arquitectura x86 y x86 64. Construcci´on de paquetes adicionales para mejorar la usabilidad del sistema, esto significa incluir navegadores web, hojas de c´alculo, com- piladores y un entorno gr´afico. 2.4. Antecedentes A continuaci´on se presentan los antecedentes al proyecto a realizar, di- vidimos estos antecedentes en cuatro apartados. En primer lugar aquellas aplicaciones o interfaces de programaci´on para evaluar el funcionamiento de programas accediendo a contadores hardware, en segundo lugar los sistemas operativos o modificaciones que permitan la ejecuci´on de modo exclusivo de procesos, en tercer lugar analizaremos el antecedente de la distribuci´on y
    • 18 2.4. Antecedentes punto de partida principal del proyecto, Karma Linux, y por ´ultimo comenta- remos algunas soluciones posibles para realizar tests destinados a comprobar las mejoras que ofrece nuestro sistema. 2.4.1. Antecedentes a Lperfex y Glperfex ContEven Proyecto Fin de Carrera de Antonio Espinar Ruiz para el an´ali- sis de rendimiento de procesadores de tipo Pentium y AMD desarrolla- do en el ´Area de Arquitectura de Computadores del Departamento de Arquitectura de Computadores, Electr´onica y Tecnolog´ıa Electr´onica de la Universidad de C´ordoba en 2003. El inconveniente fundamen- tal que no hace aplicable el proyecto como soluci´on es que ´este s´olo muestra informaci´on gen´erica del procesador sin aprovechar la infor- maci´on que nos proporcionan los contadores hardware del procesador. Este programa funciona en la plataforma Windows, lo que traiciona nuestro objetivo moral de aportar una soluci´on utilizando ´unicamente software libre a la hora de enfocar el proyecto. Perfex Herramienta para la realizaci´on de tests en sistemas con procesador R10K y sistema operativo IRIX de Silicon Graphics a trav´es de los contadores de eventos proporcionados por dichos procesadores. Por ello se trata de una aplicaci´on imposible de adaptar a sistemas distintos para los que est´a concebido. SpeedShop Es un conjunto de herramientas para la ejecuci´on de prue- bas de rendimiento en programas ejecutables y examinar los resul- tados de dichas pruebas. Proporciona no s´olo las estad´ısticas t´ıpi- cas de programas de an´alisis de rendimiento de procesador como uso del procesador, estado de la pila o registro de excepciones, sino que adem´as, incorpora experimentos que que permiten analizar directa- mente el rendimiento de la memoria cach´e, fallos de acceso a memoria cach´e de datos e instrucciones, fallos de acceso a TLB5, controles como fork, exec, sproc, etc. Sin embargo al igual que Perfex, SpeedShop s´olo puede ser utilizado en sistemas IRIX. Papiex Sistema similar a la herramienta Perfex para entornos x86. Esta aplicaci´on se distribuye junto a PAPI y es ´util para el estudio de la intercepci´on de procesos. Sin embargo no ser´ıa soluci´on a nuestros objetivos al no permitir una ejecuci´on exclusiva del proceso sobre el procesador, adem´as de ser una herramienta poco actualizada [1]. 5 Translation Lookaside Buffer (TLB) es un b´ufer o cach´e en una Unidad de Procesa- miento Central (CPU), que contiene partes de la tabla de paginaci´on, es decir, relaciones entre direcciones virtuales y reales.
    • Definici´on del Problema 19 Intel Vtune Analiza el rendimiento de programas para Windows y Linux. Est´a dise˜nado para desarrollar software m´as eficiente y r´apido en sis- temas mono y multiprocesador. Adem´as, analiza aplicaciones sin ne- cesidad de recompilaci´on o enlazado [11]. Sin embargo, VTune est´a di- se˜nado exclusivamente para procesadores Intel, y el coste de su licencia es elevado. 2.4.2. Antecedentes de Planificadores en Tiempo Real RTLinux Es un sistema operativo en tiempo real utilizado en proyectos de medicina o aeron´autica [12]. Su vertiente de c´odigo abierto ha ca´ıdo en desuso [13] y la versi´on comercial es descartada por su car´acter privativo por las mismas razones que argument´abamos al hablar de ContEven. RTAI Es un sistema de tiempo real que utiliza una capa de abstracci´on llamada ADEOS y soporta arquitecturas como x86, PowerPC, ARM y MIPS [14]. El proyecto RTAI es software libre y se utiliz´o para para la planificaci´on de procesos de modo exclusivo en Karma Linux, nuestro antecedente principal. 2.4.3. Antecedentes de la Distribuci´on Karma Linux Es una distribuci´on de Linux en tiempo real para la me- dici´on de eventos [1]. Karma Linux est´a enfocado como adelantamos en la introducci´on en el uso del modo exclusivo de ejecuci´on sobre un ´unico procesador para los eventos que la requieran. La limitaci´on fun- damental de Karma Linux radica en este hecho, que impide un funcio- namiento ´optimo en sistemas multiprocesador. Adem´as, la aplicaci´on utilizada para la medici´on de contadores hardware carece de interfaz de usuario m´as all´a de la terminal. Con la realizaci´on de este proyecto pretendemos solventar estas dos limitaciones de Karma Linux. 2.4.4. Antecedentes a Sistemas de Benchmarking El benchmark es una t´ecnica utilizada para medir el rendimiento de un sistema o componente de un sistema, frecuentemente en comparaci´on con el cual se refiere espec´ıficamente a la acci´on de ejecutar un benchmark. La palabra benchmark es un anglicismo traducible al castellano como compa- rativa. Si bien tambi´en puede encontrarse esta palabra haciendo referencia al significado original en la lengua anglosajona, es en el campo inform´atico
    • 20 2.4. Antecedentes donde su uso est´a m´as ampliamente extendido. M´as formalmente puede en- tenderse que un benchmark es el resultado de la ejecuci´on de un programa inform´atico o un conjunto de programas en una m´aquina, con el objetivo de estimar el rendimiento de un elemento concreto, o la totalidad de la misma, y poder comparar los resultados con m´aquinas similares [15]. Los benchmarks analizados fueron: Standard Performance Evaluation Corporation (SPEC) Es un con- sorcio sin fines de lucro que incluye a vendedores de computadoras, integradores de sistemas, universidades, grupos de investigaci´on, pu- blicadores y consultores de todo el mundo. Son los responsables del conjunto de tests SPEC CPU2000, un benchmark creado con el fin de proveer una medida de rendimiento que pueda ser usado para com- parar cargas de trabajo intensivas de c´omputo en distintos sistemas. Se divide en dos suites principales, la CINT2000, orientada a la medi- ci´on de computaci´on sobre enteros, y la CFP2000, para punto flotante. SPEC CPU2000 incluye algoritmos de teor´ıa de juegos e Inteligencia Artificial, recorrido de ´arboles, compiladores e int´erpretes, compresi´on de datos, bases de datos, predicci´on del clima, din´amica de fluidos, f´ısi- ca, qu´ımica y procesamiento de im´agenes, con lo que se puede probar un amplio espectro de algoritmia con dichos tests [16]. Los benchmarks SPEC fueron los elegidos para la realizaci´on de un art´ıculo sobre Kar- ma Linux presentado en el Congreso CEDI en 2005 [17]. NAS BenchMark Colecci´on de benchmark creados por la NASA. El pro- grama NAS naci´o como un gran esfuerzo por parte del centro de inves- tigaciones de la NASA para avanzar en el estudio de la computaci´on aerodin´amica. NAS presenta la ventaja de que al ser desarrollados con la computaci´on paralela en mente, son gen´ericos y no favorecen nin- guna m´aquina de forma espec´ıfica. Adem´as, a pesar de que la mayor´ıa de tests son de ejecuci´on paralela (usando MPI), tambi´en existe una rama que incluye los principales tests NAS en modo serial. El bench- mark NAS posee tres algoritmos principales, Lower-Upper Symmetric Gauss-Seidel (LUS), Scalar Penta-diagonal (SP) y Block Tri-diagonal (BT). Los test NAS cargan principalmente al procesador, teniendo escasa o nula presencia de entrada/salida [18]. Perfect Bencharmak Es una prueba orientada a superordenadores y pro- ceso en paralelo. Consta de 13 programas en FORTRAN, que incluyen aplicaciones de ingenier´ıa y cient´ıficas, representando a cuatro ´areas de estudio reales: mec´anica de fluidos, f´ısica y qu´ımica, dise˜no de inge- nier´ıa y procesado de se˜nal. Los resultados, expresados en millones de operaciones en coma flotante por segundo (MFLOPS), son calculados como la media geom´etrica de los resultados de este juego de tests [21].
    • Definici´on del Problema 21 2.5. Restricciones A continuaci´on se expondr´an las restricciones o factores limitativos exis- tentes en el ´ambito del dise˜no y que condicionan la elecci´on de las diferentes alternativas. 2.5.1. Factores Dato En el desarrollo del proyecto se considerar´an los siguientes factores dato: El resultado final ha de se transparente al usuario, esto implica que el usuario no tendr´a que realizar una configuraci´on previa del sistema y que la aplicaci´on a probar no requerir´a ser recompilada. Por lo tanto las mediciones se realizar´an sobre c´odigo compilado sin que el c´odigo de C, Fortran o cualquier lenguaje deba ser tratado de manera especial, siempre que haya sido compilado de acuerdo con el est´andar ELF. El sistema ha de ser multiplataforma, satisfaciendo as´ı el objetivo de crear un sistema aut´onomo e independiente de la plataforma donde se desee ejecutar (aunque no de la arquitectura). Adem´as deber´a ser capaz de aprovechar las tecnolog´ıas multiprocesador. Se har´a uso de la aplicaci´on lperfex y las bibliotecas RTAI y PAPI adoptando la soluci´on escogida en Karma Linux original para imple- mentar la medici´on no intrusiva de eventos. Esto implica que las fun- cionalidades a extender (no hablamos de proporcionar una interfaz gr´afica al programa, sino del funcionamiento interno del sistema de medici´on) deber´an programarse en C y deber´an cumplir con la licen- cia v´ırica GNU GPL v2 [19] de lperfex. Esto significa, que nuestra aplicaci´on ampliada, de acuerdo con la licencia GNU GPL, podr´a li- cenciarse como GPL v2 o superior, contando esta elecci´on como un factor estrat´egico. Uso de GNU/Linux, por motivos an´alogos al punto anterior, ya que este proyecto se plantea como una ampliaci´on de Karma Linux, todo deber´a enfocarse desde y para este sistema operativo. 2.5.2. Factores Estrat´egicos Tambi´en se considerar´an los siguientes factores estrat´egicos:
    • 22 2.5. Restricciones Enfoque del trabajo hacia la arquitectura x86, arquitectura de mayor uso y mayor facilidad de acceso a la hora de realizar el proyecto. Se podr´ıa realizar una versi´on de arquitectura x86 64, sin embargo esto impedir´ıa su aplicaci´on en la mayor´ıa de monoprocesadores comunes y en los Intel Core Duo (ordenadores a d´ıa de hoy utilizados en las aulas de inform´atica de la Universidad de C´ordoba). Uso de la licencia GNU GPL v3. Como se adelant´o en el tercer punto de los factores dato, lperfex, aplicaci´on que nos permitir´a realizar las mediciones de forma no intrusiva, ya sea usando un planificador en tiempo real o el planificador cl´asico del kernel de Linux, est´a licenciada seg´un la GNU GPL v2. Esta forma de licenciar el producto da la posibilidad de escoger en las modificaciones la licencia GNU GPL v2 o una licencia superior. En este caso se escoger´a la licencia GNU GPL v3 persiguiendo los objetivos de la misma en defensa del software libre [20]: • Resolver formas en que a pesar de todo alguien pod´ıa quitar li- bertades a los usuarios. • Como un caso especial de lo anterior: Prohibir el uso de softwa- re cubierto por licencias de sistemas dise˜nados para sustraer las libertades de los usuarios del mismo (como las tecnolog´ıas cono- cidas como DRM6). • Resolver ambig¨uedades y aumentar su compatibilidad con otras licencias. • Facilitar su adaptaci´on a otros pa´ıses. • Incluir cl´ausulas que defiendan a la comunidad de software libre del uso indebido de patentes de software. Realizaci´on de una interfaz gr´afica para la aplicaci´on lperfex de mo- do que se facilite la usabilidad del programa y que se proporcionen una serie de funcionalidades extra. Esto responde al inter´es de difun- dir la aplicaci´on entre personas sin un gran conocimiento del manejo de comandos bajo Unix. Desafortunadamente esto es com´un no s´olo entre alumnos de inform´atica sino tambi´en entre profesionales de la inform´atica. 6 Digital Rights Management (DRM) es un conjunto de tecnolog´ıas orientadas a ejercer restricciones sobre los usuarios de un sistema forzando de esta manera los derechos digitales permitidos por comisi´on de los poseedores de esos derechos de autor e independientemente de la voluntad del usuario/consumidor del mismo. Generalmente estos dispositivos son instalados como condici´on previa a la distribuci´on de software no libre, obras musicales, libros electr´onicos o cualquier tipo de archivo sujeto a derechos de autor. En algunos casos, las restricciones aplicadas se extienden m´as all´a de los archivos que deb´ıan proteger, agregando restricciones sobre el uso de otros documentos o aplicaciones presentes en la m´aquina.
    • Definici´on del Problema 23 Uso de Python para la realizaci´on de la interfaz gr´afica. Este factor estrat´egico se debe a la versatilidad del lenguaje, debida a la gran cantidad de bibliotecas que contiene, no s´olo para la realizaci´on de interfaces gr´aficas sino para manejo de cualquier tipo de dato, accesos al sistema, etc. Python nos ofrece una sencillez a la hora de programar que favore- cer´a tanto la rapidez del desarrollo de la interfaz, como la interacci´on con lperfex, gracias a la facilidad para operar con entradas y salidas de programas (stdin, stdout, stderr) o la posibilidad de realizar llamadas a funciones de C a trav´es de bindings. Con respecto a las pruebas de benchmarking se descartan los test Per- fect Benchrmark debido a que su antig¨uedad (los test son anteriores a 1985), hace que alguno de estos tests no sean compatibles con los compiladores modernos de Fortran. A pesar de su frecuente uso en el pasado, dichos test apenas se mencionan en documentos a partir del a˜no 2000 [1]. Los test escogidos para la realizaci´on del proyecto son los test NAS, cuyas caracter´ısticas resumimos en el apartado 2.4.4. Por ejemplo se usar´a un algoritmo para buscar la soluci´on de diferencias finitas a ecua- ciones de Navier-Stokes, que consisten en un conjunto de ecuaciones no lineales en derivadas parciales que describen el movimiento de un flui- do. Los dem´as tests tratan de resolver el mismo problema empleando diversos m´etodos matem´aticos [18]. La complejidad de c´alculo de los tests hace que provoquen una gran carga de procesamiento del sistema y una baja carga de entrada/salida, mejorando el m´etodo de medici´on de la mejora obtenida. Esta es la raz´on del descarte de los test SPEC como m´etodo de valoraci´on, ya que, a pesar de los buenos resultados obtenidos en experiencias previas, tienen una excesiva cantidad de entrada/salida. 2.6. Recursos para el Desarrollo A continuaci´on se comentar´an los recursos necesarios para el desarrollo del proyecto. Estos recursos vendr´an diferenciados en funci´on de su condi- ci´on, es decir, recursos humanos, hardware y software. 2.6.1. Recursos Humanos Los recursos humanos a la hora de desarrollar el proyecto son:
    • 24 2.6. Recursos para el Desarrollo Recursos humanos internos: Directores Prof. D. Ezequiel Herruzo G´omez y Prof. Dr. Jos´e Igna- cio Benavides Ben´ıtez, directores, asesoradores y supervisores del desarrollo del proyecto. Autor Fernando Garc´ıa Aranda. Encargado del an´alisis y soluci´on del problema, t´ecnicas de mejora, testeo y documentaci´on de la misma. Recursos humanos externos: Pedro Navajas Modelo Autor de Karma Linux. Lista de correo de RTAI Fundamental a la hora de examinar los puntos a modificar del programa para permitir la selecci´on de procesadores del multiprocesador que se desean utilizar en la eje- cuci´on exclusiva del programa. Lista de correo de PAPI Necesaria a la hora de conseguir que la soluci´on final se adapte a la medici´on de eventos en el m´aximo n´umero de procesadores (modelos) posibles. 2.6.2. Recursos Hardware Los recursos hardware a la hora de realizar el proyecto ser´an: Ordenador PC con procesador Intel Core 2 Duo (T7200), 2GHz, 4MB de memoria cach´e, 1GB de memoria RAM y 120GB de disco duro. Ser´a el utilizado para trabajar con multiprocesador, en este caso mul- ticore. Ordenador PC con procesador AMD Athlon XP 2.6Ghz, 512KB de memoria cach´e, 512MB de memoria RAM y 120GB de disco duro. Utilizado para trabajar en monoprocesador. 2.6.3. Recursos Software Los recursos software ser´an: Debian GNU/Linux: distribuci´on de GNU/Linux bajo la que se reali- zar´a el desarrollo de la soluci´on y que servir´a de base para la imple- mentaci´on final de la misma (Live CD).
    • Definici´on del Problema 25 Int´erprete de Python 2.4: para la ejecuci´on de la interfaz gr´afica de usuario. Biblioteca WxPython 2.8: binding de la biblioteca gr´afica wxWidgets (escrita en C++) para el lenguaje de programaci´on Python. Necesaria para la implementaci´on de la interfaz gr´afica de usuario. Live-helper: conjunto de paquetes para la creaci´on de Live CDs bajo Debian testing y unstable. Autotools: Herramientas para la creaci´on de proyectos de software libre que permite la generaci´on autom´atica de Makefiles adaptados a cada sistema, generaci´on y mantenimiento de traducciones, an´alisis de dependencias, etc. Colecci´on de Compiladores de GNU (GCC): Compiladores de C y For- tran empleados para compilar y enlazar el c´odigo fuente del medidor de eventos y las pruebas de testeo. Kernel de Linux: fuentes originales del kernel (vanilla sources) donde aplicaremos los parches necesarios, versi´on 2.6.22.15. Editores de textos Vim y Gedit, para la codificaci´on del proyecto y la documentaci´on del mismo. Kile: IDE7 de LATEX. DIA: programa para la realizaci´on de diagramas, procedimientos y gr´aficos de todo tipo necesarios para la documentaci´on del proyecto. Doxygen: generador de documentaci´on multilenguaje para el manual de c´odigo. Evince: programa para la visualizaci´on de documentos pdf y ps. Navegador web Iceweasel y cliente de correo Icedove (basados en las herramientas de Mozila Firefox y Thunderbird respectivamente, in- cluidos en Debian GNU/Linux). 2.7. Recursos para la Ejecuci´on A continuaci´on se comentar´an los recursos necesarios para la ejecuci´on del proyecto. 7 Integrated Development Environment, Entorno de Desarrollo Integrado.
    • 26 2.7. Recursos para la Ejecuci´on 2.7.1. Recursos Humanos Cualquier persona puede insertar el Live CD en su m´aquina e iniciar el sistema con las herramientas necesarias para realizar las mediciones. Este CD configurar´a el sistema y preparar´a todo lo necesario para que el usuario pueda realizar la labor sin necesidad de configurar nada. 2.7.2. Recursos Hardware Cualquier ordenador con arquitectura x86 o x86 64 y lector de DVD es suficiente para realizar las mediciones. 2.7.3. Recursos Software No es necesario ning´un recurso software, ya que el Live CD provee todos los recursos necesarios para crear un entorno de ejecuci´on id´oneo.
    • Cap´ıtulo 3 An´alisis del Sistema Si en cap´ıtulo anterior se ofreci´o una visi´on global del problema a resol- ver, describiendo as´ı la aplicaci´on a desarrollar, ahora es el momento de la especificaci´on t´ecnica de los requisitos de la aplicaci´on. Para describir la aplicaci´on glperfex, interfaz sencilla a lperfex utilizare- mos el Lenguaje Unificado de Modelado (UML) a trav´es de diagramas de casos de uso y clases, para el modelado est´atico, y diagramas secuencia, para el modelado din´amico. Por otro lado estableceremos los requisitos y espe- cificaciones del resto de los elementos que componen el sistema, adem´as de describir c´omo se alamacenar´a la informaci´on manejada. 3.1. Identificaci´on de Requisitos El proyecto trata de realizar un entorno sencillo y determinista de me- dici´on de eventos de procesador sobre programas ejecutables. A continuaci´on se presenta una lista general de requisitos del sistema, dada por los objetivos que enumeramos durante la etapa de definici´on del problema. Mejorar la precisi´on de las mediciones Esta propuesta requiere prue- bas en diversos entornos para solventar los aspectos del problema, por lo que es dif´ıcil estimar la duraci´on de la misma. Usar un entorno en tiempo real bajo Linux Ofrece las ventajas de un planificador en tiempo real junto a la posibilidad de uso de un sistema operativo libre, que asegure una mayor configurabilidad del mismo y un mayor aprendizaje de los aspectos internos del mismo. 27
    • 28 3.2. Modelado Est´atico Uso de herramientas libres La idea es aprovechar y contribuir en el tra- bajo de una comunidad incalculable de desarrolladores de software que nos brindan la oportunidad de utilizar, mejorar y modificar excelentes productos integr´andolos as´ı en nuestro sistema. Por ello es fundamen- tal la publicaci´on de las modificaciones que realicemos para que puedan ser aprovechadas por el resto de la sociedad ya que esta filosof´ıa es sin duda un paso adelante y una gran contribuci´on al avance tecnol´ogico. Interfaz gr´afica sencilla para la realizaci´on de las mediciones Implica el dise˜no de una interfaz gr´afica simple, completa e intuitiva que permita al usuario poco experimentado aprovechar las funcionali- dades de la aplicaci´on, de manera que pueda utilizare para multitud de ´ambitos de aplicaci´on. Adaptaci´on a Multiprocesador Hace necesario el estudio y aplicaci´on de una soluci´on para la distribuci´on del proceso a ejecutar en modo exclusivo por el planificador en tiempo real. Obtenci´on de Informaci´on sobre la m´aquina en tiempo de ejecuci´on Existe informaci´on vital para lograr una muestra v´alida de acuerdo con las caracter´ısticas del modelo de procesador sobre el que se ejecuta la aplicaci´on. Por ello el sistema debe ser capaz de obtener datos tan importantes como el n´umero de procesadores y los contadores hardware con los que cuenta la m´aquina. Entorno propio sin necesidad de configuraci´on Como consecuencia del punto anterior se debe de contar con un entorno configurado ade- cuadamente para realizar las mediciones sin que el usuario realice ins- talaciones extra y que detecte los elementos y configure el equipo de acuerdo con sus caracter´ısticas. 3.2. Modelado Est´atico Mediante el modelado est´atico se pretende establecer de un modo for- mal el comportamiento del sistema a trav´es de uso del Lenguaje Unificado de Modelado (UML). Para ello examinaremos tanto los casos de uso de la aplicaci´on, a trav´es de sus diagramas de casos de uso, como las clases invo- lucradas y sus relaciones, a trav´es su diagrama de clases. La visi´on que realizaremos se basar´a exclusivamente en la interfaz gl- perfex (describiremos la relaci´on de esta interfaz con lperfex en el modelado din´amico), ya que las especificaciones y requisitos del resto del sistema ser´an descritos en el apartado 3.6.
    • An´alisis del Sistema 29 3.2.1. Casos de Uso 3.2.1.1. Identificaci´on de los Actores El ´unico actor implicado es el usuario final. Esto se debe al cumplimiento de la premisa de funcionamiento aut´onomo del sistema, de manera que no exista la necesidad de implicar a ning´un administrador que realice configu- raciones o mantenimiento del mismo. Podemos catalogar a los usuarios entre los siguientes tipos: Investigadores y Desarrolladores Utilizan la aplicaci´on para realizar benchmarkings midiendo as´ı la optimizaci´on de un algoritmo (obser- vando las mejoras a realizar o los ´exitos de las mismas) evaluando para ello todos los eventos que la arquitectura permite medir. Docentes y Alumnos Pueden necesitar la aplicaci´on para la demostra- ci´on y validaci´on de teor´ıas a trav´es de una serie de pruebas de las mismas. Tambi´en puede utilizarse la aplicaci´on para la comprensi´on del funcionamiento interno de un procesador (en este caso deber´a li- mitarse a procesadores de las arquitecturas x86 y x86 64). 3.2.1.2. Diagrama de Casos de Uso En la Figura 3.1 podemos observar los casos de uso de nuestro sistema. Figura 3.1: Diagrama de Casos de Uso
    • 30 3.2. Modelado Est´atico 3.2.1.3. Especificaci´on de los Casos de Uso A continuaci´on especificaremos de modo formal cada uno de los casos que se han identificado a la hora de realizar el diagrama. Dado que UML no propone ning´un modelo de plantilla para definir los casos de uso, establece- remos una plantilla b´asica para especificar cada caso en el proceso. UC#id: Nombre del Caso de Uso Descripci´on breve del caso de los ob- jetivos del caso de uso. 1. Actores: Actores que intervienen en el caso de uso. 2. Precondiciones: Conjunto de condiciones que deben cumplirse para que el caso de uso se realice de forma correcta. 3. Flujo Principal: Secuencia de pasos necesarios que se deben seguir para la correcta realizaci´on del caso de uso. 4. Postcondiciones: Conjunto de condiciones que se cumplen cuando se ejecutan los pasos del flujo principal. 5. Flujo alternativo: Opciones del flujo alternativo en caso de no ejecutarse el flujo principal. Cuadro 3.1: Plantilla para la Definici´on de Casos de Uso Una vez definida la plantilla a emplear para el detallado de los casos de uso podemos realizar el proceso con los casos identificados. UC1: Generar Medici´on El usuario desea realizar una medici´on sobre una serie de contadores hardware de un programa ejecutable. 1. Actores: Usuario 2. Precondiciones: No existen precondiciones porque contamos con un sistema aut´onomo que ha detectado los elementos de la m´aquina y que contiene todo lo necesario para realizar la medi- ci´on. 3. Flujo Principal: Para realizar la medici´on de forma correcta el usuario deber´a actuar de acuerdo con los pasos que se siguen en el caso de uso UC5 (Punto de Inclusi´on). 4. Postcondiciones: Se generan una serie de estad´ısticas que refle- jan los valores de medici´on que se pidieron en la configuraci´on de la misma. 5. Flujo alternativo: Existen dos flujos alternativos que pueden operar con los datos obtenidos a partir de la medici´on generada.
    • An´alisis del Sistema 31 Se podr´an guardar los resultados de la medici´on (Punto de Extensi´on: Guardar Resultados). En este caso el usuario sim- plemente tendr´a que dar la ruta donde desea almacenar el fichero y se generar´a el mismo. Se podr´a guardar la gr´afica de la medici´on en caso de ha- ber sido generada (Punto de Extensi´on: Guardar Gr´afica). El usuario indicar´a la ruta y el tipo de imagen (formato a elegir entre una serie de formatos soportados) que desee ge- nerar para su posterior visualizaci´on. UC2: Cargar Medici´on El usuario dispone de datos extra´ıdos de medi- ciones anteriores y desea cargarlos en la aplicaci´on para examinarlos. 1. Actores: Usuario 2. Precondiciones: Existe la precondici´on de disponer de unos re- sultados guardados en el formato apropiado. 3. Flujo Principal: El usuario selecciona el fichero de resultados deseados. 4. Postcondiciones: Se publican las estad´ısticas que reflejan los valores de medici´on guardados en el fichero. 5. Flujo alternativo: - UC3: Configurar Medici´on El usuario necesita configurar la medici´on a realizar para poder generar los resultados deseados, por lo tanto se trata de un caso de inclusi´on. 1. Actores: Usuario 2. Precondiciones: - 3. Flujo Principal: El usuario debe seleccionar medici´on normal dentro de las opciones de configuraci´on. Tambi´en establecer´a el n´umero de ejecuciones que se realizar´an en las pruebas, el bina- rio a ejecutar (programa que se desea probar en el sistema) y seleccionar´a los eventos hardware que desea medir. 4. Postcondiciones: Una vez realizada la configuraci´on, se puede obtener la medici´on y enviar la consulta (haciendo una analog´ıa a las bases de datos) a lperfex para que realice la medici´on. 5. Flujo alternativo: El sistema permite realizar otro tipo de me- dici´on aparte de la est´andar y es la medici´on exclusiva (Punto de Extensi´on: Medici´on Exclusiva) que se describe en el UC4. UC4: Medici´on Exclusiva El usuario puede desear una medici´on distinta de la est´andar o normal, de acuerdo con el requisito de inclusi´on de un planificador en tiempo real.
    • 32 3.2. Modelado Est´atico 1. Actores: Usuario 2. Precondiciones: - 3. Flujo Principal: El usuario debe seleccionar medici´on exclusi- va dentro de las opciones de configuraci´on. Como caracter´ıstica fundamental de la medici´on exclusiva es que permite seleccionar el procesador o procesadores donde se desea lanzar la aplicaci´on a probar. M´as all´a de eso se realizar´an la configuraci´on de ele- mentos comunes, n´umero de ejecuciones que se realizar´an en las pruebas... 4. Postcondiciones: Igual que las establecidas en el caso base de configuraci´on de la medici´on, lperfex se encargar´a de realizar la medici´on exclusiva. 5. Flujo alternativo: - 3.2.2. An´alisis de Clases del Sistema En esta etapa del modelado est´atico se determinar´an las clases que apa- recer´an en el sistema. Se trata de una descripci´on breve sin llegar a un grado de explicaci´on que se obtendr´a en etapas siguientes del desarrollo del proyecto. 3.2.2.1. Diagrama de Clases En la Figura 3.2 podemos observar el diagrama de clases de glperfex, donde identificamos las siete clases distintas que lo componen. Figura 3.2: Diagrama de Clases
    • An´alisis del Sistema 33 3.2.2.2. Descripci´on de las Clases A continuaci´on describimos la clases indicadas en el diagrama: MainFrame Es la clase encargada de mostrar la ventana principal de glper- fex. Dentro de ella se encuentra el notebook que albergar´a los paneles que se describir´an a continuaci´on y se dirigen las operaciones de ge- neraci´on de mediciones, adem´as de dar la opci´on de almacenar dichos resultados, su gr´afica, en caso de haberse generado, y cargar resultados de mediciones anteriores. Tambi´en albergar´a las acciones para abrir la ayuda. Configuration Esta clase alberga el panel encargado de la configuraci´on de la ejecuci´on del programa. Est´a situada por encima de la clase de entrada y salida, y requiere de ella para tener acceso y contacto con el programa lperfex. Dentro de ella se realiza la configuraci´on del n´umero de ejecuciones, n´umero de procesadores a elegir, y se elige entre el caso base de prueba (medici´on est´andar) o el caso de medici´on exclusiva. Counters Clase correspondiente al panel encargado de la configuraci´on de los contadores elegidos para la medici´on, utiliza la clase de entrada y salida, situ´andose por encima de ´esta en nivel de abstracci´on de forma que obtiene los contadores propios del sistema que proporciona lperfex. Gestionar´a como como vemos a continuaci´on la clase CheckListCtrl para mostrar y operar con los contadores. CheckListCtrl Clase correspondiente simplemente al panel donde se es- cribir´an y seleccionar´an los contadores hardware de la m´aquina bajo el mando de la clase Counters. Results De la misma manera que las dos clases anteriores, esta clase corres- ponde a un panel, en este caso al encargado de mostrar los resultados de las estad´ısticas as´ı como la gr´afica de los mismos (siempre se mos- trar´a en caso de existir m´as de dos resultados de una prueba, una gr´afica con un ´unico punto no tendr´ıa sentido), para mostrar los resul- tados se har´a uso de la clase ResultsPanel. Para recoger los resultados tras la ejecuci´on se comportar´a en interacci´on de manera an´aloga a las clases anteriores con la clase IOInterface. ResultsPanel Es una clase utilizada por Results simplemente como panel de muestra de resultados. IOInterface Clase encargada de interaccionar con el programa lperfex, la idea inicial es que se comporte como una capa a parte, de manera que sea cual sea la forma elegida de interaccionar con lperfex, el resto de
    • 34 3.3. Modelado Din´amico comunicaci´on con las clases no se vea modificada. Al ser una capa de abstracci´on menor, y por propia usabilidad, las clases Configuration, Counters y Results heredar´an de ella. 3.3. Modelado Din´amico En esta fase de la especificaci´on se proceder´a a describir c´omo interact´uan entre s´ı los objetos presentes en la aplicaci´on, modificando el estado de este a lo largo del tiempo. Para ello, siguiendo el modelo de UML, se emplear´an diagramas de secuencia. Esto nos servir´a para realizar la fase de dise˜no de datos. 3.3.1. Diagramas de Secuencia Los diagramas de secuencia describen la colaboraci´on entre los objetos que componen el sistema. Se tratan de una serie de diagramas de interacci´on que detallan las operaciones que se llevan a cabo, qu´e mensajes son enviados y cu´ando. El tiempo comienza en el eje y del sistema de coordenadas car- tesiano, de forma que los eventos que ocurran en las partes inferiores ser´an los que hayan ocurrido con mayor tiempo transcurrido. De forma an´aloga objetos se situar´an conforme a su orden de participaci´on en el eje x. Estableceremos un diagrama de secuencia para los casos fundamentales de uso. Sin embargo, y por la simpleza y m´ınima variaci´on que suponen, tal y como describiremos posteriormente, resumiremos los casos de uso en dos ´unicos diagramas de secuencia. 3.3.1.1. Generar Medici´on El caso de uso Generar Medici´on (UC1), Figura 3.1, es el principal de nuestra aplicaci´on. El usuario pide al programa (aplicando una serie de confi- guraciones) que muestre por pantalla los resultados deseados. Exist´ıan tam- bi´en dos posibilidades a˜nadidas a este caso, la posibilidad de guardar los resultados de la ejecuci´on en un fichero, y la posibilidad de guardar una gr´afica con los resultados en caso de que esta hubiera sido generada (en caso de haber existido m´as de una ejecuci´on, para visualizar gr´aficamente c´omo ´esta se ajustaba a la media). La Figura 3.3 presenta el diagrama de secuencia del caso de uso Generar Medici´on, a˜nadiendo al final del mismo la operaci´on Guardar Resultados como muestra completa de las posibilidades que el programa si atacamos su
    • An´alisis del Sistema 35 funcionalidad por este sentido. Podr´ıamos haber a˜nadido tambi´en al final (a la altura de Guardar Resultados, la posibilidad de Guardar la gr´afica) sin embargo se trata de un proceso an´alogo y no se considera necesario redundar en la explicaci´on. Figura 3.3: Diagrama de Secuencia: Generar Medici´on A continuaci´on realizaremos una descripci´on paso a paso del diagrama: 1. El usuario, que tiene a su disposici´on la interfaz gr´afica (GUI) glperfex abierta se encuentra con la opci´on de configurar la ejecuci´on. Este caso de uso ten´ıa, como vimos en la secci´on 3.2.1.3, un caso especial
    • 36 3.3. Modelado Din´amico de ejecuci´on exclusiva, hemos determinado no obstante que tendr´an que aparecer todas las opciones en el mismo espacio en la ventana, adelant´andonos de este modo un poco a la especificaci´on de la interfaz, por lo que no ser´a necesaria la descripci´on, o especificaci´on de una comunicaci´on extra para las comunicaciones del usuario a la GUI. 2. El usuario necesita ahora elegir los contadores para completar la con- figuraci´on de la ejecuci´on, por ello pide a la interfaz que muestre los contadores disponibles por el sistema. En este caso podr´ıamos haber especificado el proceso que realiza la GUI a trav´es de la Interfaz de I/O para obtener esos datos de lperfex, sin embargo este proceso se realiza al iniciar la ejecuci´on de glperfex y no con la intervenci´on del usuario, por lo que se situar´ıa al principio. No obstante, se trata proce- so an´alogo al de obtenci´on de resultados, y, por supuesto, ser´a tomado en cuenta a la hora de codificar. 3. Una vez la interfaz detecta la petici´on de muestra del panel de conta- dores, la GUI muestra al usuario los contadores obtenidos (generado tal y como se coment´o en el punto 2). 4. El usuario realiza la selecci´on deseada entre los contadores que le mues- tra la GUI. 5. Una vez se han reunido los datos necesarios para generar una medici´on, el usuario puede pedir a la aplicaci´on que se genere la medici´on de su programa. 6. La GUI recopila internamente los datos que el usuario ha dado como entrada. 7. La GUI env´ıa la informaci´on recopilada para la ejecuci´on y medici´on a la Interfaz de Entrada/Salida. 8. La Interfaz de Entrada/Salida se encarga de reunir la informaci´on en una consulta v´alida para lperfex, siguiendo las especificaciones de la misma. 9. La Interfaz de I/O ejecuta lperfex con las caracter´ısticas requeridas. 10. lperfex realiza las mediciones correspondientes. 11. Una vez realizadas las mediciones, lperfex da sus resultados y la Inter- faz de I/O los recoge. 12. La Interfaz de I/O da formato a los resultados obtenidos de la ejecuci´on de lperfex. 13. Una vez reunidos los datos de la ejecuci´on y guardados en las estruc- turas requeridas por la GUI para manejarlos se mandan a la misma.
    • An´alisis del Sistema 37 14. La GUI rellena los paneles de resultados (y la gr´afica en caso de ser necesario hacerlo) de acuerdo con los datos recibidos en las estructuras correctas. 15. El usuario puede disfrutar ahora de los resultados de la ejecuci´on or- denada. En este caso el usuario podr´ıa contentarse con la ejecuci´on dada, pero existe una posibilidad m´as detallada en el diagrama que podr´ıa realizar (en realidad tal y como comentamos en la introducci´on a la descripci´on son dos an´alogas), la opci´on de guardar los resultados, puntos 16, 17, 18, 19, 20 y 21. 16. El usuario pide a la GUI guardar los resultados. 17. La GUI necesita el nombre del fichero donde se desea guardar y su ruta para transmitirlo, por ello lo solicita al usuario. 18. El usuario especifica a la GUI el nombre del fichero a ejecutar. 19. La GUI ejecuta la opci´on de guardar resultados de la Interfaz de I/O, que comunicar´a con el sistema para realizar la operaci´on. 20. La Interfaz de I/O env´ıa la confirmaci´on de escritura del fichero. 21. La GUI notifica al usuario la confirmaci´on de escritura. 3.3.1.2. Cargar Medici´on El caso de uso Cargar Medici´on nos da la oportunidad de mostrar los resultados almacenados tras alguna medici´on por pantalla. De esta manera en la Figura 3.4 se muestra el diagrama de secuencia correspondiente al caso de uso. A continuaci´on realizaremos una descripci´on paso a paso del diagrama: 1. El usuario selecciona la opci´on de cargar medici´on en la interfaz gr´afica (GUI). 2. La GUI pide al usuario el nombre y la ruta del fichero que desea cargar. 3. El usuario escribe el nombre del fichero y la ruta en la GUI. 4. La GUI da la instrucci´on a la Interfaz de Entrada/Salida para abrir el fichero deseado.
    • 38 3.4. Descripci´on de la Informaci´on Figura 3.4: Diagrama de Secuencia: Cargar Medici´on 5. La Interfaz de I/O obtiene el fichero a trav´es de una llamada al sistema y una vez abierto, almacena los datos en las estructuras requeridas por la GUI para el manejo de los datos. 6. La Interfaz de I/O env´ıa los datos formateados a GUI. 7. La GUI rellena con los datos correspondientes los paneles de resulta- dos. 8. La GUI muestra los resultados una vez rellenos los paneles (con gr´afica en caso de haberse generado). 3.4. Descripci´on de la Informaci´on Antes de realizar un enfoque a la especificaci´on de la interfaz y a la des- cripci´on del resto de componentes del sistema es importante tener en cuenta la informaci´on manipulada por la aplicaci´on. En concreto nos centraremos en la descripci´on de la informaci´on almacenada y manipulada en los casos de uso Cargar Medici´on y en el caso especial al generar medici´on, Guardar Resultados. Una de las necesidades que ya hemos comentado en los objetivos y en la especificaci´on de requisitos de nuestro sistema es la de guardar los datos
    • An´alisis del Sistema 39 de las mediciones. Si estamos inmersos en un proceso de evaluaci´on del funcionamiento de una aplicaci´on, ser´a capital comparar los resultados de las diferentes mediciones que vayamos obteniendo. La manera m´as ´util de almacenar estos resultados ser´ıa hacerlo en un for- mato entendible por programas de oficina como hojas de c´alculo, de forma que no s´olo pudieran ser visualizados en nuestro sistema, sino que pudie- ran ser manipulados externamente y tratados con una gran facilidad. Otra posibilidad ser´ıa almacenar los resultados en una base de datos. Sin embar- go, incurrir´ıamos en el supuesto que acabamos de negar, los resultados s´olo ser´ıan accesibles a trav´es de nuestro programa o mediante consultas SQL, lo que dificultar´ıa en gran manera el acceso y manipulaci´on posterior de los mismos. Con estas premisas, y tras una breve investigaci´on se ha escogido la opci´on de guardar las estad´ısticas en un formato especial llamado comma- separated values (CSV). 3.4.1. El Formato CSV Los ficheros CSV son un tipo de documento sencillo para representar datos en forma de tabla. En ellas las columnas se separan por comas (o punto y coma, dependiendo del estilo que escogido para la separaci´on decimal) y las filas por saltos de l´ınea. Los campos que contengan una coma, un salto de l´ınea o una comilla doble deben ser encerrados entre comillas dobles. El formato CSV es muy sencillo y no indica un juego de caracteres con- creto, ni c´omo van situados los bytes, ni el formato para el salto de l´ınea. Estos puntos deben indicarse muchas veces al abrir el fichero, por ejemplo, con una hoja de c´alculo [22]. La principal ventaja de CSV, adem´as de la especificaci´on sencilla1 y so- portada por multitud de lenguajes de programaci´on, es que las principales herramientas de hojas de c´alculo del mercado son capaces de leer y operar con dicho formato (OpenOffice.org Calc y Excel de Microsoft Office entre ellas). De esta manera el usuario de nuestra aplicaci´on podr´a tratar los resul- tados en hojas de c´alculo facilitando la labor de documentaci´on y evaluaci´on de las pruebas. 1 Probablemente no exista ninguna especificaci´on m´as sencilla que la de CSV. No obs- tante, hay que matizar que no existe una especificaci´on formal para los ficheros CSV. Las ´unicas directrices fueron dadas en el documento RFC 4180 [23] que describe un formato com´un y establece el tipo MIME “text/csv”, registrado por la Internet Assigned Numbers Authority (IANA). Otra especificaci´on importante es la provista por el est´andar Fielded Text [24] que cubre en un apartado el formato CSV. Se pueden encontrar m´as referencias a la especificaci´on en [25] y [26].
    • 40 3.4. Descripci´on de la Informaci´on Contador,Resultado,Tiempo,Tiempo Sys NOMBRECONTADOR0,RESULTADO,TIEMPO,TIEMPOSYS NOMBRECONTADOR1,RESULTADO,TIEMPO,TIEMPOSYS NOMBRECONTADOR2,RESULTADO,TIEMPO,TIEMPOSYS NOMBRECONTADOR3,RESULTADO,TIEMPO,TIEMPOSYS ..... Cuadro 3.2: Ejemplo de Fichero CSV resultado de una medici´on Contador,Resultado medio,Desviaci´on,Tiempo,Tiempo Sys,N. Ejecuciones NOMBRECONTADOR0,RESULTADOMEDIO,DESVIACI´ON,T,T_SYS,3 N. Ejecuci´on,Resultado 1, Valor1 2, Valor2 3, Valor3 NOMBRECONTADOR1,RESULTADOMEDIO,DESVIACI´ON,T,T_SYS,3 N. Ejecuci´on,Resultado 1, Valor1 2, Valor2 3, Valor3 .... Cuadro 3.3: Ejemplo de Fichero CSV resultado de tres mediciones 3.4.2. Nuestro Uso de CSV Tal y como hemos visto en la descripci´on de CSV el formato almacena los datos en columnas separadas por comas y filas establecidas como saltos de l´ınea. De esta manera, el objetivo es escribir en el fichero la informaci´on tabulada que aparecer´a en los paneles de resultados que coment´abamos en los diagramas de secuencia. Establecemos dos modelos de registro de datos, la clasificaci´on viene dada por el n´umero de ejecuciones que ha ordenado el usuario de cada contador. El Cuadro 3.2 muestra el modelo fichero en caso de prueba de una ´unica medici´on de varios contadores, mientras que el Cuadro 3.3 muestra el fichero en caso de tres ejecuciones de varios contadores. La presentaci´on de estos dos ficheros CSV en OpenOffice.org Calc resul- tar´a tal y como podemos observar en las Figuras 3.5 y 3.6 f´acil de tratar por
    • An´alisis del Sistema 41 el usuario final y asegurar´a que el Caso de Uso de almacenaje de los datos sea totalmente funcional una vez escrito el fichero. Figura 3.5: Ejemplo de Fichero CSV: Una medici´on 3.5. Requisitos de la Interfaz Una vez conocidas las restricciones propuestas a la interfaz, as´ı como los casos de uso principales, es hora de dar la primera aproximaci´on a las normas que deber´a obtener la interfaz final. Nuestro sistema de medici´on tiene dos interfaces fundamentales, La interfaz proporcionada por Karma Linux original, es decir, uso de lperfex mediante la interacci´on con a trav´es del est´andar getopts con la terminal y el programa documentada en [1]. La interfaz de Karma Linux 2008, glperfex, en modo gr´afico con el objetivo de cumplir su funci´on de manera sencilla y ´agil para el usuario. En este apartado describiremos la segunda interfaz al tratarse de la pro- pia de nuestro proyecto, y de una de los objetivos fundamentales de Karma Linux 2008. Las normas o requisitos de glperfex son los siguientes:
    • 42 3.5. Requisitos de la Interfaz Figura 3.6: Ejemplo de Fichero CSV: Tres mediciones La interfaz debe permitir la configuraci´on de la clase de ejecuci´on (est´andar o exclusiva), un n´umero de ejecuciones dado por el usuario, as´ı como el n´umero de procesadores donde se ejecutar´a la aplicaci´on en caso de producirse una medici´on exclusiva. Debe permitir la carga de uno o m´as eventos de procesador para su medici´on, por lo que estos eventos deber´an estar disponibles con una descripci´on de los mismos de manera que el usuario pueda configurarlos de forma correcta. La interfaz deber´a publicar los resultados de una forma entendible para el usuario. En caso de producirse la medici´on de un evento en m´as de una ocasi´on, se deber´a generar una gr´afica con los resultados sobre un eje cartesiano de manera que se pueda ver la variaci´on con respecto de la media de los mismos. Deber´a ofrecer la posibilidad de guardar los resultados generados en un fichero, as´ı como la gr´afica en caso de haber sido generada. Deber´a ofrecer la posibilidad de cargar resultados generados en medi- ciones anteriores en el sistema. En caso de necesitarla el usuario podr´a consultar una opci´on de ayuda donde aclarar las mismas.
    • An´alisis del Sistema 43 La interfaz deber´a emitir mensajes de error cuando falten datos por introducir y/o estos datos sean err´oneos de la forma m´as sencilla po- sible. 3.6. Descripci´on y Especificaciones del Resto del Sistema En las secciones anteriores hemos realizado el an´alisis de la aplicaci´on glperfex que con el uso conjunto de lperfex utilizaremos para realizar las mediciones y obtener los resultados de las mismas tanto de forma exclusiva como mediante el uso del planificador est´andar del kernel de Linux. Una vez definidas las especificaciones de la aplicaci´on debemos extender este an´alisis al contexto en el que se encuentra la aplicaci´on, por lo que en esta secci´on nos encargaremos de analizar todos los objetos del dominio as´ı como sus requisitos funcionales y no funcionales. 3.6.1. Planificaci´on de Procesos Los sistemas operativos multitarea se dividen en dos tipos, los sistemas operativos multitarea cooperativa y los de multitarea de reemplazo [2]. Multitarea Cooperativa En estos sistemas un proceso no deja de ejecu- tarse hasta que ´el mismo as´ı lo decida, el acto de suspensi´on voluntaria de la ejecuci´on es llamado yielding o cesi´on. Debido a esto, el proce- sador no puede tomar decisiones globales sobre qu´e proceso ejecutar, los procesos pueden monopolizar el procesador durante un periodo de tiempo muy largo y se corre el riesgo de que dichos procesos no cedan jam´as uso del procesador. Uno de los escasos ejemplos de sistemas ope- rativos multitarea cooperativa es el MacOS 9 y versiones anteriores. Multitarea de Reemplazo Al contrario que en los sistemas multitarea cooperativa aqu´ı es el planificador el que decide cu´ando un proceso debe cesar su ejecuci´on y cu´ando un proceso debe continuarla. El acto de suspender una tarea en ejecuci´on es llamado preempt o reemplazo. El tiempo que un proceso ejecuta antes de su reemplazo es determina- do con anterioridad, aunque puede variar en caso de imprevistos. Este periodo de ejecuci´on antes de su reemplazo es llamado cuanto y var´ıa para cada sistema operativo y cada tarea. Unix posee multitarea de reemplazo desde el comienzo y por tanto Linux tambi´en, al igual que la mayor´ıa de sistemas operativos modernos. En Linux el cuanto de
    • 44 3.6. Descripci´on y Especificaciones del Resto del Sistema tiempo de ejecuci´on es calculado din´amicamente permitiendo al plani- ficador tomar decisiones globales sobre el sistema. Esta naturaleza de reemplazo y divisi´on en cuantos, previene que un proceso monopolice la CPU. Como hemos podido ver, en Linux, una tarea no obtiene el control ab- soluto de la CPU de ninguna forma. En la rama 2.6 del kernel se han des- activado las llamadas sti() y cli(), restringiendo el acceso a la activaci´on y desactivaci´on de interrupciones, lo que obliga al programador a usar otras t´ecnicas para la sincronizaci´on de drivers. Esta restricci´on, que deja todo el control de los procesos al sistema operativo, tiene el objetivo de asegurar un sistema fiable con una mayor transparencia y mejor interacci´on con el usuario final. Un ejemplo de ello podemos encontrarlo en la forma de tratar los cuan- tos de tiempo en el planificador del kernel de Linux. Tal y como podemos observar en la Figura 3.7, el planificador asigna un cuanto de tiempo que var´ıa desde los 10 milisegundos hasta los 200 dependiendo de la prioridad de la tarea y de la interactividad que requiera, es decir, a mayor interactivi- dad, mayor ser´a el cuanto de tiempo, ya que es preferible que el usuario no permanezca a la espera eternamente. Figura 3.7: Cuantos de tiempo en el planificador de Linux Estas decisiones tomadas para mejorar la capacidad de interacci´on del sistema operativo son a su vez el principal problema a la hora de realizar las mediciones. Nuestra tarea es reemplazada por otra, pero sin embargo los contadores siguen midiendo de tal forma que incluso creando una serie de contadores virtuales que midan s´olo una tarea desactiv´andose al ser reem- plazada, los contadores medir´ıan el cambio de contexto, la llamada al nuevo proceso y en cada cuanto que vuelva a ocupar nuestro proceso el procesador, los contadores medir´ıan de nuevo su cambio de contexto, y lo que es m´as importante, el proceso cometer´ıa errores forzados en la memoria cach´e, que se traducir´ıan en una cantidad variable de ciclos de procesador adicional, m´as accesos a cach´e tanto de nivel 1 como de nivel 2, etc.
    • An´alisis del Sistema 45 3.6.2. Descripci´on de Componentes Una vez descrito el contexto bajo el que se coloca la aplicaci´on es el momento de describir los principales objetos que intervendr´an en nuestro entorno. Dado que glperfex es una interfaz para lperfex nos referiremos a partir de este punto a los objetos que intervienen en las mediciones realizadas por lperfex. En la Figura 3.8 podemos observar para introducirnos en el complejo sistema de dependencias que necesita lperfex para realizar su cometido, una vez visualizada la estructura introduciremos cada componente para poder especificar sin problemas los requisitos de los diferentes subsistemas. Figura 3.8: Estructura de Componentes de Karma GNU/Linux 3.6.2.1. Glibc Es la biblioteca est´andar de C en su sexta versi´on para pr´acticamente todo programa compilado en entornos Unix. Glibc divide los procesos en
    • 46 3.6. Descripci´on y Especificaciones del Resto del Sistema una serie de llamadas al sistema divididas en funciones y estructuras entre las que se encuentra una funci´on que se ejecuta en el contexto del proce- so como inicializaci´on del mismo, donde se pueden colocar constructores y otros elementos, y otra que se ejecutar´a al final del proceso pero dentro de su contexto, es decir, antes de que el proceso definitivamente muera. Gracias a esto, Glibc permite sustituir esas funciones para que un proceso determi- nado crea que lo que debe ejecutar es c´odigo que la aplicaci´on insert´o en su contexto para inicializar los contadores, ya que si los contadores son inicia- lizados fuera del contexto de una aplicaci´on, medir´an fuera de ella. 3.6.2.2. RTAI RTAI es una implementaci´on de Linux para tiempo real basada en RTLi- nux [30]. A˜nade un peque˜no kernel de tiempo real bajo el kernel est´andar de Linux y trata al kernel de Linux como una tarea con la menor prioridad. RTAI adem´as proporciona una amplia selecci´on de mecanismos de comuni- caci´on entre procesos y otros servicios de tiempo real. La Real-Time Application Interface act´ua como dominio de ADEOS. Co- mo vimos con anterioridad, ADEOS se coloca un nivel por encima del kernel del sistema operativo e intercepta sus interrupciones y llamadas a sistema con la finalidad de poder tomar decisiones sin ning´un tipo de restricci´on. Figura 3.9: Posicionamiento de ADEOS en el sistema operativo Arquitectura[28] RTAI trata el kernel est´andar de Linux como una tarea de tiempo real con la menor prioridad, lo que hace posible que se eje- cute cuando no haya ninguna tarea con mayor prioridad ejecut´andose.
    • An´alisis del Sistema 47 Las operaciones b´asicas de las tareas de tiempo real son implemen- tadas como m´odulos del kernel. RTAI maneja las interrupciones de perif´ericos y son atendidas por el kernel de Linux despu´es de las posi- bles acciones de tiempo real que hayan podido ser lanzadas por efecto de la interrupci´on. La Figura 3.10 muestra la arquitectura b´asica de RTAI. Las interrup- ciones se originan en el procesador y en los perif´ericos. Las originadas en el procesador (principalmente se˜nales de error como divisi´on por cero), son manejadas por el kernel est´andar, pero las interrupciones de los perif´ericos (como los relojes) son manejadas por RTAI Interrupt Dispatcher. RTAI env´ıa las interrupciones a los manejadores del ker- nel est´andar de Linux cuando no hay tareas de tiempo real activas. Las instrucciones de activar/desactivar las interrupciones del kernel est´andar son reemplazadas por macros que se enlazan con las instruc- ciones de RTAI. Cuando las interrupciones est´an desactivadas en el kernel est´andar, RTAI encola las interrupciones para ser repartidas despu´es de que el kernel est´andar haya activado las interrupciones de nuevo. Adicionalmente, se puede ver en la Figura 3.10 el mecanismo de co- municaci´on entre procesos (IPC), que est´a implementado de forma se- parado por Linux y por RTAI. Tambi´en existe un planificador distinto para Linux y para RTAI. HAL - Hardware Abstraction Layer[29] Los desarrolladores de RTAI introducen el concepto de Real Time Hardware Abstraction Layer (RTHAL) que es usado para inter- ceptar las interrupciones hardware y procesarlas despu´es. RTHAL es una estructura instalada en el kernel de Linux que re´une los punteros a los datos internos del hardware relacionados en el ker- nel y las funciones necesarias por RTAI para operar. El objetivo de RTHAL es minimizar el n´umero de cambios necesarios sobre el c´odigo del kernel y por tanto mejorar el mantenimiento de RTAI y del c´odigo del kernel de Linux. Con RTHAL, las diferentes ope- raciones (ej. manejar interrupciones) son m´as f´aciles de cambiar o modificar sin tener que interferir con la implementaci´on de Li- nux. Por ejemplo, la estructura de RTHAL contiene la tabla de manejadores de interrupci´on, la cual es un lista de las funciones que son llamadas para manejar las diferentes interrupciones. El cambio consiste ´unicamente en modificar unas 20 l´ıneas del c´odigo del kernel de Linux y a˜nadir unas 50 nuevas l´ıneas. Cuando RTHAL es instalado en Linux, las funciones y las estruc- turas de datos relacionadas con la interacci´on con el hardware son reemplazada por punteros a la estructura de RTHAL.
    • 48 3.6. Descripci´on y Especificaciones del Resto del Sistema Figura 3.10: Composici´on RTAI y Linux Planificaci´on La unidad de planificaci´on de RTAI es la tarea. Siempre hay al menos una tarea, llamada kernel de Linux, que ejecuta como la tarea de menor prioridad. Cuando las tareas de tiempo real son a˜nadidas, el planificador da entonces mayor prioridad a ´estas so- bre la tarea del kernel de Linux. El planificador proporciona servi- cios tales como suspend, resume, yield, make periodic o wait until, que son usadas en varios sistemas operativos de tiempo real. El planificador es implementado como un m´odulo del kernel dedi- cado lo que facilita la implementaci´on de planificadores alterna- tivos si es necesario. Actualmente hay tres tipos de planificadores dependiendo del tipo de m´aquina: • Uniprocesador (UP). • Multiprocesador sim´etrico (SMP). Est´a dise˜nado para m´aquinas SMP y proporciona un interfaz para las aplica- ciones de forma que es posible seleccionar el procesador o procesadores que deben ejecutar una tarea. Si el usuario no especifica un procesador para la tarea, SMP selecciona el pro- cesador en funci´on de la carga de trabajo. • Multi-Uniprocesador (MUP). Puede ser usado con ambos, pero al contrario que SMP, a las tareas se les debe especificar
    • An´alisis del Sistema 49 el procesador que deben usar. Vi´endolo por el lado positivo, el planificador MUP permite unos mecanismo de tiempo m´as flexibles para las tareas que los planificadores SMP ´o UP. Caracter´ısticas Con el objetivo de hacer el desarrollo de aplicaciones m´as f´aciles y flexibles posibles, los desarrolladores de RTAI han introduci- do diferentes mecanismos para la comunicaci´on entre procesos (IPC), entre las tareas de tiempo real y los procesos en el espacio de usua- rios. Como a˜nadido al mecanismo IPC, RTAI proporciona servicios de manejo de memoria y threads compatibles con POSIX. Comunicaci´on entre procesos (IPC - Inter-process comu- nication) RTAI proporciona una variedad de mecanismos para la comu- nicaci´on entre procesos. Aunque los sistemas Unix proporcionan mecanismos similares a IPC para los procesos en el espacio de usuario, RTAI necesita proporcionar una implementaci´on propia para que las tareas de tiempo real puedan usar este mecanismo y no usen el est´andar del kernel de Linux. Los diferentes meca- nismo de IPC est´an incluidos como m´odulos de kernel, lo que facilita la carga cuando son necesarios. Como ventaja adicional el uso de m´odulos para los servicios, IPC facilita el mantenimiento y la expansi´on. El antiguo mecanismo b´asico de comunicaci´on de RTAI eran los FIFOs. FIFO es un as´ıncrono y no bloqueante canal de comuni- caci´on entre los procesos de Linux y las tareas de tiempo real. RTAI puede lanzar se˜nales cuando hay eventos en el FIFO (es- critura de nuevos datos). Los procesos en el espacio de usuario pueden entonces crear un manejador para la se˜nal por los me- canismos est´andar de Unix. Sin embargo, este mecanismo no es necesario para los procesos de usuario que quieran leer o escribir del FIFO. Adicionalmente, puede haber m´ultiples lectores y es- critores en el FIFO. Adem´as, los identificadores FIFO pueden ser din´amicamente localizados con un nombre simb´olico. Los sem´aforos es otra herramienta b´asica de sincronizaci´on entre procesos usada en los sistemas operativos. RTAI proporciona un API para usar sem´aforos, aunque cada sem´aforo esta t´ecnicamen- te asociado a un FIFO, por tanto cada sem´aforo usa una entrada global del FIFO. Como a˜nadido al servicio b´asico de sem´aforos, un sem´aforo puede estar asociado con un reloj, el cual puede ser usado para despertar un proceso encolado en un sem´aforo, incluso cuando el sem´aforo a´un esta cerrado. La compartici´on de memoria proporciona una alternativa a IPC y al paradigma FIFO cuando un modelo de comunicaci´on dife-
    • 50 3.6. Descripci´on y Especificaciones del Resto del Sistema rente es requerido. La memoria compartida es un bloque com´un de memoria que puede ser le´ıdo o escrito por un proceso y una tarea en el sistema. Como los diferentes procesos pueden operar de forma as´ıncrona en la regi´on de memoria, es necesario un di- se˜no para asegurar que los datos no sean sobreescritos de forma intencionada. Finalmente, el m´etodo m´as flexible de IPC quiz´as sean los mailbo- xes. Cualquier n´umero de procesos pueden enviar y recibir men- saje de y desde un mailbox. Un mailbox almacena mensajes hasta un l´ımite que se defina, y contrario a los FIFOs, mailbox preserva los mensajes que est´an en el l´ımite. Puede haber un n´umero arbi- trario de mailboxes activos en el sistema simult´aneamente. RTAI tambi´en facilita la comunicaci´on entre procesos mediante RPC. Gesti´on de memoria En las primeras versiones de RTAI la memoria ten´ıa que ser asig- nada est´aticamente y no era posible la asignaci´on en tiempo real. Sin embargo en las actuales versiones se incluye un m´odulo gestor de memoria que permite la asignaci´on din´amica de memoria por parte de las tareas de tiempo real usando un interfaz basado en una biblioteca est´andar de C. RTAI preasigna trozos de memoria antes de la ejecuci´on de tiem- po real. Cuando la tarea de tiempo real llama a la funci´on rt_malloc(), la respuesta que obtiene es el trozo preasignado. Antes de que el espacio se agote, RTAI reserva nuevos trozos de memoria (preasigna) para futuras llamadas. De manera similar ocurre con la funci´on rt_free(), en este caso, se libera la memo- ria preasignada a la espera de futuras reservas. Cuando la suma de memoria liberada es mayor que un valor para una marca, se ordena su liberaci´on. Threads POSIX RTAI tiene m´odulos que proporcionan la implementaci´on de th- reads de acuerdo al est´andar POSIX 1003.1c. Usando las opera- ciones especificadas en el est´andar, el usuario puede manejar de manera similar a como lo hace con los threads POSIX convencio- nales, excepto en cuanto a los conceptos de joining y detaching. Los threads de un mismo proceso comparten el espacio de memo- ria, por tanto es f´acil el intercambio de informaci´on entre ellos, sin embargo, el uso de ´areas de memoria compartida son necesarias para la sincronizaci´on. Tambi´en se proporcionan los mecanismos de mutex y de variables de condici´on. LXRT: User-space Interface to RTAI LXRT es una API para RTAI que hace posible el desarrollo de aplicaciones de tiempo real en el espacio de usuario sin tener que
    • An´alisis del Sistema 51 crear m´odulos para el kernel. Esto es ´util en primer lugar porque el espacio de memoria destinado al kernel no est´a protegido de accesos inv´alidos, lo que puede provocar la corrupci´on de datos y el mal funcionamiento del kernel de Linux. En segundo lugar, si el kernel es actualizado, los m´odulos necesitan ser recompilados lo que puede provocar que sean incompatibles con la nueva versi´on. Mientras se desarrolla una aplicaci´on de tiempo real en el espacio de usuario el programador puede usar las herramientas est´andar de depuraci´on hasta que ya no contienen errores, pero en este caso se trata de procesos de tiempo real flexibles (soft). Adem´as, los servicios proporcionados por las llamadas al sistema de Li- nux est´an disponibles para las tareas. La ventaja de esto es que cuando la aplicaci´on est´e libre de errores puede convertirse a un m´odulo en el espacio del kernel, por lo que ya tendremos una tarea de tiempo real estricto. Sin embargo, al hacer esto, las lla- madas al sistema utilizadas no sirven y deber´an ser cambiadas por las proporcionadas por RTAI. El cambio de la aplicaci´on de procesos del espacio de usuario a tareas de tiempo real es f´acil porque LXRT proporciona una API sim´etrica para la comunicaci´on entre procesos y otros servicios de RTAI, lo que significa que la misma API puede ser usada por las tareas de tiempo real y por los procesos del espacio de usuario. La misma API de LXRT puede ser tambi´en usada cuando 2 procesos del espacio de usuario o 2 tareas de tiempo real se comunican entre si, esto implica que varios relojes y mensajes del sistema proporcionados por LXRT puedan ser usados incluso cuando la aplicaci´on no requiera tiempo real. LXRT permite a las aplicaciones el intercambio din´amico entre tiempo real flexible y estricto mediante el uso de una simple lla- mada en el espacio de usuario. Cuando una aplicaci´on est´a en el modo de tiempo real flexible, usa el planificador de Linux, pero requiere el uso de la pol´ıtica de planificaci´on FIFO. Sin embar- go la planificaci´on de procesos FIFO puede provocar la p´erdida de ranuras de tiempo por varias razones, por ejemplo, porque se est´a ejecutando un manejador de interrupciones o el planificador de tareas de RTAI. Con el objetivo de facilitar el paso a tiempo real estricto, LXRT crea un agente en el espacio del kernel para cada proceso del es- pacio de usuario con requerimientos de tiempo real. Cuando el proceso entra en modo de tiempo real estricto, el agente desac- tiva las interrupciones, y mueve al proceso fuera del planificador de Linux y lo a˜nade a la cola del planificador de RTAI. Ahora el proceso no es interrumpido por las interrupciones de otro proceso
    • 52 3.6. Descripci´on y Especificaciones del Resto del Sistema de Linux. Para poder realizar este cambio el proceso debe asegu- rar que la memoria usada por el proceso este en la memoria RAM y debe desactivar la paginaci´on usando la funci´on mlockall(). Esta llamada no debe ser usada en modo tiempo real estricto. Aunque los desarrolladores de RTAI ven bien el desarrollo de aplicaciones de tiempo real estricto usando LXRT, el tiempo de respuesta no es tan bueno como la ejecuci´on de las tareas como m´odulos del kernel. 3.6.2.3. PAPI PAPI consiste en un conjunto de bibliotecas de funciones que nos per- miten realizar pruebas de rendimiento de hardware con c´odigo creado por nosotros mismos. Usando estas bibliotecas podremos crear benchmarks, me- dir FLOPS, MIPS, etc, en el procesador. Estas bibliotecas constan de 40 funciones de bajo nivel y 6 funciones de alto nivel. Estas ´ultimas est´an cons- truidas usando las primeras para facilitar los test del hardware, tanto en Fortran como en C. Con todas estas funciones se nos proporciona acceso a los contadores hardware de nuestro procesador y con ellos se pueden medir ocurrencias de diferentes eventos para obtener las medidas de rendimiento que deseemos. PAPI nos da soporte para contadores hardware en Windows NT (y su- cesores) y Linux, incluyendo este ´ultimo soporte para varias arquitecturas de procesador. Arquitectura PAPI surgi´o con la idea principal de hacer frente a la cre- ciente aparici´on de diversos sistemas de medici´on exclusivos de cada arquitectura, hecho que complica la comparaci´on entre las mismas al no existir un entorno com´un de evaluaci´on de rendimiento. Por este motivo, PAPI se divide en una capa independiente de la m´aquina sobre la que se ejecuta y una capa dependiente del hardware (Figura 3.11). La capa inferior consta de una extensi´on al sistema operativo que lo aprovecha para acceder al hardware de medici´on de eventos de la m´aquina, por lo que variar´a para cada hardware y para cada sistema operativo. La capa superior est´a formada por varios componentes opcionales, que depender´an del hardware de la m´aquina, como el control de desborda- miento (overflow), el multiplexado y las interrupciones del temporiza- dor ya que no est´an disponibles en todas las m´aquinas. En esta capa se sit´uan las dos divisiones de la API, la de bajo nivel y las funciones
    • An´alisis del Sistema 53 Figura 3.11: Arquitectura del sistema PAPI de alto nivel que son usadas para las herramientas de medici´on, gra- cias a lo cual se consiguen herramientas que, al igual que PAPI, ser´an independientes de la plataforma. 3.6.2.4. Live CD Para terminar el recorrido al contexto del sistema el ´ultimo punto a mencionar es el entorno donde encontraremos el sistema. Como menciona- mos en apartados anteriores, la complicaci´on que entra˜na la configuraci´on del sistema, con la necesidad de aplicar parches y configurar el kernel de Linux de una manera especial, as´ı como la instalaci´on de bibliotecas com- plementarias apartan al usuario medio de nuestra aplicaci´on. Por ello, se ha escogido la integraci´on del sistema en un Live CD, basado en la distribuci´on de GNU/Linux Debian. Esta distribuci´on basada en Debian contar´a con todo el entorno realizado para la realizaci´on de las pruebas, as´ı como con herramientas de compilaci´on
    • 54 3.6. Descripci´on y Especificaciones del Resto del Sistema y depuraci´on, edici´on de textos y un entorno gr´afico. En Debian la realizaci´on de Live CDs (actualmente en la rama testing y unstable) se basa en un paquete de aplicaciones llamado live-helper [27]. Una vez instalado live-helper contamos con una serie de herramientas sen- cillas para realizar el proceso creaci´on del Live CD, existiendo incluso una herramienta gr´afica de configuraci´on denominada live-magic. 3.6.3. Requisitos Funcionales Una vez contextualizado el sistema, podemos establecer los requisitos funcionales de los diferentes componentes. 3.6.3.1. Performance API El componente de medici´on de eventos trae una serie de requisitos fun- cionales a satisfacer, la mayor´ıa de ellos ligados ´unicamente a los contadores hardware. La Performance API debe emplearse teniendo en cuenta que de los datos disponibles en las distintas m´aquinas, algunos forman una base com´un que deber´a estar accesible desde todas ellas, estos son: Unidades Enteras N´umero de instrucciones enteras ejecutadas y n´umero de instrucciones por segundo. Unidades de Punto Flotante Instrucciones de punto flotante por segun- do e instrucciones de multiplicaci´on o divisi´on en punto flotante. Unidad de Predicci´on de saltos, aciertos y fallos en la predicci´on Consulta de la informaci´on sobre los saltos que utiliza. Memoria Cach´e N´umero de aciertos, fallos y acceso a la misma en los distintos niveles, tanto refiri´endonos a toda la cach´e como s´olo a la de datos o s´olo a la de instrucciones (si en el procesador se encuentran separadas). Eventos Generales Acerca de distintas ocurrencias de la m´aquina, tales como tiempos de ejecuci´on de un c´odigo, cantidad de ciclos empleados, frecuencia real del procesador o interrupciones hardware. Adem´as de medir las ocurrencias de estos eventos o los tiempos, tambi´en resulta interesante de cara a la comprensi´on de la arquitectura del procesa- dor, o del compilador para dicho procesador, inferir medidas a partir de las
    • An´alisis del Sistema 55 obtenidas directamente mediante el conteo de eventos, como por ejemplo la tasa de reuso de l´ınea de cach´e, etc. En general se habla de dos tipos de eventos, unos cuentan ocurrencias y los otros cuentan duraci´on. Los primeros se cuentan cada vez que ocurre el evento que se contabiliza (lo que se traduce en un incremento del contador correspondiente). Para los de duraci´on el contador muestra el n´umero total de ciclos en los que la condici´on es cierta. Esta monitorizaci´on tambi´en debe estar disponible y se puede realizar gracias a unos registros internos que la CPU incorpora y que pueden ser inicializados, modificados y consultados. 3.6.3.2. RTAI Como comentamos en el apartado 3.6.1, el planificador est´andar del ker- nel de Linux no satisface nuestros requisitos. Necesitamos un componente en el proyecto que se encargue de reemplazar el planificador no deseado por uno que nos permita aislar un proceso en el procesador que determinemos. El sistema escogido debe cumplir con una serie de requisitos por lo tanto: Debe poder ignorar las interrupciones del sistema operativo cuando se desee, de esta forma eliminaremos este foco de intromisi´on en las mediciones. Debe estar situado por encima del sistema operativo con el fin de poder planificar incumpliendo las normas del planificador del kernel de Linux. Debe permitir la monopolizaci´on de las CPUs seleccionadas por parte de un proceso, sin que ning´un otro pueda reemplazarle ni ocupar alg´un cuanto de tiempo mientras el proceso cr´ıtico est´e en ejecuci´on. Cuando no se realice ninguna tarea espec´ıfica, el sistema debe permitir que sea el planificador de Linux el que se encargue de los procesos, es decir, no queremos un entorno exclusivo cuando se vaya a ejecutar un proceso no cr´ıtico. 3.6.3.3. Live CD Para que el entorno obtenido finalmente sea funcional y se ajuste a las necesidades del proyecto ha de satisfacer las siguientes necesidades:
    • 56 3.6. Descripci´on y Especificaciones del Resto del Sistema Configuraci´on autom´atica Configuraci´on de la red, configuraci´on gr´afica y configuraci´on del resto del sistema y perif´ericos. Acceso a la Red Una vez detectada la configuraci´on hardware de red, el sistema deber´a intentar configurar el acceso a red de forma autom´atica y en caso de no conseguirse se deber´a pedir al usuario los datos de la conexi´on para establecer el acceso a internet. Permitir el acceso al Sistema desde fuera de la Red De manera que no sea necesaria la presencia f´ısica para la realizaci´on de las mismas, el sistema deber´a hacer de servidor para cualquiera que conozca la clave del mismo pueda acceder para realizar cualquier acci´on que podr´ıa realizar en la m´aquina de forma presencial. Software de Oficina Incluyendo todo el software necesario para generar documentos de texto y datos estad´ısticos. Tambi´en se deben incluir clientes de correo y navegadores web. Herramientas de Desarrollo Depuradores, compiladores para manejar los programas que deseamos tratar y optimizar su rendimiento pro- gresivamente. Entorno Gr´afico Para alejar al usuario inexperto de complicaciones e in- cluir los paquetes comentados en el punto anterior. Posibilidad de Instalaci´on De manera que el usuario pueda instalar el sistema en su ordenador de modo nativo. 3.6.4. Requisitos No Funcionales A parte de los requisitos anteriormente indicados, la soluci´on adoptada tiene varios requisitos adicionales de car´acter general, los m´as notables son los siguientes: Reusabilidad, el sistema puede ampliarse y es necesario que cada una de las partes que lo compone est´e perfectamente definido y modulari- zado para permitir que en caso de ampliaci´on encaje adecuadamente con el resto del sistema. Cada m´odulo adem´as ha de tener en cuen- ta este punto y permitir la creaci´on del sistema sin un determinado m´odulo para permitir el desarrollo independiente de los mismos. Sistema multiplataforma, punto que como se coment´o anteriormente se satisface con la creaci´on de un sistema aut´onomo, ya que si no necesita una plataforma ya que esta incluida en la soluci´on, no hay necesidad de multiplataforma.
    • An´alisis del Sistema 57 Adaptabilidad a nuevos entornos y formas de funcionamiento. Esto se deber´a cumplir ofreciendo el c´odigo fuente junto a la soluci´on para que todo aquel que necesite adaptar el sistema a sus necesidades pueda realizar la adaptaci´on con un coste m´ınimo y sin necesidad de reali- zar ingenier´ıa inversa. Tanto el entorno como la aplicaci´on deber´an cumplir este requisito, puesto que ambas partes pueden necesitar de adaptaciones previas en distintos campos. Escasos requisitos hardware para el funcionamiento, ya que se pre- tende una soluci´on capaz de medir eventos en cualquier plataforma con arquitectura PC, se debe usar software que no requiera una gran velocidad de procesador, o una buena tarjeta gr´afica para el entorno gr´afico que acompa˜na a la distribuci´on etc.
    • Cap´ıtulo 4 Dise˜no del Sistema A lo largo de los cap´ıtulos anteriores se ha realizado una descripci´on de las caracter´ısticas, restricciones y requisitos que debe cumplir el proyecto. Mientras que la fase de an´alisis trata recopilar todas las especificaciones necesarias para lograr la soluci´on del problema independientemente de la forma de llegar a la misma, durante el dise˜no se tomar´an las decisiones pertinentes acerca de la forma en la que se resolver´a el problema. El dise˜no del sistema se dividir´a en cuatro partes: El entorno que necesita la aplicaci´on para ejecutarse. Es decir: confi- guraci´on del kernel y entornos tanto de tiempo real como de medici´on de eventos. La aplicaci´on en s´ı. Secci´on en la que indicaremos el plantamiento y desarrollo de glperfex. El dise˜no de la interfaz de la aplicaci´on. El sistema final en el que se incorporar´a la aplicaci´on, es decir el en- torno necesario de herramientas b´asicas en la m´aquina donde se ana- lizar´a el rendimiento. 4.1. Dise˜no del Entorno de Ejecuci´on El entorno de ejecuci´on debe contemplar tres apartados fundamenta- les: un kernel compilado y preparado con los parches necesarios de RTAI y perfctr, el entorno en tiempo real (RTAI+ADEOS), y el entorno para la medici´on de eventos (perfctr+PAPI). 59
    • 60 4.1. Dise˜no del Entorno de Ejecuci´on 4.1.1. Compilaci´on y Preparaci´on del Kernel El entorno de ejecuci´on dispondr´a de un kernel de Linux con todas las modificaciones necesarias para la interacci´on con el entorno de tiempo real y de medici´on de eventos. El primer paso para la preparaci´on del kernel ser´a la descarga de una copia sin modificaciones previas. Las distribuciones de GNU/Linux suelen incluir parches de serie en el kernel para mejorar la integraci´on e inter- acci´on con los componentes que incluyen. Sin embargo, algunos de estos parches provocan problemas de rendimiento y funcionamiento de RTAI. Por ello, descargaremos un kernel vanilla (en el argot de Gentoo Linux) de http://www.kernel.org, en este caso el kernel 2.6.22.15. Una vez descargado el kernel pertinente deberemos construir el parche que incluya las modificaciones necesarias para ambos entornos. El proceso recomendado para realizar el parche es el siguiente: 1. Se realizan tres copias del kernel linux-2.6.22.15 original en una carpeta. 2. Una vez realizadas las tres copias del kernel aplicamos de for- ma independiente el parche HAL (modificaci´on de ADEOS) de RTAI a linux-2.6.22.15-rtai y el parche de perfctr-2.6 para linux-2.6.22.15-papi. 3. Una vez realizada la aplicaci´on de los parches procederemos a una comparaci´on de tres v´ıas de los directorios. Una manera sencilla de realizar la comparaci´on es mediante la aplicaci´on gr´afica Meld. El mo- tivo de no aplicar los dos parches consecutivamente sobre el kernel es que existen modificaciones comunes a varias l´ıneas de c´odigo con dis- tintas implementaciones, y por ello es necesaria una evaluaci´on l´ınea a l´ınea de los cambios, decidiendo la soluci´on no-conflictiva. 4. Una vez realizado el proceso obtendremos un kernel parcheado con las caracter´ısticas necesarias para que los dos entornos funcionen de manera correcta. Lo correcto, una vez tengamos el kernel, ser´a extraer un par- che de las modificaciones a trav´es del comando diff y gene- rar tres paquetes precompilados deb1, uno para la imagen del kernel (linux-image-2.6.22.15-karma.deb), otro para las cabeceras 1 Deberemos de tener en cuenta la configuraci´on que comentaremos posteriormente de perfctr. En la versi´on original de Karma Linux (basada en Gentoo) se realiz´o un ebuild.
    • Dise˜no del Sistema 61 (linux-headers-2.6.22.15-karma.deb) y un ´ultimo paquete con las fuen- tes (linux-source-2.6.22.15-karma.deb). 4.1.2. Creaci´on del Entorno en Tiempo Real RTAI necesita para su ejecuci´on y correcto funcionamiento el sistema ADEOS, tal y como se coment´o en la descripci´on de la fase de an´alisis. La instalaci´on de este sistema requiere una recompilaci´on del kernel de Li- nux con parche espec´ıfico que coloca el sistema ADEOS por encima de ´el, permitiendo su posterior utilizaci´on por parte de RTAI. 4.1.2.1. Configuraci´on de RTAI Para la compilaci´on de RTAI, adem´as de la aplicaci´on del parche de ADEOS, es necesaria la configuraci´on del propio sistema a crear. La confi- guraci´on de RTAI sigue un sistema an´alogo al del kernel de Linux. Es decir, antes de realizar el proceso de compilaci´on (make, make install) proce- deremos a crear un Makefile de acuerdo con los objetivos de configuraci´on deseados. Para obtener este Makefile teclearemos make menuconfig, siguien- do las siguientes indicaciones del Cuadro 4.1 en el di´alogo que aparecer´a a continuaci´on. General ---> (/usr/realtime) Installation directory (/usr/src/linux) Linux source tree RTAI Documentation ---> [*] Build DocBook XML documentation (HTML/PDF) [*] Let the DocBook XML tools use network Base system ---> [*] Kernel/User space scheduler without RTAI own kernel tasks [*] Kernel/User space scheduler with RTAI own kernel tasks Cuadro 4.1: Configuraci´on del Entorno en Tiempo Real Las primeras opciones establecidas, dentro del apartado General indi- can los directorios de instalaci´on del sistema y del ´arbol del kernel a utilizar. Dentro de este apartado modificaremos la RTAI Documentation seleccio- nando la construcci´on de la documentaci´on en HTML y PDF para permitir usar la red a las herramientas de DocBook (el sistema de generaci´on de documentaci´on empleado por RTAI). Las opciones seleccionadas dentro de Base System forman parte del pro- pio sistema a generar, su significado es el siguiente:
    • 62 4.1. Dise˜no del Entorno de Ejecuci´on Kernel/User space scheduler without RTAI own kernel task Especifica que el planificador soporte hard real time para todos los objetos planificables de Linux (procesos, hilos y kthreads2). Kernel/User space scheduler with RTAI own kernel task Indica que no deseamos solamente hard real time para objetos del sistema, sino tambi´en para las tareas de RTAI. Esta opci´on hace tambi´en que la llamada a creaci´on de procesos de RTAI cree un propio proceso de RTAI en modo kernel, por lo que se reduce notablemente el tiempo de ejecuci´on eliminando los cambios de contexto. 4.1.3. Creaci´on del Entorno de Medici´on de Eventos El entorno PAPI necesita, al igual que RTAI, unas funcionalidades que no est´an incluidas por defecto en el kernel de Linux por lo que es necesario aplicar una serie de modificaciones al mismo en forma de parche. 4.1.4. Integraci´on del Sistema de Medici´on en el kernel de Linux La configuraci´on (configuraci´on make menuconfig del kernel de Linux) necesaria para el sistema de medici´on de eventos escogido (perfctr) se mues- tra en el cuadro 4.2. Processor type and features ---> Performance-monitoring counters support ---> <*> Performance monitoring counters support [ ] Additional internal consistency checks [ ] Init-time hardware tests [*] Virtual performance counters support [*] Global performance counters support Cuadro 4.2: Configuraci´on de perfctr dentro del kernel de Linux La justificaci´on de las selecciones es la siguiente: 2 Un kthread es un hilo creado bajo modo kernel para realizar algunas tareas de fondo. A pesar de que habitan en modo kernel y jam´as son enviados a modo usuario, los kthreads son tratados como procesos normales y pueden ser reemplazados de la cola de planificaci´on como cualquier otro proceso. S´olo son creados durante el inicio o por otro kthread
    • Dise˜no del Sistema 63 Additional internal consistency checks Esta opci´on no ser´a necesaria, ya que se utiliza para labores de depuraci´on. Init-time hardware test Permite al driver realizar tests del hardware adicionales durante la inicializaci´on de modo que se puedan realizar algunas comprobaciones, algo ´util cuando el procesador sobre el que se van a realizar las pruebas principales no es conocido o est´andar. En la mayor´ıa de los casos esto no es as´ı por lo que esta opci´on no es necesaria. Virtual performance counters support Crea contadores virtuales a partir de los contadores hardware encargados de medir cada proce- so, esto evita ruidos y aumenta la efectividad de las mediciones. Global performance counters support Permite que se lean y controlen todas las mediciones realizadas en todos los procesadores. Una vez establecida la configuraci´on necesaria del kernel de Linux se seguir´a la instalaci´on t´ıpica que proporcionan las herramientas de autocon- figuraci´on de GNU. 4.2. Dise˜no de la Aplicaci´on En este apartado se describen las clases que son necesarias para la aplica- ci´on y que se desean implementar. Las clases han sido extra´ıdas de la propia definici´on del problema, de los diagramas de casos de uso y de los diagramas de secuencia. Cada una de ´estas clases que ser´an descritas incluyen: una breve des- cripci´on de la funcionalidad de la clase, los diferentes atributos que forman la clase y los m´etodos que la componen. De ´estas clases solo se detallar´an aquellos atributos y m´etodos que se consideran m´as importantes. 4.2.1. Clase MainFrame Clase que contiene el marco principal de la aplicaci´on gr´afica, dentro de ´el se activar´an las pesta˜nas donde se configuran las diferentes opciones del programa expresadas en pesta˜nas. Es decir, la pesta˜na de Configuraci´on, clase Configuration, la pesta˜na de Contadores, clase Counters y la pesta˜na de Resultados, clase Results.
    • 64 4.2. Dise˜no de la Aplicaci´on 4.2.1.1. M´etodos init Constructor de la clase. GetAndSendSelections Recoge las selecciones que se han realizado y comprueba si se puede proceder a aplicar la medici´on. OnOpen Abre los resultados que est´an almacenados en un fichero dado por el usuario. OnSave Guarda los resultados de la ejecuci´on en caso de haber sido gene- rados estos. OnSaveDraw Guarda la gr´afica despu´es de comprobar si ´esta ha sido ge- nerada. OnAbout Construye la ventana de About, donde podremos consultar los autores de la aplicaci´on as´ı como su licencia completa. OnExit Cierra la ventana. 4.2.1.2. Atributos P´ublicos config Instancia de la clase Configuration. counters Instancia de la clase Counters. stats Instancia de la clase Results. nb NoteBook con los paneles de configuraci´on, contadores y resultados en sus pesta˜nas. 4.2.2. Clase Configuration Desde esta clase se muestran las opciones de Configuraci´on de la ejecu- ci´on de lperfex. Es decir, sintetiza de modo gr´afico las opciones lperfex -x, lperfex -s y lperfex -s -x de la interfaz de comandos. Adem´as de sinte- tizar las operaciones de configuraci´on, une a la cadena el fichero ejecutable (debe ser un binario enlazado con la libc) a medir. Subiendo en abstracci´on, esta clase se trata de un Panel en la ventana principal (MainFrame) de glperfex.
    • Dise˜no del Sistema 65 4.2.2.1. M´etodos init Constructor de la clase MainFrame. OpenFile Abre un di´alogo para cargar un fichero, en este caso el ejecutable de la medici´on. OnOpen Habilita las checkboxes que se˜nalan la posibildad de escoger el procesador, o procesadores, donde ejecutaremos el proceso a medir en funci´on de si hemos elegido el modo normal (0), que deshabilita todos, o uno distinto de cero, que habilita la selecci´on de procesador. GetCommand Trata el Comando que ser´a enviado. 4.2.2.2. Atributos P´ublicos io Instancia de la clase IOInterface. executionMode Define el modo de ejecuci´on (normal o exclusiva). cpusnum Registra las CPUs donde se desea ejecutar el programa. executable Guardar´a el nombre del fichero ejecutable. 4.2.3. Clase Counters Desde esta clase se muestran los contadores que pueden ser medidos en la Ejecuci´on. Una vez el usuario ha observado dichos contadores podr´a selec- cionar aquellos que desee medir. Se trata de un Panel en la ventana principal (MainFrame) de glperfex. 4.2.3.1. M´etodos init Constructor de la Clase. OnSelect Controla la selecci´on de los distintos contadores al realizarse la misma. OnSelectAll Al activarse, selecciona todos los contadores de la lista. OnSelectNone Borra todos los contadores de la lista, se activa al pulsar el bot´on correspondiente. GetSelectedCountersList Obtiene los elementos seleccionados de la lista.
    • 66 4.2. Dise˜no de la Aplicaci´on 4.2.3.2. Atributos P´ublicos io Instancia de la clase IOInterface. selectedCountersList Lista de Contadores seleccionados, que se actualiza con la selecci´on del usuario. 4.2.4. Clase CheckListCtrl Esta clase construye una Lista de Control con Checkboxes, la utilizare- mos para que el usuario seleccione los contadores. 4.2.4.1. M´etodos init Constructor de la Clase. 4.2.5. Clase Results Esta clase controla la interfaz de Resultados, dentro de ella encontra- mos un notebook con pesta˜nas eliminables donde se registran los resultados generados desde la clase de interfaz de entrada y salida. 4.2.5.1. M´etodos init Constructor de la Clase. SetResults Inserta los resultados de las ejecuciones en sus listas corres- pondientes, de forma que cada nuevo resultado aparece en una nueva pesta˜na del notebook. RemoveTab Borra un elemento dado de la lista de Pesta˜nas. SetList Inicia los diccionarios. Load Carga en el diccionario de resultados los valores del fichero a abrir. Get Extrae los valores de la ejecuci´on de la pesta˜na actual para escribirlos en un fichero. GetDraw Guarda en el fichero que se indica la gr´afica obtenida, en caso de haber sido generada.
    • Dise˜no del Sistema 67 4.2.5.2. Atributos P´ublicos io Instancia de la clase IOInterface. nb Notebook con pesta˜nas de paneles de resultados de obtenidos y/o carga- dos. listOfTabs Lista con las pesta˜nas de los paneles de resultados obtenidos, de modo que se puedan controlar aquellos que se encuentran abiertos en cada momento. commandDict Diccionario con los comandos a ejecutar. dictionaryOfResults Diccionario con los resultados obtenidos y que se publicar´an en los paneles de resultados. 4.2.6. Clase ResultsPanel La clase ResultsPanel se ocupa de manejar las pesta˜nas que se cargan en la clase Results. 4.2.6.1. M´etodos init Constructor de la clase. DecideStructure Este m´etodo construye los resultados que figurar´an en la pesta˜na de cada resultado, la construcci´on depender´a del n´umero de filas que tenga, es decir, si la ejecuci´on se realiz´o una sola vez, s´olo tendr´a que ofrecer resultados individuales, en caso contrario mostra- mos la gr´afica y las ejecuciones medias. OnSelect Es llamado al activar el evento de selecci´on de un resultado medio de la lista de resultados medios. Tiene el objetivo de imprimir en la lista de resultados individuales dichos resultados y dibujar la gr´afica. 4.2.6.2. Atributos P´ublicos isDrawn Comprueba si se ha dibujado la gr´afica de resultados (la variable se utiliza para comprobaciones a la hora de guardar la gr´afica). dictionaryOfResults Diccionario con los resultados obtenidos y que pu- blicar´a en el panel. rows Indica el n´umero de filas que tendr´a el panel de resultados individuales (una fila significar´a que s´olo hubo una ejecuci´on y no hace falta fabricar un panel con resultados individuales).
    • 68 4.2. Dise˜no de la Aplicaci´on 4.2.7. Clase IOInterface Esta clase hace de interfaz entre glperfex y lperfex, de manera que el resto de clases puedan despreocuparse de los aspectos m´as complicados como leer ficheros, escribir en ellos o comunicarse con la entrada y salida de lperfex. 4.2.7.1. M´etodos init Constructor de la clase. GetDictionary Devuelve el diccionario de contadores de la m´aquina. AddItemToSelectionList A˜nade un ´ıtem a la lista de selecci´on. RemoveItemFromSelectionList Borra un ´ıtem de la lista de selecci´on. CleanSelectionList Borra toda la lista de selecci´on. GetSelectionList Devuelve la lista de selecci´on. GetResults Devuelve los resultados obtenidos al ejecutar un comando de lperfex, es quiz´a el m´etodo m´as importante de glperfex, ya que es junto al m´etodo que obtiene la lista de eventos el que ofrece la interacci´on con lperfex. DividePath Obtiene el directorio y lo une al nombre del fichero tras com- probar que se aloja en un directorio v´alido en la variable PATH del sistema. CheckExecutableFile Comprueba si el fichero introducido se trata de un fichero ejecutable v´alido a trav´es de la salida del comando file, es decir, si se trata de un fichero ELF de 32 bits enlazado din´amicamente. ReadCSV Lee un fichero .csv dado por par´ametros, tal y como estable- cimos en la definici´on del mismo en el apartado 3.4.2, y devuelve un diccionario de resultados tal y como si se hubiera realizado una medi- ci´on normal. WriteCSV Escribe un fichero .csv con los resultados recibidos. SaveDraw Guarda un fichero utilizando el m´etodo SaveFile del objeto cliente.
    • Dise˜no del Sistema 69 4.2.7.2. Atributos P´ublicos selectionList Lista de selecci´on. dictofCounters Diccionario de contadores de la m´aquina (incluye el nom- bre del contador y la descripci´on del mismo). command Comando a ejecutar. 4.3. Dise˜no de la Interfaz En esta secci´on se presentan, a partir de los requisitos que impusimos en la fase de an´alisis de la interfaz, secci´on 3.5, los dise˜nos de las ventanas de nuestra aplicaci´on mediante una serie de capturas de pantalla. 4.3.1. Generar Medici´on Cuando describ´ıamos los casos de uso, habl´abamos de dos casos princi- pales de uso, el caso que nos llevaba a generar una medici´on, configurando una serie de par´ametros, y el caso en el que carg´abamos los resultados desde un fichero. En este caso nos ocupamos del primero. 4.3.1.1. Configuraci´on Tal y como podemos observar en la Figura 4.1, la primera vista del pro- grama nos muestra una ventana con tres pesta˜nas, correspondientes a cada uno de los tres paneles necesarios para configurar y recoger los resultados de las mediciones. En la primera pesta˜na que se muestra podemos escoger los distintos par´ametros de configuraci´on de la ejecuci´on. Es decir: Modo de Ejecuci´on Nos permitir´a seleccionar entre la ejecuci´on est´andar (normal), que usa el planificador del kernel de Linux para ejecutar la tarea, o la ejecuci´on en modo exclusivo, que inicia una tarea en tiempo real. CPUs activas En caso de seleccionar el modo exclusivo es posible escoger el procesador donde se lanzar´a la tarea. Por defecto, si no se selecciona nada se ejecutar´a en el primer procesador de la m´aquina (en este caso CPU0). En caso de seleccionar ambos procesadores RTAI decide el
    • 70 4.3. Dise˜no de la Interfaz Figura 4.1: Glperfex: ventana principal procesador donde aislar la tarea dependiendo de la carga de tareas de RTAI que existan en ese momento activas. El n´umero de procesadores se detecta a trav´es de una llamada al sistema en tiempo de ejecuci´on. N´umero de Ejecuciones Con esta configuraci´on indicamos el n´umero de mediciones que queremos realizar de los eventos que luego selecciona- remos en la pesta˜na de Contadores, en este caso es posible realizar entre 1 y 20 ejecuciones. Binario a Ejecutar En este di´alogo se introduce el ejecutable del progra- ma sobre el que deseamos realizar las mediciones. Podemos buscar gr´aficamente la ruta a trav´es del bot´on etiquetado con “...” o es- cribirla directamente. Si nuestro ejecutable est´a en un directorio del PATH, tambi´en se permite escribir el nombre del archivo sin ruta. Por ejemplo, para realizar una medida del comando ls, no har´a falta especificar /bin/ls. 4.3.1.2. Contadores Una vez establecidos los par´ametros de configuraci´on de la ejecuci´on, en la segunda pesta˜na, la pesta˜na de Contadores, Figura 4.2, se proceder´a a
    • Dise˜no del Sistema 71 la selecci´on de los contadores requeridos para la ejecuci´on. Estos contadores son obtenidos en tiempo de ejecuci´on, a trav´es de lperfex sobre la m´aquina sobre la ejecutamos y se nos permite elegir todos los contadores requeridos, ya que internamente, se medir´an de forma independiente3. Figura 4.2: Glperfex: pesta˜na de contadores 4.3.1.3. Resultados Con los datos inclu´ıdos en la pesta˜na de configuraci´on, y en la de con- tadores podemos realizar la medici´on. Como hemos comentado ya, tanto en la fase de an´alisis como en la de dise˜no, la presentaci´on de los resultados depende del n´umero ejecuciones que hayamos indicado en la configuraci´on. Como podemos observar en la Figura 4.3, al ordenar m´as de una ejecu- ci´on, se generar´a una gr´afica y se indicar´an tambi´en los resultados indivi- duales de la misma, y en caso contrario, Figura 4.4, se mostrar´a un ´unico resultado individual de los contadores seleccionados. Los diferentes resultados de las ejecuciones se muestran como hemos podido ver en diferentes pesta˜nas etiquetadas seg´un su orden de ejecuci´on. 3 Dependiendo de la arquitectura, normalmente no se permite la medici´on de m´as de dos eventos al mismo tiempo
    • 72 4.3. Dise˜no de la Interfaz Figura 4.3: Glperfex: pesta˜na de resultados con siete ejecuciones Estas pesta˜nas nos permiten mantener a mano resultados de ejecuciones anteriores y comparar los mismos de manera sencilla. El resto de operaciones que podemos realizar en el caso de uso podemos observarlas en la Figura 4.5, donde vemos el men´u Archivo desplegado, con las opciones de Guardar Resultados y Guardar Gr´afica. 4.3.2. Cargar Resultado El caso de uso Cargar Resultado est´a contemplado en la interfaz tal y como fue descrito en la fase de an´alisis. Como podemos observar en la Figura 4.5, al seleccionar Archivo en la barra de men´u, se despliegan una serie de opciones. Al pulsar en la opci´on abrir, Figura 4.6, se nos pregunta el nombre del fichero CSV deseado. Una vez seleccionado, ´este se cargar´a en la pesta˜na de resultados, tal y como se muestra en la Figura 4.7.
    • Dise˜no del Sistema 73 Figura 4.4: Glperfex: pesta˜na de resultados con una ejecuci´on 4.4. Dise˜no del Sistema Aut´onomo La ´ultima parte del dise˜no de nuestro sistema trata de establecer las herramientas finales necesarias del sistema aut´onomo, es decir, todo aquello que requerir´a el Live CD en el que se presenta la soluci´on final para su funcionamiento y uso. Como comentamos en el apartado 3.6.2.4, el conjunto de herramientas provistas en las distribuciones Debian testing y unstable para la realizaci´on de un Live CD se denomina live-helper. El proceso a seguir para la realiza- ci´on del Live CD requiere unas opciones de configuraci´on iniciales, donde dejaremos prefijadas algunas de las caracter´ısticas del sistema, y una confi- guraci´on m´as amplia, donde en un entorno chroot4, dejar establecidas todas las necesidades finales del mismo. 4 chroot es una llamada al sistema en Unix que permite configurar un directorio co- mo ra´ız del sistema de ficheros para un proceso y sus hijos. En otras palabras, permite configurar el sistema de forma tal que se puedan lanzar procesos confinados dentro de un determinado directorio. Para ellos, dicho directorio ser´a el “/” (la ra´ız). Cualquier fichero o directorio que est´e fuera del chroot les quedar´a inaccesible.
    • 74 4.4. Dise˜no del Sistema Aut´onomo Figura 4.5: Glperfex: opciones del men´u archivo 4.4.1. Instalaci´on de Live Helper El primer paso para construir el sistema ser´a la instalaci´on del conjunto de herramientas que provee live-helper, para ello tecleamos: # apt-get install live-helper live-initramfs live-magic > live-initscripts user-setup Si observamos los paquetes instalados, aparece live-magic una sencilla aplicaci´on gr´afica, que, utilizada a modo de wizard5 permite realizar r´apida- mente un Live CD ampliamente configurable. Sin embargo, para la puesta en marcha de nuestro sistema, utilizaremos otro tipo de herramientas. 4.4.2. Configuraci´on del Live CD B´asico Una vez contamos con las herramientas necesarias, procedemos al dise˜no del sistema aut´onomo propiamente dicho. Para ello, utilizando el coman- do lh_config, estableceremos unas primeras configuraciones sobre datos 5 Con wizard nos referimos a un asistente de configuraci´on sencillo y paso a paso.
    • Dise˜no del Sistema 75 Figura 4.6: Glperfex: abriendo una prueba gen´ericos del Live CD. Para ello crearemos una carpeta donde se guardar´an todos los ficheros generados en las fases de construcci´on y dentro de ´el te- clearemos lo siguiente: # lh_config -a i386 --sections "main contrib" -p gnome Esto nos crea las indicaciones sencillas para un Live CD de la arquitec- tura x86, con repositorios de Debian main y contrib y el entorno gr´afico gnome. Si quisi´eramos terminar simplemente con el sistema indicado te- clear´ıamos lh_build y se construir´ıa la imagen del CD, sin embargo, en este caso deberemos cumplir m´as indicaciones. 4.4.3. A˜nadiendo Funcionalidades al Live CD B´asico La manera m´as sencilla de a˜nadir funcionalidades a nuestro CD b´asico ser´a construir un entorno chroot y dentro de ´el instalar programas tal y
    • 76 4.4. Dise˜no del Sistema Aut´onomo Figura 4.7: Glperfex: resultados cargados de un fichero CSV como si estuvi´eramos en un sistema normal. Antes de eso deberemos esta- blecer nuestro “sabor” del kernel dentro de la configuraci´on. Por ello en el fichero config/chroot modificaremos los par´ametros LH_LINUX_FLAVOURS y LH_LINUX_PACKAGES con los valores del Cuadro 4.3. LH_LINUX_FLAVOURS="2.6.22.15-karma" LH_LINUX_PACKAGES="linux-image linux-headers linux-source aufs-modules squashfs-modules rtai-dev rtai-modules" Cuadro 4.3: Configuraci´on previa del kernel del Live CD Lo que queremos indicar es que usaremos un kernel distinto al que in- cluye Debian por defecto, y que instale los siguientes paquetes extra, que se denominar´an utilizando el sufijo -2.6.22.15-karma. A Estos paquetes son necesarios para la configuraci´on de nuestro kernel, adem´as de los ya nombra- dos linux-image-2.6.22.15-karma, linux-headers-2.6.22.15-karma y linux-source-2.6.22.15-karma, se a˜naden los construidos con la compi- laci´on de RTAI, que incluyen m´odulos para este kernel, y los m´odulos para el mismo kernel de los sistemas de ficheros aufs y squashfs necesarios para
    • Dise˜no del Sistema 77 cargar el sistema en el arranque del Live CD. Los paquetes mencionados deber´an copiarse al directorio config/chroot_local-packages. 4.4.4. El entorno chroot Una vez realizadas algunas de las configuraciones b´asicas necesarias, es- tamos en condiciones de configurar el entorno chroot. Para construirlo de- beremos ejecutar: # lh_bootstrap && > lh_chroot && > lh_chroot_hosts install && > lh_chroot_resolv install && > lh_chroot_proc install && > chroot chroot Tras esta serie de instrucciones tendremos un entorno a construir, que finalmente ser´a el que disfrutaremos durante la ejecuci´on del Live CD. La lista de operaciones a realizar ser´ıa m´as o menos la siguiente: 1. Configuraci´on de las Locales. 2. Instalaci´on de compiladores, bibliotecas y herramientas necesarias para la compilaci´on y configuraci´on de las fuentes. Entre estas herramientas podemos encontrar: gcc, gfortran y g77, gdb y su interfaz ddd, make, autoconf, autogen... 3. Instalaci´on de wxPython en su versi´on 2.8. Para ello in- cluiremos los repositorios de wxPython de Ubuntu Gutsy, deb http://apt.wxwidgets.org/ gutsy-wx main en el fiche- ro de fuentes /etc/apt/source.list. Los paquetes a instalar ser´an: python-wxgtk2.8, python-wxtools, python-wxaddons y wx2.8-i18n. 4. Instalaci´on de PAPI, con sus librer´ıas, compilando las fuentes. 5. Instalaci´on de lperfex, compilando las fuentes y glperfex, a trav´es de su fichero deb. 6. Instalaci´on de programas de oficina y edici´on de textos, tales como todo el paquete de openoffice.org y el IDE kile, para la edici´on de LATEX, y el editor fundamental vim.
    • 78 4.4. Dise˜no del Sistema Aut´onomo 7. Instalaci´on de herramientas de comunicaci´on, es decir, clientes de men- sajer´ıa como pidgin, paquetes de acceso remoto ssh y clientes de IRC como xchat. 4.4.5. Cerrando el Live CD Una vez realizada la configuraci´on del entorno chroot s´olo quedar´a la construcci´on del sistema en una imagen capaz de generar un CDROM. Por lo tanto, para terminar el proceso, simplemente tecleamos: # lh_chroot_hosts remove && > lh_chroot_resolv remove && > lh_chroot_proc remove && > lh_binary Tras este proceso, si miramos el directorio que creamos al inicio, descubri- remos un fichero llamado binary.iso, que ser´a la soluci´on final al problema que plantea el proyecto.
    • Cap´ıtulo 5 Pruebas 5.1. Introducci´on A lo largo del siguiente cap´ıtulo se mostrar´an y comentar´an los resultados de las pruebas realizadas sobre la aplicaci´on principal y la integraci´on de la misma en el sistema. Las pruebas que realizaremos tienen una doble finalidad: Pretenden poner de manifiesto posibles errores o incongruencias de la aplicaci´on con el objetivo de corregirlas antes de su puesta en funcio- namiento. Pretenden demostrar que la aplicaci´on cumple con los requerimientos detallados en la fase de an´alisis. Las pruebas que realizaremos sobre la aplicaci´on ser´an: Pruebas de Unidad Engloba las siguientes pruebas: Pruebas de Casos de Uso Equivalen a las pruebas de caja negra. En ellas se observa el comportamiento de la aplicaci´on desde el punto de vista del resultado, a partir de una entrada para cada uno de los casos de uso especificados en la secci´on 3.2.1. Pruebas de Escenarios de la Aplicaci´on Equivalentes a las prue- bas de caja blanca, donde se analiza la secuencia interna de accio- nes para ejecutar cada grupo espec´ıfico de datos de entrada para la aplicaci´on. 79
    • 80 5.2. Pruebas de Unidad Pruebas de la Aplicaci´on Se realizar´an varias pruebas de la aplicaci´on de forma global. Pruebas de Rendimiento Se comprar´an diferentes ejecuciones en la me- dici´on de eventos para ver el ´exito de la implantaci´on de la soluci´on de la ejecuci´on exclusiva. 5.2. Pruebas de Unidad Las pruebas de unidad tratan de comprobar que el sistema desarrollado cumple de forma correcta las especificaciones para las que fue definido. De este modo se verificar´a que toda la funcionalidad de la aplicaci´on proporciona la salida esperada y que existen los distintos conjuntos de datos de entrada que hacen que se ejecuten todos los caminos posibles. Estas t´ecnicas se denominan pruebas de casos de uso y pruebas de escenarios, respectivamente. 5.2.1. Pruebas de Casos de Uso En esta secci´on se realizar´an pruebas para cada uno de los casos de uso descritos en el la secci´on 3.2.1. Para la realizaci´on de los mismos ser´a necesario desarrollar una serie de casos de prueba que especifiquen las pruebas para cada caso. Un caso de prueba de este tipo incluye la verificaci´on del resultado de la interacci´on entre actores y aplicaci´on, y de la secuencia a seguir de acuerdo con las acciones especificadas en el mismo. Por lo tanto, esta prueba consiste en una aplicaci´on de la caja negra, es decir, una prueba del comportamiento de la misma observable desde el exterior. A continuaci´on se describen los diferentes casos de prueba descritos para los dos casos de uso de la aplicaci´on y para extensiones de casos de uso. 5.2.1.1. Caso de Prueba: Generar Medici´on Entrada La aplicaci´on recibir´a los datos necesarios para la ejecuci´on, es decir, el tipo de medici´on est´andar, en el caso de uso normal, el n´ume- ro de ejecuciones que se desean realizar, el nombre y, en caso de ser
    • Pruebas 81 necesaria, la ruta del binario a ejecutar (que deber´a ser un fichero bi- nario compilado de 32 bits). Adem´as habr´a que a˜nadir una lista de contadores de los indicados en la lista que se adjunta al usuario. Salida La salida correcta ser´a la enumeraci´on de los resultados de los datos pedidos en una nueva pesta˜na de resultados. Estos llevar´an una gr´afica en caso de haberse ordenado m´as de una ejecuci´on. Condiciones Haber introducido un binario v´alido y seleccionado uno o m´as contadores. Como caso especial de esta medici´on tenemos la medici´on exclusiva, en este caso, el caso de prueba ser´ıa: Entrada La aplicaci´on recibir´a los datos necesarios para la ejecuci´on, es decir, el tipo de medici´on exclusiva, las CPUs donde se desea intentar lanzar el proceso en tiempo real, el n´umero de ejecuciones que se desean realizar, el nombre y, en caso de ser necesaria, la ruta del binario a ejecutar (que deber´a ser un fichero binario compilado de 32 bits). Adem´as habr´a que a˜nadir una lista de contadores de los indicados en la lista que se adjunta al usuario. Salida La salida correcta ser´a la enumeraci´on de los resultados de los datos pedidos en una nueva pesta˜na de resultados. Estos llevar´an una gr´afica en caso de haberse ordenado m´as de una ejecuci´on. Condiciones Haber introducido un binario v´alido, y seleccionado uno o m´as contadores, adem´as de la CPU donde lanzar la aplicaci´on. 5.2.1.2. Caso de Prueba: Guardar Medici´on Entrada Debe introducirse el nombre del fichero y la ruta que se desea guardar en el di´alogo de gnome que se abre para guardar el fichero. Salida Aparecer´a en el directorio que hemos escogido un fichero con los resultados. Condiciones Deber´a haberse seleccionado un resultado en la pesta˜na de resultados, o tenerlo activo. 5.2.1.3. Caso de Prueba: Guardar Gr´afica Entrada Debe introducirse el nombre del fichero y la ruta que se desea guardar en el di´alogo de gnome que se abre para guardar el fichero. El
    • 82 5.2. Pruebas de Unidad tipo de fichero ser´a uno de los que soporta la biblioteca de las gr´aficas, estos se indicar´an en la ventana. Salida Aparecer´a en el directorio que hemos escogido un fichero con la gr´afica. Condiciones Deber´a haberse seleccionado un resultado en la pesta˜na de resultados que contenga una gr´afica. 5.2.1.4. Caso de Prueba: Cargar Medici´on Entrada Debe introducirse el nombre del fichero y la ruta que se desea cargar en el di´alogo de gnome que se abre para cargar el fichero. Salida Aparecer´an los resultados cargados en una nueva pesta˜na de la pes- ta˜na de resultados. Condiciones Deber´a haberse seleccionado un fichero v´alido. 5.2.2. Pruebas de Escenarios de la Aplicaci´on Para la realizaci´on de estos casos es necesaria la implementaci´on de una serie de casos de prueba. Un caso de prueba de este tipo puede incluir la verificaci´on de la interacci´on entre los componentes que implementan los casos de uso. Estos casos especificar´an una prueba de aplicaci´on de caja blanca. Los casos de prueba realizados son los siguientes: 5.2.2.1. Caso de Prueba: Generar Medici´on El cuarto caso se trata de una opci´on s´olo compatible con la medici´on exclusiva. 1. Descripci´on El usuario no introduce el nombre del binario a ejecutar. Acciones Esperadas El sistema informa de la ausencia de datos. 2. Descripci´on El usuario introduce un fichero no v´alido en el campo del binario a ejecutar. Acciones Esperadas
    • Pruebas 83 El sistema informa de la incompatibilidad del fichero con el formato requerido. 3. Descripci´on El usuario no selecciona ning´un contador en la pesta˜na de contadores. Acciones Esperadas El sistema informa de la ausencia de contadores. 4. Descripci´on El usuario no selecciona ninguna CPU donde ejecutarse. Acciones Esperadas El sistema presupone que se ha seleccionado la CPU0. 5.2.2.2. Caso de Prueba: Guardar Medici´on 1. Descripci´on El usuario no introduce el nombre del fichero a guardar. Acciones Esperadas El sistema informa de la ausencia de datos. 2. Descripci´on No se ha realizado ninguna medici´on. Acciones Esperadas El sistema informa de la ausencia de mediciones a guardar. 5.2.2.3. Caso de Prueba: Guardar Gr´afica 1. Descripci´on El usuario no introduce el nombre de la gr´afica a guardar. Acciones Esperadas El sistema informa de la ausencia de datos. 2. Descripci´on El usuario intenta guardar sin haberse generado una gr´afica. Acciones Esperadas El sistema informa de la ausencia de gr´afica a guardar. 5.2.2.4. Caso de Prueba: Cargar Medici´on 1. Descripci´on El usuario no introduce el nombre de la medici´on a cargar. Acciones Esperadas El sistema no hace nada.
    • 84 5.3. Pruebas de la Aplicaci´on 2. Descripci´on El usuario intenta cargar un fichero no v´alido. Acciones Esperadas El sistema no hace nada. 5.3. Pruebas de la Aplicaci´on En este apartado se describir´an los resultados obtenidos en la realizaci´on de los casos y procedimientos de prueba dise˜nados en el apartado anterior, probando as´ı los casos de uso m´as importantes. 5.3.1. Procedimiento Seguido A continuaci´on se especifica el procedimiento seguido para probar los distintos casos de prueba de la aplicaci´on: 1. El usuario ejecuta la aplicaci´on. 2. El usuario intenta realizar una medici´on sin ejecutar ning´un binario en el campo indicado. 3. El usuario introduce un fichero no v´alido como binario para las medi- ciones de eventos. 4. El usuario no selecciona ning´un contador en la pesta˜na de contadores. 5. El usuario no selecciona ninguna CPU en la selecci´on de CPUs de la medici´on exclusiva. 6. El usuario intenta guardar un fichero sin introducir su nombre. 7. El usuario intenta guardar un fichero sin haberse realizado una medi- ci´on. 8. El usuario no introduce el nombre de la gr´afica a almacenar. 9. El usuario intenta guardar una gr´afica sin haber sido generado ´esta. 10. El usuario no introduce el nombre de una medici´on a cargar. 11. El usuario intenta cargar un fichero no v´alido como medici´on.
    • Pruebas 85 5.3.2. Ejecuci´on de los Casos de Prueba de la Aplicaci´on Por ´ultimo, y una vez planeados, descritos y realizados los casos de prue- ba, podemos examinar el comportamiento observado en la aplicaci´on. La evaluaci´on se compone de la descripci´on del error que se produce, el resul- tado de la prueba y el estado del sistema al concluir la misma. 5.3.2.1. Caso de Prueba: Generar Medici´on El cuarto caso se trata de una opci´on s´olo compatible con la medici´on exclusiva. 1. Descripci´on El usuario no introduce el nombre del binario a ejecutar. Resultado Completado. Estado Estable. 2. Descripci´on El usuario introduce un fichero no v´alido en el campo del binario a ejecutar. Resultado Completado. Estado Estable. 3. Descripci´on El usuario no selecciona ning´un contador en la pesta˜na de contadores. Resultado Completado. Estado Estable. 4. Descripci´on El usuario no selecciona ninguna CPU donde ejecutarse. Resultado Completado. Estado Estable.
    • 86 5.3. Pruebas de la Aplicaci´on 5.3.2.2. Caso de Prueba: Guardar Medici´on 1. Descripci´on El usuario no introduce el nombre del fichero a guardar. Resultado Completado. Estado Estable. 2. Descripci´on No se ha realizado ninguna medici´on. Resultado Completado. Estado Estable. 5.3.2.3. Caso de Prueba: Guardar Gr´afica 1. Descripci´on El usuario no introduce el nombre de la gr´afica a guardar. Resultado Completado. Estado Estable. 2. Descripci´on El usuario intenta guardar sin haberse generado una gr´afica. Resultado Completado. Estado Estable. 5.3.2.4. Caso de Prueba: Cargar Medici´on 1. Descripci´on El usuario no introduce el nombre de la medici´on a cargar. Resultado Completado. Estado Estable. 2. Descripci´on El usuario intenta cargar un fichero no v´alido. Resultado
    • Pruebas 87 Completado. Estado Estable. 5.4. Pruebas de Rendimiento de la Aplicaci´on A continuaci´on analizaremos el rendimiento y posible mejora que aporta la aplicaci´on de acuerdo con la comparaci´on de la ejecuci´on en entornos con ruido y sin ruido de los test de benchmark, NAS Paralell Benchmarks (rama NPB3.2-SER) considerados en el apartado de antecedentes. Las pruebas ser´an realizadas sobre un procesador Intel Core2 Duo T7200, usando, para la planificaci´on no exclusiva, el planificador multicore del kernel de Linux 2.6.22.15. De las pruebas realizadas se obtendr´an tres datos estad´ısticos de impor- tancia: la media, la varianza y el coeficiente de variaci´on. Las pruebas se realizar´an usando la aplicaci´on en modo normal con y sin ruido de fondo, y en modo exclusivo. Se tomar´an medidas del empobrecimiento de la mues- tra en su ejecuci´on con ruido con respecto a la prueba tomada sin ruido de fondo, y a continuaci´on se comparar´an ambos resultados con las mediciones realizadas bajo exclusividad de procesador con el fin de obtener el porcen- taje de mejora de la soluci´on obtenida ante una ejecuci´on normal, con y sin procesos de fondo. Las mediciones se tomar´an siguiendo las siguientes f´ormulas: Media Se calcula de la forma est´andar: x = 1 n n i=1(xi) Varianza Corresponde a: S2 = 1 n−1 n i=1(xi − x) Empobrecimiento La f´ormula empleada para su c´alculo es: empobrecimiento = 1 − (1V arianzadelamuestraconruido V arianzadelamuestrasinruido ) Mejora Se calcula como: mejora = 1 − (1 varianza varianzaenexclusividad ) Para la obtenci´on de estad´ısticas, cada prueba se realiz´o en diez ocasio- nes.
    • 88 5.4. Pruebas de Rendimiento de la Aplicaci´on En los resultados, por motivos de espacio no se incluir´an todos los resul- tados obtenidos sino tan s´olo los tres datos indicados con anterioridad para cada caso. A continuaci´on se incluyen los resultados obtenidos de las pruebas obte- nidas durante las mediciones especificadas. 5.4.1. Pruebas No Exclusivas Sin Ruido En la Tabla 5.1 se observan los resultados obtenidos en las mediciones est´andar, es decir en las mediciones realizadas sobre un proceso ejecut´andose bajo el planificador est´andar de Linux con reemplazo. En los resultados se observa que el cociente de variaci´on alcanza valores elevados, superando en alg´un caso el 50 %, lo que indica que la fiabilidad de la muestra no es muy elevada. No de ciclos Fallos en L2 Fallos en L1 (I) Fallos en L1(D) bt.S Media 352.499.977 3.261 28.036 1.860.000 Varianza 762.143.302.344 3.310.305 23.055.152 242.172.208 Cociente de variaci´on 0,25 % 55,79 % 17,13 % 0,84 % is.S Media 39.695.619 767 1.378 105.506 Varianza 312.740.499.546 1.270.185 4.870 104.973 Cociente de variaci´on 1,41 % 146,87 % 5,06 % 0,31 % lu-hp.S Media 175.186.766 2.306 19.928 3.837.878 Varianza 321.760.503.088 3.239.976 916.563 64.651.207 Cociente de variaci´on 0,32 % 78,06 % 4,80 % 0,21 % lu.S Media 177.349.515 2.081 23.568 3.476.408 Varianza 138.163.085.576 1.273.692 6.818.650 2.854.859 Cociente de variaci´on 0,21 % 54,24 % 11,08 % 0,05 % sp.S Media 174.738.731 4.816 28.394 3.266.724 Varianza 623.326.821.562 4.651.787 6.613.768 6.235.034 Cociente de variaci´on 0,45 % 44,78 % 9,06 % 0,08 % ua.S Media 2.576.405.913 1.078.370 48.106 50.456.874 Varianza 131.616.712.100.111 86.552.694.427 2.176.890 1.340.172.865 Cociente de variaci´on 0,45 % 27,28 % 3,07 % 0,07 % Cuadro 5.1: Resultados de las mediciones est´andar sin ruido
    • Pruebas 89 5.4.2. Pruebas No Exclusivas Con Ruido Estas pruebas no muestran diferencia con las anteriores con la salvedad que durante su ejecuci´on se iniciaron intencionadamente procesos de fondo que combinasen tanto una alta carga de procesador como una alta actividad de entrada/salida. Los resultados, que podemos evaluar en la Tabla 5.2, muestran empo- brecimientos en la fiabilidad de la mayor´ıa de las mediciones. En algunas, no obstante, el empobrecimiento es negativo. Esto se explica si se tiene en cuenta que, en realidad, el primer sistema de medici´on sin ruido no estaba completamente libre de interferencias. Comparando los resultados en empobrecimiento de Karma Linux 2008 con ruido con los que se publicaron de Karma original en [1], podemos observar que el planificador multicore de Linux mejora los resultados al disponer de varios n´ucleos para distribuir la carga. No obstante, la forma de obtenci´on del ruido ha sido distinta, por lo que estos resultados no son tan concluyentes en principio como puede apreciarse a simple vista. 5.4.3. Pruebas Bajo el Entorno Exclusivo Estas pruebas se realizaron mediante el modo exclusivo de glperfex, es decir, se le indic´o a la aplicaci´on lperfex que para las mediciones a realizar se requer´ıa el entorno de exclusividad del procesador desarrollado con el fin de mejorar la medici´on y la variaci´on de las muestras. En esta ocasi´on se seleccion´o en la interfaz que se ejecutaran las pruebas sobre la CPU0 del Intel Core2 Duo T7200. RTAI lanza un proceso en el procesador escogido de modo exclusivo (la tarea ser´a ejecutada en ese procesador sin ser reemplazada). Si seleccionara- mos dos procesadores, RTAI seleccionar´ıa aquel con menor carga de procesos en tiempo real para lanzar la tarea. Las pruebas en este caso no se dividen entre pruebas con ruido y pruebas sin ruido ya que los resultados obtenidos en ambas situaciones no muestran diferencias relevantes (las tareas de Linux se ven postergadas en su uso, motivo por el que la medici´on carece de ruido, nuestra tarea no puede ser reemplazada).
    • 90 5.4. Pruebas de Rendimiento de la Aplicaci´on No de ciclos Fallos en L2 Fallos en L1 (I) Fallos en L1(D) bt.S Media 354.884.155 14.755 46.253 1.868.571 Varianza 1.125.889.636.453 28.464.662 1.935.204.824 224.169.572 Cociente de variaci´on 0,30 % 36,16 % 95,11 % 0,80 % Empobrecimiento 32,31 % 88,37 % 98,81 % -8,03 % is.S Media 39.988.446 1.759 1.543 112.822 Varianza 806.941.900.505 1.467.873 762.019 576.946.071 Cociente de variaci´on 2,25 % 68,88 % 56,59 % 21,29 % Empobrecimiento 61,24 % 13,47 % 99,36 % 99,98 % lu-hp.S Media 176.105.599 6.923 22.233 3.855.104 Varianza 294.135.373.472 3.923.527 15.985.847 774.662.732 Cociente de variaci´on 0,31 % 28,61 % 17,98 % 0,72 % Empobrecimiento -9,39 % 17,42 % 94,27 % 91,65 % lu.S Media 178.213.427 7.291 25.552 3.481.716 Varianza 121.675.944.894 32.898.824 559.462.005 82.294.866 Cociente de variaci´on 0,20 % 78,67 % 92,57 % 0,26 % Empobrecimiento -13,55 % 96,13 % 98,78 % 96,53 % sp.S Media 176.325.891 20.350 31.226 3.274.074 Varianza 1.787.535.336.985 2.569.747.778 6.820.124 333.338.206 Cociente de variaci´on 0,76 % 249,10 % 8,36 % 0,56 % Empobrecimiento 65,13 % 99,82 % 3,03 % 98,13 % ua.S Media 2.609.919.907 4.773.160 84.893 50.543.727 Varianza 228.514.900.869.419 52.736.674.402 7.426.875.267 9.463.472.940 Cociente de variaci´on 0,58 % 4,81 % 101,52 % 0,19 % Empobrecimiento 42,40 % -64,12 % 99,97 % 85,84 % Cuadro 5.2: Resultados obtenidos para las pruebas est´andar con ruido En la Tabla 5.3 se observa una disminuci´on notable de la varianza y del cociente de variaci´on en la mayor´ıa de las muestras, lo que se refleja en un alto porcentaje de mejora con respecto a la medici´on usando el planificador est´andar ya sea con procesamiento de fondo o sin el. El Campo Mejora se refiere a: 1. Mejora con respecto a la prueba no exclusiva sin ruido. 2. Mejora con respecto a la prueba no exclusiva con ruido. Una de las diferencias que se pueden extraer en la comparaci´on con [1] es la mejora de la ejecuci´on de tareas con ruido en el planificador de Linux, esto hace que en muchas ocasiones la mejora resulte menor que en la versi´on de Karma Linux original.
    • Pruebas 91 No de ciclos Fallos en L2 Fallos en L1 (I) Fallos en L1(D) bt.S Media 352.308.025 5.238 15.088 1.847.476 Varianza 632.320.045.424 388.458 24.228 244.347.100 Cociente de variaci´on 0,23 % 11,90 % 1,03 % 0,85 % Mejora (1) 43,84 % 98,64 % 100,00 % -9,00 % Mejora (2) 17,03 % 88,27 % 99,89 % -0,90 % is.S Media 39.538.981 5.492 1.127 113.715 Varianza 4.786.736.142 972.981 2.257 16.680 Cociente de variaci´on 0,17 % 17,96 % 4,22 % 0,11 % Mejora (1) 99,41 % 33,71 % 99,70 % 100,00 % Mejora (2) 98,47 % 23,40 % 53,65 % 84,11 % lu-hp.S Media 174.690.302 5.743 15.198 3.833.006 Varianza 14.262.748.372 315.312 48.717 25.111.561 Cociente de variaci´on 0,07 % 9,78 % 1,45 % 0,13 % Mejora (1) 95,15 % 91,96 % 99,70 % 96,76 % Mejora (2) 95,57 % 90,27 % 94,68 % 61,16 % lu.S Media 176.895.184 5.607 15.444 3.477.858 Varianza 79.649.456.248 257.597 15.164 2.040.348 Cociente de variaci´on 0,16 % 9,05 % 0,80 % 0,04 % Mejora (1) 34,54 % 99,22 % 100,00 % 97,52 % Mejora (2) 42,35 % 79,78 % 99,78 % 28,53 % sp.S Media 173.663.312 4.876 14.717 3.260.188 Varianza 59.353.695.166 191.681 34.958 4.854.312 Cociente de variaci´on 0,14 % 8,98 % 1,27 % 0,07 % Mejora (1) 96,68 % 99,99 % 99,49 % 98,54 % Mejora (2) 90,48 % 95,88 % 99,47 % 22,14 % ua.S Media 2.569.790.995 434.231 24.370 50.469.484 Varianza 112.591.615.415.012 13.510.795.086 44.777 908.205.309 Cociente de variaci´on 0,41 % 26,77 % 0,87 % 0,06 % Mejora (1) 50,73 % 74,38 % 100,00 % 90,40 % Mejora (2) 14,45 % 84,39 % 97,94 % 32,23 % Cuadro 5.3: Resultados de las mediciones bajo entorno exclusivo
    • Cap´ıtulo 6 Conclusiones y Futuras Mejoras 6.1. Conclusiones Cuando plante´abamos la definici´on de los objetivos del proyecto habl´aba- mos de tres apartados fundamentales a los que deb´ıa dar soluci´on: la adap- taci´on de Karma Linux a sistemas multiprocesador, una mejora de la usa- bilidad de la aplicaci´on de medici´on y la autonom´ıa de la plataforma. Por ello la mejor manera de establecer unas conclusiones acerca del proyecto es desarrollarlas con respecto a cada objetivo planteado. Adaptaci´on a Sistemas Multiprocesador El planteamiento inicial part´ıa de la base de una distribuci´on, Karma Linux que hac´ıa posible la medici´on de eventos en sistemas computacionales monoprocesador. El objetivo era utilizar esta aplicaci´on de forma que aislara la medici´on de eventos en un ´unico n´ucleo del procesador de manera no intrusiva. Las pruebas aplicadas al sistema han demostrado la validez de la solu- ci´on para realizar mediciones m´as seguras, tal y como pudimos ver en el cuadro comparativo. La mejora, al aislar toda la carga en un n´ucleo, incluye tanto la eliminaci´on de ciclos innecesarios empleados durante el reemplazo del proceso en el planificador, como la mejora en la varia- ci´on de los resultados obtenidos en las mediciones, algo imprescindible si se quiere obtener una medici´on de fiabilidad. Como coment´abamos en el cap´ıtulo anterior, las pruebas no exclusivas fueron realizadas usando el planificador multicore del kernel de Linux 2.6.22.15 sobre el procesador Intel Core 2 Duo T7200. Esto hace que no 93
    • 94 6.1. Conclusiones hayamos podido hacer una comparaci´on pormenorizada con los resul- tados de Karma Linux original [1], ya que estos fueron realizados con el planificador est´andar del kernel 2.6.15.1 sobre AMD K8. Esto var´ıa sustancialmente las condiciones de las comparaciones, no obstante, la conclusi´on final, es que ambas soluciones plantean resultados ´optimos, cada uno en su ´ambito de ejecuci´on. Mejora de la Usabiliad El desarrollo de la interfaz glperfex ha mejorado la interacci´on del usuario con la aplicaci´on concebida. De esta manera ahora los usuarios menos experimentados no tendr´an gran dificultad para realizar sus pruebas en un entorno sencillo, donde poder alma- cenar los resultados y gr´aficas de una manera eficiente facilitando el tratamiento posterior de las mismas. glperfex permite detectar en tiempo de ejecuci´on el n´umero de proce- sadores que tiene la m´aquina, lo que posibilita tanto la elecci´on del procesador donde aislar la tarea, como el ajuste de la funcionalidad para monoprocesador y multiprocesador. Tambi´en, el control de errores, que contempla la posibilidad de com- probar si el binario introducido est´a compilado para la arquitectura y fue enlazado de manera correcta, nos permite detectar las incompati- bilidades del programa que se desea medir. Autonom´ıa de la Plataforma La autonom´ıa de la plataforma se ha con- seguido aunque no de forma est´andar. Debido a que restricciones impl´ıcitas a la soluci´on a desarrollar y al lenguaje impuesto por el propio sistema han imposibilitado la creaci´on de un sistema multipla- taforma capaz de ser ejecutado por diversos sistemas operativos, la soluci´on que se ha adoptado es la de incluir el entorno y la aplicaci´on en una distribuci´on que contenga su propio sistema operativo capaz de detectar el sistema sobre el que se ejecuta y adaptarse a el. Gracias a esto se consigue que sin necesidad de ninguna operaci´on adicional que la aplicaci´on este disponible para su uso una vez arrancado el sistema. 6.1.1. Conclusiones personales Karma Linux fue iniciado hace cuatro a˜nos por Pedro Navajas Modelo. El d´ıa de su lectura de proyecto mis conocimientos, al igual que el de los compa˜neros que acudimos, distaban mucho de alcanzar a comprender la tem´atica y metodolog´ıa utilizada para alcanzar la soluci´on del problema. Poco despu´es Ezequiel me propuso retomar el proyecto y adaptarlo a las condiciones que hemos enumerado a lo largo del manual t´ecnico, y, a pesar de la falta de preparaci´on previa, mi respuesta fue s´ı. As´ı empez´o un proceso de investigaci´on, a trav´es de la revisi´on del c´odigo y el manual t´ecnico, de
    • Conclusiones y Futuras Mejoras 95 contacto con desarrolladores a trav´es de listas de correo y de muchas lecturas complementarias, que ha dado como resultado este trabajo. La filosof´ıa del software libre hace posible las bases sobre las que se cimenta el proyecto. Pedro aparc´o el trabajo hace dos a˜nos, pero gracias a su c´odigo y documentaci´on libres pude involucrarme en el mismo desde el principio, hacer las modificaciones que se publican en este documento, y en el futuro podr´a ser retomado por nuevos programadores que den nuevos y m´as eficientes enfoques a la soluci´on. Uno de los principales problemas de los proyectos fin de carrera m´as am- biciosos es que, por falta de tiempo y medios, muchos quedan en el olvido sin llegar a funcionar completamente. Si estos proyectos buscaran la colabo- raci´on de la comunidad de desarrolladores de software libre a trav´es de los canales adecuados, es posible que alcanzaran cotas jam´as pensadas gracias al trabajo de programadores interesados en la materia de cualquier lugar del mundo. El ejemplo fundamental de este proceso de desarrollo es el kernel de Linux, iniciado just for fun por Linus Torvalds en 1991, y un proyecto apoyado por desarrolladores de algunas de las empresas m´as importantes del sector inform´atico en la actualidad. Esa debe ser la base del desarrollo tecnol´ogico, eso hace que la sociedad avance hacia metas nunca contempladas. Nunca debe escribirse software en vano, nunca. 6.2. Futuras mejoras El proyecto presenta algunos puntos en los que se puede mejorar, estando algunos ya en desarrollo: En cuanto a la aplicaci´on, la interfaz podr´ıa incorporar una peque˜na ventana con la ejecuci´on por terminal del programa que se ejecuta, esto nos dar´ıa la posibilidad de valorar si la ejecuci´on de nuestro pro- grama ha sido la correcta, ya que las malas ejecuciones tambi´en se miden, y esto podr´ıa llevar a errores. Sin embargo no se trata de una actualizaci´on de importancia vital. La ejecuci´on exclusiva no presenta control del proceso, esto hace que un test que presente un bucle infinito pueda llegar a bloquear la m´aquina. Este es el punto fundamental del trabajo actual, estamos en contacto con desarrolladores de RTAI para llegar a un camino satisfactorio en este sentido. La soluci´on radica en desactivar una CPU para el uso de Linux, de manera que el n´ucleo sea siempre accesible para RTAI, pero
    • 96 6.2. Futuras mejoras no para el planificador est´andar. Esta soluci´on evitar´ıa ruido entre me- diciones repetidas, adem´as de salvar el sistema de bloqueos. Se puede examinar el hilo de la lista de correo en [31].
    • Bibliograf´ıa [1] Pedro Navajas Modelo. Karma Linux. “Distribuci´on de Linux en Tiem- po Real para la Medici´on de Eventos”. Manual T´ecnico. Universidad de C´ordoba. C´ordoba. 2006. [2] Love R., Linux Kernel Develompent - Segunda Edici´on. Sams Publis- hing, ISBN: 0-672-32720-1, Estados Unidos, 2005. [3] Intel Technology Journal. Volume 06. Issue 01. 14 de Febrero de 2002 ISSN 1535766X. [4] Revista Technology@Intel http://www.intel.com/espanol/technology/magazine/computing/multi- core-software-1006.htm ´Ultima Comprobaci´on: 15/05/2008. [5] Latin Insights@Intel blog http://blogs.intel.com/latininsights/2007/07/el fin de la era de los mhz y.html ´Ultima Comprobaci´on: 15/05/2008. [6] P´agina Web de RTAI https://www.rtai.org ´Ultima Comprobaci´on: 6/06/2008. [7] P´agina Web de Performance API http://icl.cs.utk.edu/papi/ ´Ultima Comprobaci´on: 30/05/2008. [8] Especificaci´on del Est´andar LSB sobre la Instalaci´on de Software http://refspecs.freestandards.org/LSB 3.1.0/LSB-Core-generic/LSB- Core-generic/swinstall.html#SWINSTALL-INTRO ´Ultima Comprobaci´on: 17/05/2008. [9] Anuncio de Publicaci´on de LSB 1 en Barrapunto http://barrapunto.com/articles/01/07/01/1536239.shtml ´Ultima Comprobaci´on: 17/05/2008. 97
    • 98 BIBLIOGRAF´IA [10] Linux Standard Base Plans cross-format Package API http://www.linux.com/articles/59502 ´Ultima Comprobaci´on: 15/05/2008. [11] P´agina Web de Intel VTune Performance Analyzer http://www.intel.com/cd/software/products/asmo- na/eng/vtune/239144.htm ´Ultima Comprobaci´on: 12/05/2008. [12] Osciloscopio USB. Proyecto de fin de carrera de Pablo Hoffman y Mar- tin Szmulewicz. Universidad ORT de Montevideo, Uruguay. http://pablohoffman.com/cgi-bin/twiki/bin/view/Oscusb/ DocCap04Hardware ´Ultima Comprobaci´on: 12/05/2008. [13] An´alisis de Sistemas Operativos de Tiempo Real Libres http://www.ciclope.info/doc/rtos/rtlinux.php ´Ultima Comprobaci´on: 30/05/2008. [14] RTAI. Art´ıculo de Wikipedia Inglesa http://en.wikipedia.org/wiki/RTAI ´Ultima Comprobaci´on: 30/05/2008. [15] Benchmark. Art´ıculo de Wikipedia http://es.wikipedia.org/wiki/Benchmark ´Ultima Comprobaci´on: 6/06/2008. [16] SPEC. Art´ıculo de Wikipedia http://es.wikipedia.org/wiki/SPEC ´Ultima Comprobaci´on: 15/05/2008. [17] Pedro Navajas y Ezequiel Herruzo. Medici´on de los contadores hardware del procesador en modo exclusivo de ejecuci´on. Art´ıculo presentado y aceptado en el I Congreso Espa˜nol de Inform´atica (CEDI 2005). [18] William Saphir, Alex Woo, and Maurice Yarrow. The nas parallel ben- chmarks 2.1 results. Report NAS-96-010, Agosto de 1996. [19] GNU General Public License, version 2 http://www.gnu.org/licenses/gpl-2.0.html ´Ultima Comprobaci´on: 2/06/2008. [20] GNU General Public License. Art´ıculo de Wikipedia http://es.wikipedia.org/wiki/GPL ´Ultima Comprobaci´on: 6/06/2008. [21] Consejo Superior de Inform´atica. Estaciones de Trabajo, Pruebas de Verificaci´on y Control.
    • BIBLIOGRAF´IA 99 http://www.csi.map.es/csi/silice/Hw-cpu27.html ´Ultima Comprobaci´on: 15/05/2008. [22] CSV. Art´ıculo de Wikipedia Inglesa http://en.wikipedia.org/wiki/Comma-separated values ´Ultima Comprobaci´on: 15/05/2008. [23] Common Format and MIME Type for CSV Files csv http://tools.ietf.org/html/rfc4180 ´Ultima Comprobaci´on: 27/05/2008. [24] Fielded Text Standard Reference http://www.fieldedtext.org/Standard/FTRef0.6.odt ´Ultima Comprobaci´on: 15/05/2008. [25] How To: The Comma Separated Value (CSV) File Format http://www.creativyst.com/Doc/Articles/CSV/CSV01.htm ´Ultima Comprobaci´on: 15/05/2008. [26] An EBNF definition of the CSV format with explanation http://supercsv.sourceforge.net/csvSpecification.html ´Ultima Comprobaci´on: 15/05/2008. [27] Examples for generating a Debian Live CDs and others http://wiki.debian.org/DebianLive/Examples ´Ultima Comprobaci´on: 3/06/2008. [28] Diego L´opez Zamarr´on. Arquitectura de un Sistema Operativo de Tiem- po Real. Universidad Polit´ecnica de Madrid http://gayuba1.datsi.fi.upm.es/ dlopez/rtos.php ´Ultima Comprobaci´on: 21/05/2008. [29] The RTAI Development Team. RTAI API Documentation. Technical report, RTAI, 2004. https://web.aero.polimi.it/documentation/vesuvio/html/api/ ´Ultima Comprobaci´on: 21/05/2008. [30] The RTAI Development Team. DIAPM RTAI - Beginner’s Guide. 2002, https://www.aero.polimi.it/rtai/documentation/articles/guide.html ´Ultima Comprobaci´on: 24/05/2008. [31] Isolating a task in a CPU thread on RTAI Mailing List. https://mail.rtai.org/pipermail/rtai/2008-June/thread.html#19697 ´Ultima Comprobaci´on: 6/06/2008.
    • Ap´endice A Manual de Usuario El siguiente documento incluye las instrucciones necesarias para la utili- zaci´on satisfactoria de glperfex, una interfaz gr´afica sencilla para la medici´on de eventos de procesador en un ambiente determinista. La medici´on de eventos de procesador en la ejecuci´on de un programa puede dar pistas muy valiosas al desarrollador para la optimizaci´on del mis- mo. Esto incluye informaci´on acerca del n´umero de ciclos de procesador que consume un programa al ser usado, el n´umero de fallos de cach´e tanto de nivel 1, como de nivel 2..., que influir´a radicalmente en programas dise˜nados para sistemas sensibles, por ejemplo sistemas empotrados, donde es necesa- rio ajustar hasta el m´as peque˜no detalle de rendimiento. Sin embargo, dichas mediciones son influidas por los ruidos propios de los sistemas operativos multitarea, donde la concurrencia de procesos, con sus consecuentes reemplazos provocan errores en las mediciones, que pueden llevar nuestro desarrollo por enfoques equivocados. La aplicaci´on glperfex proporciona una soluci´on a este problema. Dispo- ne, a trav´es de bibliotecas espec´ıficas para la medici´on de una gran variedad de eventos, detectados al encender la m´aquina. Adem´as provee una solu- ci´on al problema del ruido en las mediciones de los eventos, gracias a un modo particular de ejecuci´on que permite ejecutar nuestro programa en un procesador en modo exclusivo (aislando tambi´en tareas en sistemas multi- procesador). glperfex se incluye en Karma Linux 2008, una distribuci´on de GNU/Linux configurada especialmente para lograr dicho objetivo. No obs- tante es posible instalar todos los elementos necesarios para su funciona- miento en cualquier m´aquina de arquitecturas x86 y x86 64. Sin embargo, concebimos Karma para facilitar el acceso a la aplicaci´on a usuarios no 101
    • 102 A.1. Requisitos avanzados, de modo que puedan realizar las pruebas de un modo totalmente portable y sin necesidad de instalar todo el sistema en su m´aquina, a pesar de, y como explicaremos a continuaci´on, ofrecer al usuario la posibilidad de instalar todo el sistema del mismo modo que se instala cualquier distribuci´on de GNU/Linux. A.1. Requisitos A.1.1. Requisitos del Sistema Completo Para la ejecuci´on y/o instalaci´on de Karma Linux 2008 son necesarios los siguientes requisitos hardware (todo el software necesario se incluye en la distribuci´on). Procesador de arquitecturas x86 o x86 64 de entre los siguientes mo- delos: • Intel Pentium III • Intel Pentium 4 • AMD Opteron • AMD Athlon • Intel Itanium • Intel Core2 series Lector de DVDs. 5GB de espacio libre en el Disco Duro en caso de desear la instalaci´on. A.1.2. Requisitos de Glperfex A pesar de que el documento enfoca la utilizaci´on y puesta a punto del sistema Karma Linux 2008 completo, es conveniente indicar los requisitos de la aplicaci´on para los usuarios que quieran tratarla en su propio sistema. A.1.2.1. Requisitos Hardware Procesador de arquitecturas x86 o x86 64 de entre los siguientes mo- delos: • Intel Pentium III
    • Manual de Usuario 103 • Intel Pentium 4 • AMD Opteron • AMD Athlon • Intel Itanium • Intel Core2 series A.1.2.2. Requisitos Software Cualquier distribuci´on de GNU/Linux. Kernel de la rama 2.6 incluyendo los parches de RTAI y perfctr para el mismo, y compilado con las opciones requeridas por perfctr para la medici´on de eventos. PAPI 3.5 o superior. RTAI 3.5 o superior. Aplicaci´on lperfex, con fichero ejecutable situado en alguna carpeta incluida en la variable PATH del sistema. Python 2.4 WxPython 2.8 A.2. Instalaci´on A.2.1. Instalaci´on de Karma Linux 2008 Karma Linux 2008 se trata, a diferencia de su antecesora1, de una dis- tribuci´on basada en Debian GNU/Linux. Esto hace que la instalaci´on de la misma sea sencilla para un usuario de nivel medio/bajo, igual que la instalaci´on de Debian Lenny2. Los pasos a seguir son los siguientes: 1. Inserte el DVD en su unidad, despu´es de comprobar que la opci´on de carga de ese dispositivo es la primera en el orden de arranque de la BIOS. 1 Karma Linux fue concebida como una distribuci´on basada en Gentoo 2 Puesto que la instalaci´on es la propia de Debian Lenny al ser una modificaci´on de la misma, seguimos los pasos tal y como se indican en el manual del instalador de Debian, http://d-i.alioth.debian.org/manual/es.i386/apas03.html
    • 104 A.2. Instalaci´on 2. Una vez que se inicie el instalador, se le mostrar´a una pantalla inicial de bienvenida. Pulse Enter para arrancar, o lea las instrucciones para obtener informaci´on de otros m´etodos y par´ametros para la instalaci´on. 3. Despu´es de unos instantes se le pedir´a que elija su idioma. Use las teclas de desplazamiento para elegirlo y pulse Enter para continuar. Seguidamente se le solicitar´a seleccionar su pa´ıs, las opciones que se muestran incluir´an pa´ıses en donde se habla su idioma. Si su pa´ıs no se encuentra en la lista corta puede acceder a una lista con todos los pa´ıses en el mundo. 4. Puede que necesite confirmar su mapa de teclado. Elija el valor pro- puesto a menos que sepa que no es el adecuado. 5. Ahora si´entese y espere mientras el instalador de Debian detecta su hardware y carga los otros componentes de la instalaci´on desde el DVD. 6. A continuaci´on el instalador intentar´a detectar su hardware de red y configurar la red usando DHCP. Podr´a configurar la red de forma manual si no est´a en una red o no tiene DHCP. 7. Ahora toca particionar sus discos. Primero se le dar´a la oportunidad de particionar autom´aticamente bien el disco entero o bien el espacio libre disponible en su disco (particionado guiado). Esta opci´on es la m´as recomendable para usuarios noveles o alguien con prisa. Escoja la Manual en el men´u si no desea particionado autom´atico. Si tiene una partici´on DOS o Windows que quiera preservar, tenga cuidado con el particionado autom´atico. Si elije particionado manual, puede usar el instalador para redimensionar particiones FAT o NTFS y dejar espacio para la instalaci´on de: simplemente seleccione la partici´on y especifique su nuevo tama˜no. 8. En la siguiente pantalla ver´a su tabla de particiones, c´omo se forma- tear´an las particiones, y d´onde ser´an montadas. Elija una partici´on si desea modificarla o eliminarla. Si ha efectuado un particionado au- tom´atico, solamente se le permitir´a elegir Finalizar particionado en el men´u, para usar lo que se ha definido. Recuerde que debe crear por lo menos una partici´on de intercambio y montar una partici´on en /. 9. Ahora el debian-installer formatea sus particiones y empieza a instalar el sistema base, lo que puede tomar un tiempo. Tras esto se llevar´a a cabo la instalaci´on del n´ucleo. 10. A continuaci´on debe configurar su zona horaria y su reloj. El insta- lador intentar´a seleccionar la configuraci´on autom´aticamente y s´olo le
    • Manual de Usuario 105 preguntar´a si no puede hacerlo. Tras esta configuraci´on se crean las cuentas de usuarios. Por omisi´on, s´olo necesitar´a dar la contrase˜na para la cuenta del usuario root (administrador) y la informaci´on necesaria para crear una cuenta para un usuario normal. 11. El sistema base que se instala al principio es una instalaci´on funcional, pero m´ınima. El paso siguiente le permite instalar paquetes adicionales y seleccionar tareas de forma que el sistema instalado sea m´as operati- vo. Debe configurar apt antes de que se puedan instalar los paquetes, ya que esta configuraci´on define de d´onde se obtendr´an los paquetes. Por omisi´on se instala la tarea del “Sistema est´andar” y es la que generalmente deber´ıa estar instalada. 12. El ´ultimo paso es la instalaci´on del gestor de arranque. El instalador a˜nadir´a autom´aticamente al men´u de arranque y mostrar´a un aviso si detecta otros sistemas operativos en su ordenador. GRUB se instala de forma predeterminada en el sector de arranque del primer disco duro, lo que generalmente es una buena elecci´on. Podr´a cambiarlo e instalarlo en otra ubicaci´on si as´ı lo desea. 13. Ahora el debian-installer le indicar´a que la instalaci´on ha finalizado. Retire el CDROM o el medio que haya utilizado para la instalaci´on y pulse Enter para reiniciar su m´aquina. ´Esta deber´a arrancar en el sistema que acaba de instalar para que pueda acceda al mismo. A.2.2. Instalaci´on de la Aplicaci´on Para instalar glperfex en un sistema que cumpla con las condiciones establecidas en los requisitos de la aplicaci´on existe un paquete deb que rea- lizar´a todo el trabajo (en sistemas tipo Debian). La instalaci´on del paquete se realiza mediante el comando dpkg, de la siguiente manera: # dpkg -i glperfex-1.0_all.deb La desinstalaci´on es an´aloga a la de cualquier programa en Debian, # apt-get remove glperfex. Tambi´en es posible instalar glperfex en siste- mas de empaquetado rpm, utilizado para ello el programa alien que convierte el formato.
    • 106 A.3. Uso de la Aplicaci´on A.3. Uso de la Aplicaci´on A continuaci´on se presentan las instrucciones para realizar correctamente todos los objetivos de uso que contempla glperfex. A.3.1. Abrir Glperfex glperfex est´a accesible en Herramientas del sistema a trav´es del men´u de Aplicaciones de gnome, Figura A.1. Por supuesto, tambi´en puede ser acce- dido a trav´es de l´ınea de comandos, simplemente tecleando glperfex. El resto de la aplicaci´on est´a localizado en /usr/share/glperfex. Figura A.1: Manual de Usuario: abrir glperfex A.3.2. Generar Medici´on con Planificador Est´andar Como adelantamos en la introducci´on, glperfex puede usarse en medicio- nes exclusivas, optimizadas para la medici´on con el menor ruido posible, y mediante el uso del planificador normal del kernel de Linux. Para realizar una medici´on con el Planificador de Linux, basta con se- leccionar en “Modo de Ejecuci´on” la opci´on Normal, como vemos en la Figura A.2, de esta manera, se desactiva la opci´on de elegir el procesador
    • Manual de Usuario 107 Figura A.2: Manual de Usuario: Medici´on con Planificador Est´andar donde ejecutar la tarea, esto se debe a que el planificador de Linux deci- dir´a el reparto de la carga del sistema de acuerdo con su propio criterio. En este mismo panel podemos escoger el n´umero de repeticiones que haremos de la medici´on, entre una y veinte, en “N´umero de Ejecuciones”, y el bina- rio a ejecutar. Este binario debe ser tener una descripci´on parecida a la del Cuadro A.1 al ejecutar el comando file /ruta/nombreejecutable. invitado@karma:~/ruta$ file nombrejecutable nombreejecutable: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped Cuadro A.1: Manual de Usuario: caracter´ısticas v´alidas de un ejecutable Esto nos indica que es un fichero ejecutable, que cumple con el est´andar ELF, y que est´a enlazado din´amicamente y compilado para 32 bits. El eje- cutable puede ser abierto mediante un di´alogo activado al pulsar en el bot´on “...”, o escribiendo su ruta completa. En caso de estar incluido en una car- peta del PATH del sistema, podremos escribir el nombre del ejecutable direc- tamente.
    • 108 A.3. Uso de la Aplicaci´on Una vez hemos realizado la configuraci´on de la ejecuci´on, es momento de seleccionar los contadores a medir, Figura A.3. Figura A.3: Manual de Usuario: Medici´on con Planificador Est´andar La lista de contadores cl´asica incluye los siguiente eventos a medir3: PAPI L1 DCM Level 1 data cache misses PAPI L1 ICM: Level 1 instruction cache misses PAPI L2 DCM: Level 2 data cache misses PAPI L2 ICM: Level 2 instruction cache misses PAPI L1 TCM: Level 1 cache misses PAPI L2 TCM: Level 2 cache misses PAPI CA SHR: Requests for exclusive access to shared cache line PAPI CA CLN: Requests for exclusive access to clean cache line PAPI CA ITV: Requests for cache line intervention 3 Han sido publicados tal y como muestra la salida de lperfex
    • Manual de Usuario 109 PAPI TLB DM: Data translation lookaside buffer misses PAPI TLB IM: Instruction translation lookaside buffer misses PAPI L1 LDM: Level 1 load misses PAPI L1 STM: Level 1 store misses PAPI L2 LDM: Level 2 load misses PAPI L2 STM: Level 2 store misses PAPI BTAC M: Branch target address cache misses PAPI HW INT: Hardware interrupts PAPI BR CN: Conditional branch instructions PAPI BR TKN: Conditional branch instructions taken PAPI BR NTK: Conditional branch instructions not taken PAPI BR MSP: Conditional branch instructions mispredicted PAPI BR PRC: Conditional branch instructions correctly predicted PAPI TOT IIS: Instructions issued PAPI TOT INS: Instructions completed PAPI FP INS: Floating point instructions PAPI BR INS: Branch instructions PAPI RES STL: Cycles stalled on any resource PAPI TOT CYC: Total cycles PAPI L1 DCH: Level 1 data cache hits PAPI L1 DCA: Level 1 data cache accesses PAPI L2 DCA: Level 2 data cache accesses PAPI L2 DCR: Level 2 data cache reads PAPI L2 DCW: Level 2 data cache writes PAPI L1 ICH: Level 1 instruction cache hits PAPI L2 ICH: Level 2 instruction cache hits PAPI L1 ICA: Level 1 instruction cache accesses
    • 110 A.3. Uso de la Aplicaci´on PAPI L2 ICA: Level 2 instruction cache accesses PAPI L1 ICR: Level 1 instruction cache reads PAPI L2 ICR: Level 2 instruction cache reads PAPI L2 TCH: Level 2 total cache hits PAPI L1 TCA: Level 1 total cache accesses PAPI L2 TCA: Level 2 total cache accesses PAPI L2 TCR: Level 2 total cache reads PAPI L2 TCW: Level 2 total cache writes PAPI FML INS: Floating point multiply instructions PAPI FDV INS: Floating point divide instructions PAPI FP OPS: Floating point operations Una vez seleccionados los contadores necesarios, pulsamos en el bot´on “Ejecutar Test” y se generar´an los resultados. Si hemos seleccionado s´olo una ejecuci´on, aparecer´an los resultados con el aspecto de la Figura A.4, con m´as de una ejecuci´on se generar´a una gr´afica comparativa, tal y como se aprecia en la Figura A.5. A.3.3. Generar Medici´on Exclusiva Como caso alternativo de medici´on contemplamos la medici´on exclusi- va, lanzando el programa a ejecutar como un proceso de tiempo real. La selecci´on de este caso se realiza en el mismo apartado que realizamos la me- dici´on est´andar, es decir, seleccionamos en la pesta˜na de Configuraci´on, en el cuadro “Modo de Ejecuci´on”, Exclusiva, Figura A.6. Como observamos al pulsar la opci´on, ahora s´ı se nos permite seleccionar el procesador donde lanzar el programa. El funcionamiento es el siguiente: Al seleccionar una CPU solamente, el sistema lanzar´a la tarea de forma exclusiva sobre ese procesador. Al seleccionar m´as de una CPU, RTAI decidir´a d´onde se lanzar´a de forma exclusiva el proceso dependiendo de la carga de tareas en tiempo real. El resto del proceso es an´alogo al de la medici´on est´andar, por lo que simplemente se sigue el proceso del apartado .
    • Manual de Usuario 111 Figura A.4: Manual de Usuario: Medici´on con Planificador Est´andar 1 A.3.4. Guardar Resultados de una Medici´on Una vez generada una medici´on, como ser´ıa el caso de la Figuras A.4 y A.5, glperfex nos permite guardar los resultados de la misma en un fichero de formato CSV4. Este formato es compatible con la mayor´ıa de hojas de c´alculo del mercado (incluyendo OpenOffice.org Calc y Microsoft Office), por lo que trabajar con los resultados de las mediciones ser´a sencillo. Para guardar la medici´on accederemos a la opci´on Guardar Resultado del men´u “Archivo”, tal y como podemos ver en la Figura A.7. Despu´es, se nos abrir´a un di´alogo donde simplemente especificaremos la ruta donde almacenar el fichero y el nombre que deseemos darle. A.3.5. Guardar Gr´afica de una Medici´on Del mismo modo que vimos en el apartado anterior, al generarse una gr´afica podemos guadar la misma para utilizarla con posterioridad en alg´un documento. Gracias a la biblioteca utilizada para generarla, la imagen puede 4 M´as informaci´on acerca del formato CSV http://en.wikipedia.org/wiki/Comma- separated values
    • 112 A.3. Uso de la Aplicaci´on Figura A.5: Manual de Usuario: Resultados con Planificador Est´andar 2 ser almacenada en una gran cantidad de formatos conocidos, entre los que se incluyen png, jpg o gif. Para guardar la medici´on accederemos a la opci´on Guardar Gr´afica del men´u “Archivo”, tal y como podemos ver en la Figura A.7. Despu´es, se nos abrir´a un di´alogo donde simplemente especificaremos la ruta donde almacenar la gr´afica y el nombre que deseemos darle. Es importante recal- car de nuevo que en mediciones donde s´olo se realice una repetici´on, no se permitir´a guardar la gr´afica al no haber sido generada. A.3.6. Cargar una Medici´on Previa Como resultado de la opci´on de copia de las mediciones que se descri- bi´o en el apartado A.3.4, glperfex incluye una ´ultima opci´on de uso que permite cargar en el programa una medici´on realizada con anterioridad. Para abrir un resultado, accederemos tal y como hicimos en las dos opciones de guardar al men´u “Archivo”, y accedemos a la opci´on Abrir. Una vez ah´ı se nos pedir´a la ruta del fichero y el nombre, carg´andose al seleccionar el mismo en el panel de resultados de la ´ultima pesta˜na, tal y como si se hubiera realizado una nueva medici´on.
    • Manual de Usuario 113 Figura A.6: Manual de Usuario: Ejecuci´on en Modo Exclusivo Esta opci´on ser´a ´util cuando queramos comparar in situ ejecuciones de un mismo programa. A.4. Ayuda y Licencia Toda la informaci´on de ayuda, as´ı como los cr´editos e informaci´on de contacto, y la licencia del programa est´a disponible en el men´u “Ayuda”, junto al men´u de archivo que ve´ıamos en las figuras anteriores. glperfex es software libre bajo licencia GNU GPL v3, por lo tanto, cum- ple con la libertad 0 de la definici´on de software libre: “Libertad para usar (ejecutar) el programa, con cualquier prop´osito”. En el manual de usuario, debido al ´ambito sobre el que se enfoca la redacci´on del texto, ´esta ser´ıa la ´unica libertad a nombrar, sin embargo, si el usuario desea seguir investigan- do, y hacerse part´ıcipe de las tres libertades restantes: 1. La libertad de estudiar c´omo funciona el programa, y adaptarlo a las necesidades necesidades. El acceso al c´odigo fuente es una condici´on previa para esto.
    • 114 A.4. Ayuda y Licencia Figura A.7: Manual de Usuario: Men´u Archivo 2. La libertad de distribuir copias, para ayudar a la comunidad. 3. La libertad de mejorar el programa y hacer p´ublicas las mejoras a los dem´as, de modo que toda la comunidad se beneficie. El acceso al c´odigo fuente es un requisito previo para esto. Puede encontrar toda la informaci´on y c´odigo fuente necesarios en http://consejo-eps.uco.es/karma.
    • Ap´endice B Manual de C´odigo El siguiente documento presenta la documentaci´on de c´odigo de la apli- caci´on glperfex, interfaz sencilla para lperfex, aplicaci´on para la medici´on no intrusiva de eventos de procesador. La documentaci´on ha sido generada utilizando el programa Doxygen. Doxygen es un generador de documentaci´on para C++, C, Java, Objective- C, Python, IDL (versiones Corba y Microsoft) y en cierta medida para PHP, C# y D. Funciona en la mayor´ıa de sistemas Unix as´ı como en Windows y MacOS X. Est´a licenciado bajo la licencia de GNU GPL v2 y es utiliza- do por infinidad de aplicaciones de software libre para la generaci´on de su documentaci´on, entre ellas destacan: Abiword. ALSA (Advanced Linux Sound Architecture Project). Kdevelop y muchos otros proyectos de KDE. MediaWiki MySQL. Pidgin. ReactOS. Samba. ScummVM. 115
    • 116 B.1. Referencia de la Clase glperfex::MainFrame La organizaci´on de la documentaci´on es sencilla, se ir´an exponiendo or- denadamente cada una de las siete clases del programa, enumerando sus atributos p´ublicos m´as importantes y realizando un an´alisis comentado de los m´etodos acompa˜nados de su c´odigo. B.1. Referencia de la Clase glperfex::MainFrame Clase que contiene el marco principal de la aplicaci´on gr´afica, dentro de ´el se activar´an las pesta˜nas donde se configuran las diferentes opciones del programa expresadas en pesta˜nas. M´etodos p´ublicos def init Constructor de la clase MainFrame ( p. 116). def GetAndSendSelections Este m´etodo recoge las selecciones que se han realizado y comprueba si se puede proceder a aplicar la medici´on. def OnOpen Este m´etodo abre los resultados que est´an almacenados en alg´un fichero. def OnSave Este m´etodo guarda los resultados de la ejecuci´on en caso de haber sido generados estos. def OnSaveDraw Este m´etodo guarda la gr´afica despu´es de comprobar si ´esta ha sido gene- rada. def OnAbout Este m´etodo construye la ventana de About, donde podremos consultar los autores de la aplicaci´on as´ı como su licencia completa. def OnExit Este metodo cierra la ventana.
    • Manual de C´odigo 117 Atributos p´ublicos file help menubar runButton icon nb config counters stats B.1.1. Descripci´on detallada Clase que contiene el marco principal de la aplicaci´on gr´afica, dentro de ´el se activar´an las pesta˜nas donde se configuran las diferentes opciones del programa expresadas en pesta˜nas. Es decir, la pesta˜na de Configuraci´on, clase Configuration, la pesta˜na de Contadores, clase Counters y la pesta˜na de Resultados, clase Results. Par´ametros: wx.Frame Hereda de la clase wx.Frame Definici´on en la l´ınea 27 del archivo glperfex.py. B.1.2. Documentaci´on de las funciones miembro B.1.2.1. def glperfex::MainFrame:: init ( self) Constructor de la clase MainFrame (p. 116). Par´ametros: self Puntero al objeto actual. Definici´on en la l´ınea 31 del archivo glperfex.py. 31 : 32 # Iniciamos la clase de la que hereda MainFrame
    • 118 B.1. Referencia de la Clase glperfex::MainFrame 33 wx.Frame.__init__(self,None,wx.ID_ANY,title="Glperfex", size = (600,400), 34 style = wx.DEFAULT_FRAME_STYLE | wx.NO_FULL_REPAINT_ON_RESIZE) 35 36 # Barra de Estatus 37 self.CreateStatusBar() 38 39 # Creamos el menu con sus submenus 40 # Men´u Archivo 41 42 self.file = wx.Menu() 43 44 # Opci´on de abrir fichero 45 openFile = wx.MenuItem(self.file, 101, ’&AbrirtCtrl+O’) 46 openFile.SetBitmap(wx.Bitmap(’/usr/share/glperfex/icons/fileopen.png’)) 47 self.file.AppendItem(openFile) 48 49 # Opci´on de guardar resultado de mediciones 50 saveFile = wx.MenuItem(self.file, 102, ’&Guardar ResultadotCtrl+S’) 51 saveFile.SetBitmap(wx.Bitmap(’/usr/share/glperfex/icons/filesave.png’)) 52 self.file.AppendItem(saveFile) 53 54 # Opci´on de guardar la gr´afica generada 55 saveGraphic = wx.MenuItem(self.file, 105, ’&Guardar Gr´aficatCtrl+G’) 56 saveGraphic.SetBitmap(wx.Bitmap(’/usr/share/glperfex/icons/filesaveas.png’)) 57 self.file.AppendItem(saveGraphic) 58 59 self.file.AppendSeparator() 60 61 quit = wx.MenuItem(self.file, 103, ’&SalirtCtrl+Q’) 62 quit.SetBitmap(wx.Bitmap(’/usr/share/glperfex/icons/exit.png’)) 63 self.file.AppendItem(quit) 64 65 # Men´u Ayuda 66 67 self.help = wx.Menu() 68 69 about = wx.MenuItem(self.file, 104, ’&Acerca &de’) 70 about.SetBitmap(wx.Bitmap(’/usr/share/glperfex/icons/help-about.png’)) 71 self.help.AppendItem(about) 72 73 self.menubar = wx.MenuBar() 74 self.menubar.Append(self.file, "&Archivo") 75 self.menubar.Append(self.help, "Ay&uda") 76 self.SetMenuBar(self.menubar) 77 self.runButton = wx.Button(self, -1, "Ejecutar Test") 78 self.runButton.SetMinSize((160,27)) 79 80 # Establecemos el icono de la aplicaci´on. 81 self.icon = wx.EmptyIcon() 82 self.icon.CopyFromBitmap(wx.Bitmap("/usr/share/glperfex/icons/glperfex.png", wx.BITMAP_TYPE_ANY)) 83 self.SetIcon(self.icon) 84
    • Manual de C´odigo 119 85 86 87 # Hacemos bind con las funciones que queremos ejecutar en el men´u. 88 self.Bind(wx.EVT_MENU, self.OnOpen, id = 101) 89 self.Bind(wx.EVT_MENU, self.OnSave, id = 102) 90 self.Bind(wx.EVT_MENU, self.OnExit, id =103) 91 self.Bind(wx.EVT_MENU, self.OnAbout, id=104) 92 self.Bind(wx.EVT_MENU, self.OnSaveDraw, id=105) 93 94 # Creamos el NoteBook donde se introducir´an los diferentes paneles. 95 self.nb = wx.Notebook(self,-1,style=0) 96 97 # Creamos las p´aginas de nuestro NoteBook, con los tres paneles cada uno en una 98 # pesta~na. 99 self.config = configuracion.Configuration(self.nb) 100 self.counters = contadores.Counters(self.nb) 101 self.stats = resultados.Results(self.nb) 102 103 104 # A~nadimos las p´aginas al NoteBook 105 self.nb.AddPage(self.config, "Configuraci´on") 106 self.nb.AddPage(self.counters, "Contadores") 107 self.nb.AddPage(self.stats, "Resultados") 108 109 # Finalmente introducimos el NoteBook 110 sizer = wx.BoxSizer(wx.VERTICAL) 111 sizer.Add(self.nb, 1, wx.EXPAND) 112 sizer.Add(self.runButton, 0, wx.ALIGN_BOTTOM|wx.ALIGN_CENTER_HORIZONTAL| wx.ADJUST_MINSIZE, 0) 113 self.SetSizer(sizer) 114 115 self.Bind(wx.EVT_BUTTON, self.GetAndSendSelections, id=self.runButton.GetId()) 116 ## Este m´etodo recoge las selecciones que se han realizado y comprueba si se puede proceder a aplicar la medici´on. B.1.2.2. def glperfex::MainFrame::GetAndSendSelections ( self, event) Este m´etodo recoge las selecciones que se han realizado y comprueba si se puede proceder a aplicar la medici´on. Par´ametros: self Puntero al objeto actual. event Evento que activa el m´etodo al accionarse en el panel. Definici´on en la l´ınea 120 del archivo glperfex.py.
    • 120 B.1. Referencia de la Clase glperfex::MainFrame 120 : 121 122 # Se recogen los contadores seleccionados de la pesta~na de Contadores 123 listofCounters = self.counters.GetSelectedCountersList() 124 # Se recogen las selecciones de la pesta~na de Configuraci´on 125 tupleofCommands = self.config.GetCommand() 126 127 # No existe ning´un fichero binario 128 if tupleofCommands == "empty": 129 dial = wx.MessageDialog(None, ’No ha sido introducido ning´un fichero binario’, 130 ’Aviso’, wx.OK | wx.ICON_EXCLAMATION) 131 dial.ShowModal() 132 dial.Destroy() 133 134 #El fichero introducido no es un binario v´alido 135 elif tupleofCommands == "invalid": 136 dial = wx.MessageDialog(None, ’El fichero introducido no es un binario v´alido’, 137 ’Aviso’, wx.OK | wx.ICON_EXCLAMATION) 138 dial.ShowModal() 139 dial.Destroy() 140 141 # No se ha seleccionado ning´un contador. 142 elif len(listofCounters) == 0: 143 dial = wx.MessageDialog(None, ’No ha sido seleccionado ning´un Contador’, 144 ’Aviso’, wx.OK | wx.ICON_EXCLAMATION) 145 dial.ShowModal() 146 dial.Destroy() 147 148 # Caso correcto, se incia la ejecuci´on con el comando fabricado y se limpia el comando 149 # y se env´ıan los resultados a la Pesta~na de Resultados. 150 else: 151 commandDict = {} 152 i = 0 153 for element in listofCounters: 154 com = ("lperfex -e " + listofCounters[i] + " " + tupleofCommands[0] + " " + 155 tupleofCommands[1] + " -- ", tupleofCommands[2]) 156 commandDict[listofCounters[i]] = com 157 i = i + 1 158 159 self.stats.SetList(commandDict) 160 161 self.stats.SetResults(1) 162 ## Este m´etodo abre los resultados que est´an almacenados en alg´un fichero. B.1.2.3. def glperfex::MainFrame::OnOpen ( self, event) Este m´etodo abre los resultados que est´an almacenados en alg´un fichero.
    • Manual de C´odigo 121 Par´ametros: self Puntero al objeto actual. event Evento que activa el m´etodo al accionarse en el panel. Definici´on en la l´ınea 166 del archivo glperfex.py. 166 : 167 168 dlg = wx.FileDialog(self, "Abrir", os.getcwd(), "", "*.csv", wx.OPEN) 169 if dlg.ShowModal() == wx.ID_OK: 170 #Metemos la ruta en el bot´on de comandos 171 self.stats.Load(dlg.GetPath()) 172 self.stats.SetResults(2) 173 dlg.Destroy() 174 ## Este m´etodo guarda los resultados de la ejecuci´on en caso de haber sido generados estos. B.1.2.4. def glperfex::MainFrame::OnSave ( self, event) Este m´etodo guarda los resultados de la ejecuci´on en caso de haber sido generados estos. Par´ametros: self Puntero al objeto actual. event Evento que activa el m´etodo al accionarse en el panel. Definici´on en la l´ınea 178 del archivo glperfex.py. 178 : 179 180 if self.stats.generated: 181 dlg = wx.FileDialog(self,"Guardar", os.getcwd(), ".csv","*.csv", wx.SAVE) 182 if dlg.ShowModal() == wx.ID_OK: 183 self.stats.Get(dlg.GetPath()) 184 dlg.Destroy() 185 else: 186 dial = wx.MessageDialog(None, ’A´un no ha sido generado ning´un resultado’, 187 ’Aviso’, wx.OK | wx.ICON_EXCLAMATION) 188 dial.ShowModal() 189 dial.Destroy() 190 ## Este m´etodo guarda la gr´afica despu´es de comprobar si ´esta ha sido generada.
    • 122 B.1. Referencia de la Clase glperfex::MainFrame B.1.2.5. def glperfex::MainFrame::OnSaveDraw ( self, event) Este m´etodo guarda la gr´afica despu´es de comprobar si ´esta ha sido generada. Par´ametros: self Puntero al objeto actual. event Evento que activa el m´etodo al accionarse en el panel. Definici´on en la l´ınea 194 del archivo glperfex.py. 194 : 195 if self.stats.GetDraw(""): 196 pass 197 198 else: 199 dial = wx.MessageDialog(None, ’A´un no ha sido generada ninguna gr´afica’, ’Aviso’, 200 wx.OK | wx.ICON_EXCLAMATION) 201 dial.ShowModal() 202 dial.Destroy() 203 204 ## Este m´etodo construye la ventana de About, donde podremos consultar los autores de la aplicaci´on as´ı como su licencia completa B.1.2.6. def glperfex::MainFrame::OnAbout ( self, event) Este m´etodo construye la ventana de About, donde podremos consultar los autores de la aplicaci´on as´ı como su licencia completa. Par´ametros: self Puntero al objeto actual. event Evento que activa el m´etodo al accionarse en el panel. Definici´on en la l´ınea 208 del archivo glperfex.py. 208 : 209 210 description = """ 211 Glperfex es una interfaz de usuario simple a 212 lperfex, una aplicaci´on para la medici´on de eventos a 213 trav´es de Performance API (PAPI) de procesador usando
    • Manual de C´odigo 123 214 el planificador de Linux o RTAI. 215 216 Glperfex y Lperfex fueron concebidos como herramientas 217 de trabajo para la distribuci´on Karma GNU/Linux, 218 Proyecto Fin de Carrera para Ingenier´ıa T´ecnica en 219 Inform´atica de Sistemas, cursada en la Escuela 220 Polit´ecnica Superior de la Universidad de C´ordoba. 221 """ 222 # Se obtiene la licencia del fichero COPYING 223 fp = open(’COPYING’,’r’) 224 225 if fp: 226 licence = fp.read() 227 else: 228 licence = "Puede descargar una copia de GNU GPL v3 en http://www.gnu.org/licenses/gpl.html" 229 230 231 info = wx.AboutDialogInfo() 232 233 info.SetIcon(wx.Icon(’/usr/share/glperfex/icons/glperfex.png’, wx.BITMAP_TYPE_PNG)) 234 info.SetName(’Glperfex’) 235 info.SetVersion(’1.0’) 236 info.SetDescription(description) 237 info.SetCopyright(’(C) 2008 Fernando Garc´ıa ArandanPedro Navajas Modelo’) 238 info.SetWebSite(’http://consejo-eps.uco.es/karma’) 239 info.SetLicence(licence) 240 info.AddDeveloper(’Fernando Garc´ıa Arandanfernando@consejo-eps.uco.esn nPedro Navajas Modelongod4saken@gmail.com’) 241 info.AddDocWriter(’Fernando Garc´ıa Arandanfernando@consejo-eps.uco.es’) 242 243 244 wx.AboutBox(info) 245 ## Este metodo cierra la ventana B.1.2.7. def glperfex::MainFrame::OnExit ( self, event) Este metodo cierra la ventana. Par´ametros: self Puntero al objeto actual. event Evento que activa el m´etodo al accionarse en el panel. Definici´on en la l´ınea 249 del archivo glperfex.py. 249 :
    • 124 B.2. Referencia de la Clase configuracion::Configuration 250 251 self.Close(True) 252 253 254 if __name__ == "__main__": La documentaci´on para esta clase fue generada a partir del siguiente fichero: glperfex.py B.2. Referencia de la Clase configura- cion::Configuration Desde esta clase se muestran las opciones de Configuraci´on de la ejecu- ci´on de lperfex. M´etodos p´ublicos def init Constructor de la Clase Configuration ( p. 124). def OpenFile Este m´etodo abre un di´alogo para abrir un fichero, en este caso el ejecu- table de la medici´on. def EnableOrDisableCheckboxes Este m´etodo habilita las Checkboxes que se˜nalan la posibildad de elegir el procesador, o procesadores donde ejecutaremos el proceso a medir en funci´on de si hemos elegido el modo normal (0), que deshabilita, o uno distinto de cero, que habilita las Checkboxes. def GetCommand Este m´etodo trata el Comando que ser´a enviado. Atributos p´ublicos io executionMode
    • Manual de C´odigo 125 cpusnum listofCheckBoxes label sc1 label2 executable browseButton command B.2.1. Descripci´on detallada Desde esta clase se muestran las opciones de Configuraci´on de la ejecu- ci´on de lperfex. Es decir las antiguas opciones de lperfex -x, lperfex -s y lperfex -sx. Adem´as de ello se le une a esta cadena el fichero ejecutable (debe ser un binario enlazado con la libc) que ser´a ejecutado. Se trata de un Panel en la ventana principal (MainFrame) de Glperfex. Par´ametros: wx.Panel Hereda de la clase wx.Panel Definici´on en la l´ınea 24 del archivo configuracion.py. B.2.2. Documentaci´on de las funciones miembro B.2.2.1. def configuracion::Configuration:: init ( self, parent) Constructor de la Clase Configuration (p. 124). Par´ametros: self Puntero al objeto actual. parent Puntero al objeto padre. Definici´on en la l´ınea 29 del archivo configuracion.py. 29 : 30 31
    • 126 B.2. Referencia de la Clase configuracion::Configuration 32 # Iniciamos la clase de las que hereda la clase Configuration, es decir wx.Panel 33 wx.Panel.__init__(self, parent) 34 35 # 36 self.io = io.IOInterface() 37 38 #Modo de Ejecuci´on del binario 39 executionList = [’Normal’, ’Exclusiva’] 40 self.executionMode = wx.RadioBox(self, -1, "Modo de Ejecuci´on", (10, 10), wx.DefaultSize, 41 executionList, 2, 2) 42 43 44 # Se recoge el n´umero de CPUs de la m´aquina sobre la que se ejecuta el programa 45 46 self.cpusnum = num = os.sysconf(’SC_NPROCESSORS_ONLN’) 47 48 49 # Construimos la static box dependiendo del n´umero de CPUs de la m´aquina 50 if self.cpusnum <= 2: 51 wx.StaticBox(self, -1, ’CPUs Activas’, (150, 10), size=(100, 67)) 52 53 elif self.cpusnum % 2 == 0: 54 wx.StaticBox(self, -1, ’CPUs Activas’, (150, 10), size=(77* (self.cpusnum/2), 67)) 55 else: 56 wx.StaticBox(self, -1, ’CPUs Activas’, (150, 10), size=(77* (self.cpusnum/2 + 1), 67)) 57 58 # Imprimimos por pantalla las CheckBoxes correspondientes a los procesadores de la 59 # m´aquina en filas de 2 60 61 self.listofCheckBoxes = [] 62 i = 0 63 x = 160 64 while i < self.cpusnum: 65 y = 26 66 j = 0 67 while j < 2 and self.cpusnum != i: 68 label = "CPU " + str(i) 69 self.listofCheckBoxes.append(wx.CheckBox(self, -1 ,label, (x,y))) 70 y += 26 71 i += 1 72 j += 1 73 x += 70 74 75 # Activamos o desactivamos las CheckBoxes dependiendo de si hemos escogido ejecuci´on 76 # en modo exclusivo o modo normal, ya que en modo normal el planificador del kernel 77 # de linux actuar´a a su modo.
    • Manual de C´odigo 127 78 79 if self.executionMode.GetSelection() == 0: 80 for i in self.listofCheckBoxes: 81 i.Disable() 82 83 84 85 wx.StaticBox(self, -1, ’Configuraci´on para la Ejecuci´on’, (10, 95), size=(430, 100)) 86 87 88 # N´umero de ejecuciones, se permite entre 1 y 20 89 90 self.label = wx.StaticText(self,-1," N´umero de Ejecuciones",(15,125)) 91 self.sc1 = wx.SpinCtrl(self, -1, ’’, (180, 120), (60, -1), min=1, max=20) 92 93 94 # Se recoge el nombre del binario a ejecutar, ya sea por cuadro de texto (label2) 95 # o a trav´es del dato que nos da el browseButton. 96 97 self.label2 = wx.StaticText(self, -1, " Binario a Ejecutar",(15,160)) 98 self.executable = wx.TextCtrl(self, -1,"", (140,155),(260, 27)) 99 self.browseButton = wx.Button(self, -1, "...",(400,155),(27,27)) 100 101 # Enlazamos las funciones de abrir fichero al browseButton y de activar o desactivar 102 # dependiendo de si cambiamos la selecci´on de la RADIOBOX. 103 104 self.Bind(wx.EVT_BUTTON, self.OpenFile, id=self.browseButton.GetId()) 105 self.Bind(wx.EVT_RADIOBOX, self.EnableOrDisableCheckboxes, id=self.executionMode.GetId()) 106 107 108 self.command = ("","") 109 ## Este m´etodo abre un di´alogo para abrir un fichero, en este caso el ejecutable B.2.2.2. def configuracion::Configuration::OpenFile ( self, event) Este m´etodo abre un di´alogo para abrir un fichero, en este caso el ejecu- table de la medici´on. El di´alogo es el di´algo est´andar que nos proporciona wxPython. Par´ametros: self Puntero al objeto actual. event Evento que activa el m´etodo al accionarse en el panel.
    • 128 B.2. Referencia de la Clase configuracion::Configuration Definici´on en la l´ınea 114 del archivo configuracion.py. 114 : 115 116 dlg = wx.FileDialog(self, "Choose a file", os.getcwd(), "", "*", wx.OPEN) 117 if dlg.ShowModal() == wx.ID_OK: 118 self.executable.SetValue(dlg.GetPath()) #Metemos la ruta en el bot´on de comandos 119 dlg.Destroy() 120 121 ## Este m´etodo habilita las Checkboxes que se~nalan la posibildad de elegir el procesador, B.2.2.3. def configura- cion::Configuration::EnableOrDisableCheckboxes ( self, event) Este m´etodo habilita las Checkboxes que se˜nalan la posibildad de elegir el procesador, o procesadores donde ejecutaremos el proceso a medir en funci´on de si hemos elegido el modo normal (0), que deshabilita, o uno distinto de cero, que habilita las Checkboxes. Par´ametros: self Puntero al objeto actual. event Evento que activa el m´etodo al accionarse en el panel. Definici´on en la l´ınea 127 del archivo configuracion.py. 127 : 128 129 130 if self.executionMode.GetSelection() == 0: 131 for i in self.listofCheckBoxes: 132 i.Disable() 133 else: 134 for i in self.listofCheckBoxes: 135 i.Enable() 136 ## Este m´etodo trata el Comando que ser´a enviado. Primero se obtendr´a el valor que hay B.2.2.4. def configuracion::Configuration::GetCommand ( self) Este m´etodo trata el Comando que ser´a enviado.
    • Manual de C´odigo 129 Primero se obtendr´a el valor que hay registrado en el campo del texto. Despu´es se comprobar´a si est´a vac´ıo. En caso de tener barras se comprueba que exista y sea un fichero ejecutable con el m´etodo de la clase IOInterface CheckExecutableFile, si no tiene barras, se buscar´a si est´a en el PATH y extraer´a su directorio y someti´endolo entonces al mismo proceso de compro- baci´on que de las barras. Posteriormente recoger´a los datos escogidos en el resto de los paneles y devolver´a una tupla con los datos. Par´ametros: self Puntero al objeto actual. Devuelve: ”invalid” En caso de que el fichero a ejecutar no sea v´alido ”empty” En caso de que no se haya introducido un fichero a ejecutar. (mode,nexecutions,str(executable)) En caso en que todo salga correcto, devuelve una tupla de tres elementos, con el modo de ejecuci´on escogido, el n´umero de ejecuciones, y la direcci´on del ejecutable. Definici´on en la l´ınea 150 del archivo configuracion.py. 150 : 151 152 153 executable = self.executable.GetValue() 154 155 # Si el fichero ejecutable que nos introduce el usuario est´a vac´ıo se devuelve 156 # la cadena "empty" 157 if executable == "" : 158 return "empty" 159 160 # En caso de tener los directorios completos, comprobamos con la clase de IO 161 # que sea un ejecutable correcto 162 elif ’/’ in executable: 163 if self.io.CheckExecutableFile(executable) == False: 164 return "invalid" 165 166 # En caso de no tener barras, habr´a que extraer el directorio y el nombre del 167 # fichero con el m´etodo DividePath, cuando lo tengamos habr´a que comprobar 168 # como en el caso anterior que el fichero es un ejecutable correcto. 169 elif ’/’ not in executable: 170 returnedValue = self.io.DividePath(executable) 171 directory = returnedValue[0] 172 filename = returnedValue[1]
    • 130 B.3. Referencia de la Clase contadores::Counters 173 if self.io.CheckExecutableFile(directory + filename) == False: 174 return "invalid" 175 176 # Se recoge el modo de ejecuci´on, si es Normal se pone "" en la opci´on 177 if self.executionMode.GetSelection() == 0: 178 mode = "" 179 180 # En caso contrario el modo de ejecuci´on ser´a exclusivo "-x" y por defecto 181 # ejecutaremos si no hay nada ejecutado la CPU 0, es decir pondremos un 1 182 # en el par´ametro. 183 else: 184 mode = "-x" 185 ncpusallowed = 1 186 187 #En caso de haber una selecci´on se realiza el siguiente algoritmo para 188 #introducir el par´ametro necesario por glperfex 189 for i in range(self.cpusnum): 190 if(self.listofCheckBoxes[i].GetValue()): 191 ncpusallowed += pow(2,i) 192 if(ncpusallowed == 0): 193 ncpusallowed = 1 194 195 # El modo ser´a -n numerodecpus 196 mode += " -n " + str(ncpusallowed) 197 198 # Se recoge el n´umero de ejecuciones a realizar 199 nexecutions = "-s " + str(self.sc1.GetValue()) 200 201 # Si todo ha salido bien devolvemos la tupla con el modo de ejecuci´on, el n´umero 202 # de ejecuciones y el nombre del fichero ejecutable con su ruta completa 203 return mode, nexecutions, str(executable) 204 La documentaci´on para esta clase fue generada a partir del siguiente fichero: configuracion.py B.3. Referencia de la Clase contadores::Counters Desde esta clase se muestran los contadores que pueden ser medidos en la Ejecuci´on.
    • Manual de C´odigo 131 M´etodos p´ublicos def init Constructor de la Clase Counters ( p. 130). def OnSelect Este m´etodo controla la selecci´on de los distintos contadores. def OnSelectAll Este m´etodo selecciona todos los contadores de la lista. def OnSelectNone Este m´etodo borra todos los contadores de la lista. def GetSelectedCountersList Este obtiene los elementos seleccionados de la lista. Atributos p´ublicos io selectedCountersList list B.3.1. Descripci´on detallada Desde esta clase se muestran los contadores que pueden ser medidos en la Ejecuci´on. Una vez el usuario ha observado dichos contadores puede seleccionar aquellos que desee medir. Se trata de un Panel en la ventana principal (Main- Frame) de Glperfex. Par´ametros: wx.Panel Hereda de la clase wx.Panel Definici´on en la l´ınea 30 del archivo contadores.py.
    • 132 B.3. Referencia de la Clase contadores::Counters B.3.2. Documentaci´on de las funciones miembro B.3.2.1. def contadores::Counters:: init ( self, parent) Constructor de la Clase Counters (p. 130). Par´ametros: self Puntero al objeto actual. parent Puntero al objeto padre. Definici´on en la l´ınea 35 del archivo contadores.py. 35 : 36 37 # Se llama a la clase padre, para iniciar el constructor de la misma. 38 wx.Panel.__init__(self, parent) 39 40 #Objeto de la clase IO. 41 self.io = io.IOInterface() 42 43 # Cajas verticales y horizontales. 44 vbox = wx.BoxSizer(wx.VERTICAL) 45 hbox = wx.BoxSizer(wx.HORIZONTAL) 46 47 # Se construyen los panels de la izquierda y la derecha. 48 leftPanel = wx.Panel(self, -1) 49 rightPanel = wx.Panel(self, -1) 50 51 # Incializamos la lista de Contadores Seleccionados. 52 self.selectedCountersList = [] 53 54 self.list = CheckListCtrl(rightPanel) 55 self.list.InsertColumn(0, ’Contador’, width=140) 56 self.list.InsertColumn(1, ’Descripci´on’, width=400) 57 58 59 # Colocamos el nombre del Contador, desde el dicconario de Contadores 60 # y lo introducimos en la columna 0 y en la columna 1 introducimos la 61 # descripci´on. 62 for key in self.io.dictofCounters: 63 index = self.list.InsertStringItem(0,key) 64 self.list.SetStringItem(index,1, self.io.dictofCounters[key]) 65 66 # Creamos una nueva caja de divisi´on 67 vbox2 = wx.BoxSizer(wx.VERTICAL) 68 69 # Creamos los botones para Seleccionar Todo o seleccionar nada. 70 sel = wx.Button(leftPanel, -1, ’Selec. Todo’, size=(100, -1)) 71 des = wx.Button(leftPanel, -1, ’Selec. Nada’, size=(100, -1))
    • Manual de C´odigo 133 72 73 # Asignamos los botones creados al m´etodo que les corresponde. 74 self.Bind(wx.EVT_BUTTON, self.OnSelectAll, id=sel.GetId()) 75 self.Bind(wx.EVT_BUTTON, self.OnSelectNone, id=des.GetId()) 76 self.Bind(wx.EVT_LIST_ITEM_ACTIVATED, self.OnSelect) 77 78 # A~nadimos los botones a la caja de divisi´on que acabamos de crear 79 vbox2.Add(sel, 0, wx.TOP, 5) 80 vbox2.Add(des) 81 82 # Introducimos la caja de divisi´on en el panel de la izquierda. 83 leftPanel.SetSizer(vbox2) 84 85 # A~nadimos la lista donde introdujimos los contadores y la descripci´on 86 # a la caja vbox. 87 vbox.Add(self.list, 1, wx.EXPAND | wx.TOP, 3) 88 89 # A~nadimos la caja vbox al panel de la derecha. 90 rightPanel.SetSizer(vbox) 91 92 # A~nadimos los paneles de la izquierda y derecha a la caja principal 93 # que establecer´a primero el de la izquierda y segundo el de la derecha 94 # a su derecha 95 hbox.Add(leftPanel, 0, wx.EXPAND | wx.RIGHT, 5) 96 hbox.Add(rightPanel, 1, wx.EXPAND) 97 hbox.Add((3, -1)) 98 99 # Colocamos la hbox en el panel y ya tenemos el Frame. 100 self.SetSizer(hbox) 101 102 self.Centre() 103 self.Show(True) 104 105 ## Este m´etodo controla la selecci´on de los distintos contadores. B.3.2.2. def contadores::Counters::OnSelect ( self, event) Este m´etodo controla la selecci´on de los distintos contadores. Si no est´a seleccionado y se activa se selecciona y viceversa. Par´ametros: self Puntero al objeto actual. event Evento que activa el m´etodo al accionarse en el panel. Definici´on en la l´ınea 110 del archivo contadores.py.
    • 134 B.3. Referencia de la Clase contadores::Counters 110 : 111 selectedElement = self.list.GetFirstSelected() 112 113 if self.list.IsChecked(selectedElement): 114 self.list.CheckItem(selectedElement,False) 115 else: 116 self.list.CheckItem(selectedElement) 117 118 B.3.2.3. def contadores::Counters::OnSelectAll ( self, event) Este m´etodo selecciona todos los contadores de la lista. Par´ametros: self Puntero al objeto actual. event Evento que activa el m´etodo al accionarse en el panel. Definici´on en la l´ınea 122 del archivo contadores.py. 122 : 123 num = self.list.GetItemCount() 124 for i in range(num): 125 self.list.CheckItem(i) 126 ## Este m´etodo borra todos los contadores de la lista. B.3.2.4. def contadores::Counters::OnSelectNone ( self, event) Este m´etodo borra todos los contadores de la lista. Par´ametros: self Puntero al objeto actual. event Evento que activa el m´etodo al accionarse en el panel. Definici´on en la l´ınea 130 del archivo contadores.py. 130 : 131 num = self.list.GetItemCount() 132 for i in range(num): 133 self.list.CheckItem(i, False) 134 ## Este obtiene los elementos seleccionados de la lista.
    • Manual de C´odigo 135 B.3.2.5. def contadores::Counters::GetSelectedCountersList ( self) Este obtiene los elementos seleccionados de la lista. Par´ametros: self Puntero al objeto actual. Devuelve: self.selectedCountersList Devuelve una lista con los nombres de los con- tadores seleccionados Definici´on en la l´ınea 138 del archivo contadores.py. 138 : 139 num = self.list.GetItemCount() 140 self.selectedCountersList = [] 141 for i in range(num): 142 if i == 0: self.selectedCountersList = [] 143 if self.list.IsChecked(i): 144 self.selectedCountersList.append(str (self.list.GetItemText(i))) 145 return self.selectedCountersList 146 147 148 ## Esta clase construye una Lista de Control con Checkboxes, la utilizaremos para que el usuario seleccione los contadores. La documentaci´on para esta clase fue generada a partir del siguiente fichero: contadores.py B.4. Referencia de la Clase contado- res::CheckListCtrl Esta clase construye una Lista de Control con Checkboxes, la utilizare- mos para que el usuario seleccione los contadores.
    • 136 B.4. Referencia de la Clase contadores::CheckListCtrl Diagrama de herencias de contadores::CheckListCtrl Diagrama de colaboraci´on para contadores::CheckListCtrl: M´etodos p´ublicos def init Constructor de la Clase CheckListCtrl ( p. 135). B.4.1. Descripci´on detallada Esta clase construye una Lista de Control con Checkboxes, la utilizare- mos para que el usuario seleccione los contadores. Hereda de varias clases de wxPython como vemos en los par´ametros. Par´ametros: wx.ListCtrl CheckListCtrlMixin ListCtrlAutoWidthMixin
    • Manual de C´odigo 137 Definici´on en la l´ınea 154 del archivo contadores.py. B.4.2. Documentaci´on de las funciones miembro B.4.2.1. def contadores::CheckListCtrl:: init ( self, parent) Constructor de la Clase CheckListCtrl (p. 135). Par´ametros: self Puntero al objeto actual. parent Puntero al objeto padre. Definici´on en la l´ınea 158 del archivo contadores.py. 158 : 159 wx.ListCtrl.__init__(self, parent, -1, style=wx.LC_REPORT | wx.SUNKEN_BORDER) 160 CheckListCtrlMixin.__init__(self) 161 ListCtrlAutoWidthMixin.__init__(self) 162 163 164 La documentaci´on para esta clase fue generada a partir del siguiente fichero: contadores.py B.5. Referencia de la Clase resultados::Results Esta clase controla la interfaz de Resultados, dentro de ella encontra- mos un notebook con pesta˜nas borrables donde se registran los resultados generados desde la clase de interfaz de entrada y salida. M´etodos p´ublicos def init Constructor de la clase Resultados.
    • 138 B.5. Referencia de la Clase resultados::Results def SetResults Inserta los resultados de las ejecuciones en sus listas correspondientes, cada nuevo resultado en una pesta˜na nueva del NoteBook. def RemoveTab Borra cada elemento de la lista de Pesta˜nas. def SetList Inicia los diccionarios. def Load Carga en el diccionario de resultados los valores del fichero a abrir. def Get Extrae los valores de la ejecuci´on de la pesta˜na actual para escribirlos en un fichero. def GetDraw Guarda en el fichero que se indica la gr´afica obtenida, en caso de haberse obtenido. Atributos p´ublicos io nb listOfTabs i generated sizer commandDict dictionaryOfResults B.5.1. Descripci´on detallada Esta clase controla la interfaz de Resultados, dentro de ella encontra- mos un notebook con pesta˜nas borrables donde se registran los resultados generados desde la clase de interfaz de entrada y salida. Se trata de un Panel en la ventana principal (MainFrame) de Glperfex.
    • Manual de C´odigo 139 Par´ametros: wx.Panel Hereda de la clase wx.Panel Definici´on en la l´ınea 28 del archivo resultados.py. B.5.2. Documentaci´on de las funciones miembro B.5.2.1. def resultados::Results:: init ( self, parent) Constructor de la clase Resultados. Llama a los constructores de las clases de las que hereda y construye la interfaz. Tambi´en enlaza los eventos a las funciones correspondientes. Par´ametros: self Puntero al objeto actual. parent Puntero al objeto padre. Definici´on en la l´ınea 35 del archivo resultados.py. 35 : 36 37 38 #Se inician los constructores de las superclases 39 wx.Panel.__init__(self, parent) 40 self.io = io.IOInterface() 41 # Se construye el NoteBook (la lista de pesta~nas) as´ı como la lista de 42 # pesta~nas y el contador de las mismas 43 self.nb = wx.aui.AuiNotebook(self,-1 ,style=wx.aui.AUI_NB_WINDOWLIST_BUTTON| 44 wx.aui.AUI_NB_TAB_MOVE|wx.aui.AUI_NB_TAB_SPLIT| wx.aui.AUI_NB_SCROLL_BUTTONS 45 |wx.aui.AUI_NB_DEFAULT_STYLE) 46 47 self.listOfTabs = [] 48 self.i = 0 49 self.generated = False 50 51 # Se a~nade el NoteBook a la ventana de Resultados 52 self.sizer = wx.BoxSizer(wx.HORIZONTAL) 53 self.sizer.Add(self.nb, 1, wx.EXPAND) 54 self.SetSizer(self.sizer) 55 56 # Hacemos un bind del evento de cierre de la pesta~na al m´etodo que 57 # las borra 58 self.Bind(wx.aui.EVT_AUINOTEBOOK_PAGE_CLOSE, self.RemoveTab)
    • 140 B.5. Referencia de la Clase resultados::Results 59 60 ## Inserta los resultados de las ejecuciones en sus listas correspondientes, cada nuevo resultado en una pesta~na nueva del NoteBook. B.5.2.2. def resultados::Results::SetResults ( self, option) Inserta los resultados de las ejecuciones en sus listas correspondientes, cada nuevo resultado en una pesta˜na nueva del NoteBook. Par´ametros: self Puntero al objeto actual. option Opci´on que fija si hemos de colocar unos resultados de una ejecuci´on simple, es decir, sin gr´afica, o una ejecuci´on con m´as de una ejecuci´on, es decir con gr´afica. Definici´on en la l´ınea 65 del archivo resultados.py. 65 : 66 67 # A~nadiendo pesta~na de Resultados 68 if self.nb.GetPageCount() == 0: 69 self.i = 0 70 name = "Resultado " + str(self.i) 71 results = ResultsPanel(self.nb) 72 73 a = 0 74 self.i = self.i + 1 75 76 if option == 1: 77 for key in self.commandDict: 78 self.dictionaryOfResults[key] = self.GetResults( self.commandDict[key]) 79 a = self.dictionaryOfResults[key][0] 80 81 else: 82 for key in self.dictionaryOfResults: 83 a = self.dictionaryOfResults[key][0] 84 85 print self.dictionaryOfResults 86 87 if a == 1: 88 results.DecideStructure(1,self.dictionaryOfResults) 89 for key in self.dictionaryOfResults: 90 index = results.list1.InsertStringItem(0,key) 91 results.list1.SetStringItem(index, 1, 92 str(self.dictionaryOfResults[key][1][0]))
    • Manual de C´odigo 141 93 results.list1.SetStringItem(index, 2, 94 str(self.dictionaryOfResults[key][4])) 95 results.list1.SetStringItem(index, 3, 96 str(self.dictionaryOfResults[key][5])) 97 98 else: 99 results.DecideStructure(2,self.dictionaryOfResults) 100 for key in self.dictionaryOfResults: 101 index = results.list1.InsertStringItem(0,key) 102 results.list1.SetStringItem(index, 1, 103 str(self.dictionaryOfResults[key][2]).replace(’,’,’.’)) 104 results.list1.SetStringItem(index, 2, 105 str(self.dictionaryOfResults[key][3]).replace(’,’,’.’)) 106 results.list1.SetStringItem(index, 3, 107 str(self.dictionaryOfResults[key][4])) 108 results.list1.SetStringItem(index, 4, 109 str(self.dictionaryOfResults[key][5])) 110 111 112 113 self.nb.AddPage(results, name) 114 115 self.listOfTabs.append(results) 116 self.generated = True 117 ## Borra cada elemento de la lista de Pesta~nas. B.5.2.3. def resultados::Results::RemoveTab ( self, event) Borra cada elemento de la lista de Pesta˜nas. Par´ametros: self Puntero al objeto actual. event Evento que activa el m´etodo al accionarse en el panel. Definici´on en la l´ınea 121 del archivo resultados.py. 121 : 122 123 index = self.nb.GetSelection() 124 del self.listOfTabs[index] 125 ## Inicia los diccionarios. B.5.2.4. def resultados::Results::SetList ( self, orcommandDict) Inicia los diccionarios.
    • 142 B.5. Referencia de la Clase resultados::Results Par´ametros: self Puntero al objeto actual. orcomamandDict Introduce en CommandDict el valor deseado (el diccionario que se trae desde fuera). Definici´on en la l´ınea 130 del archivo resultados.py. 130 : 131 self.commandDict = {} 132 self.commandDict = orcommandDict 133 self.dictionaryOfResults = {} 134 ## Carga en el diccionario de resultados los valores del fichero a abrir. B.5.2.5. def resultados::Results::Load ( self, filename) Carga en el diccionario de resultados los valores del fichero a abrir. Par´ametros: self Puntero al objeto actual. filename Nombre del fichero a leer. Definici´on en la l´ınea 138 del archivo resultados.py. 138 : 139 self.dictionaryOfResults = self.io.ReadCSV(filename) 140 141 ## Extrae los valores de la ejecuci´on de la pesta~na actual para escribirlos en un fichero. B.5.2.6. def resultados::Results::Get ( self, filename) Extrae los valores de la ejecuci´on de la pesta˜na actual para escribirlos en un fichero. Par´ametros: self Puntero al objeto actual. filename Nombre del fichero a escribir
    • Manual de C´odigo 143 Definici´on en la l´ınea 145 del archivo resultados.py. 145 : 146 index = self.nb.GetSelection() 147 self.io.WriteCSV(self.listOfTabs[index].dictionaryOfResults,filename) 148 ## Guarda en el fichero que se indica la gr´afica obtenida, en caso de haberse obtenido. B.5.2.7. def resultados::Results::GetDraw ( self, filename) Guarda en el fichero que se indica la gr´afica obtenida, en caso de haberse obtenido. Par´ametros: self Puntero al objeto actual. filename Nombre del fichero a guardar. Devuelve: True En caso de que se haya generado la gr´afica. False En caso de que no se haya generado. Definici´on en la l´ınea 154 del archivo resultados.py. 154 : 155 if self.generated == True: 156 index = self.nb.GetSelection() 157 if self.listOfTabs[index].isDrawn == True: 158 self.io.SaveDraw(self.listOfTabs[index].client,filename) 159 return True 160 else: 161 return False 162 else: 163 return False 164 165 166 ## La clase ResultsPanel se ocupa de manejar las pesta~nas que se cargan en la clase Resultados La documentaci´on para esta clase fue generada a partir del siguiente fichero: resultados.py
    • 144 B.6. Referencia de la Clase resultados::ResultsPanel B.6. Referencia de la Clase resulta- dos::ResultsPanel La clase ResultsPanel (p. 144) se ocupa de manejar las pesta˜nas que se cargan en la clase Resultados. M´etodos p´ublicos def init Constructor de la Clase ResultsPanel ( p. 144). def DecideStructure Este m´etodo nos construye los resultados que figurar´an en la pesta˜na de cada resultado, la construcci´on depender´a del n´umero de filas que tenga, es decir, si la ejecuci´on se realiz´o una sola vez, s´olo tendr´a que ofrecer resultados individuales, en caso contrario mostramos la gr´afica y las eje- cuciones medias. def OnSelect El m´etodo OnSelect es llamado al activar el evento de selecci´on de un resultado medio de la lista de resultados medios con el objetivo de imprimir en la lista de resultados individuales dichos resultados y dibujar la gr´afica. Atributos p´ublicos hbox isDrawn dictionaryOfResults rows list1 client list2 sizer2 B.6.1. Descripci´on detallada La clase ResultsPanel (p. 144) se ocupa de manejar las pesta˜nas que se cargan en la clase Resultados.
    • Manual de C´odigo 145 Par´ametros: wx.Panel Herada de la clase wx.Panel Definici´on en la l´ınea 169 del archivo resultados.py. B.6.2. Documentaci´on de las funciones miembro B.6.2.1. def resultados::ResultsPanel:: init ( self, parent) Constructor de la Clase ResultsPanel (p. 144). Par´ametros: self Puntero al objeto actual. parent Puntero al objeto padre. Definici´on en la l´ınea 174 del archivo resultados.py. 174 : 175 176 wx.Panel.__init__(self, parent) 177 178 self.hbox = wx.BoxSizer(wx.VERTICAL) 179 self.isDrawn = False 180 ## Este m´etodo nos construye los resultados que figurar´an en la pesta~na B.6.2.2. def resultados::ResultsPanel::DecideStructure ( self, rows, dictionaryOfResults) Este m´etodo nos construye los resultados que figurar´an en la pesta˜na de cada resultado, la construcci´on depender´a del n´umero de filas que tenga, es decir, si la ejecuci´on se realiz´o una sola vez, s´olo tendr´a que ofrecer resultados individuales, en caso contrario mostramos la gr´afica y las ejecuciones medias. Par´ametros: self Puntero al objeto actual. rows N´umero de columnas del panel. dictionaryOfResults Diccionario de Resultados, desde el que se re- llenar´a el panel.
    • 146 B.6. Referencia de la Clase resultados::ResultsPanel Definici´on en la l´ınea 189 del archivo resultados.py. 189 : 190 191 # Recibimos tanto las filas, es decir, n´umero de ejecuciones, como el 192 # diccionario de resultados 193 self.dictionaryOfResults = dictionaryOfResults 194 self.rows = rows 195 196 # En este caso existe s´olo una ejecuci´on, por lo que s´olo debemos reflejar 197 # los resultados individuales 198 199 if rows == 1: 200 201 # Resultados Individuales 202 self.list1 = wx.ListCtrl(self, -1 ,style=wx.LC_REPORT|wx.LC_SINGLE_SEL) 203 self.list1.InsertColumn(0, ’Contador’, width=140) 204 self.list1.InsertColumn(1, ’Resultado’, width=140) 205 self.list1.InsertColumn(2, ’Tiempo’) 206 self.list1.InsertColumn(3, ’T_Sys’) 207 208 # Encajamos la pesta~na 209 210 self.hbox.Add(self.list1, 1, wx.EXPAND) 211 self.SetSizer(self.hbox) 212 213 # En caso de que exista mas de una fila fabricaremos la lista de 214 # resultados medios, list1, y la de resultados individuales 215 216 else: 217 218 # Grafica con las ejecuciones individulaes 219 220 self.client = plot.PlotCanvas(self) 221 222 # Resultados medios 223 224 self.list1 = wx.ListCtrl(self, -1 ,style=wx.LC_REPORT|wx.LC_SINGLE_SEL) 225 226 self.list1.InsertColumn(0, ’Contador’, width=140) 227 self.list1.InsertColumn(1, ’Resultado Medio’, width=140) 228 self.list1.InsertColumn(2, ’Desviaci´on’,width=140) 229 self.list1.InsertColumn(3, ’Tiempo’) 230 self.list1.InsertColumn(4, ’T_Sys’) 231 232 # Resultados individuales 233 234 self.list2 = wx.ListCtrl(self, -1 ,style=wx.LC_REPORT|wx.LC_SINGLE_SEL) 235 236 self.list2.InsertColumn(0, ’N’, width=40) 237 self.list2.InsertColumn(1, ’Contador’, width=140)
    • Manual de C´odigo 147 238 self.list2.InsertColumn(2, ’Resultado’, width=140) 239 240 #Encajamos la pesta~na 241 242 self.sizer2 = wx.BoxSizer(wx.HORIZONTAL) 243 244 self.hbox.Add(self.list1, 1, wx.EXPAND) 245 self.hbox.Add(self.sizer2, 1, wx.EXPAND) 246 247 self.sizer2.Add(self.list2,1,wx.EXPAND) 248 self.sizer2.Add(self.client,1,wx.EXPAND) 249 250 self.SetSizer(self.hbox) 251 self.Bind(wx.EVT_LIST_ITEM_SELECTED, self.OnSelect) 252 253 ## El m´etodo OnSelect es llamado al activar el evento de selecci´on de un resultado medio de la lista de resultados medios con el objetivo de imprimir en la lista de resultados individuales dichos resultados y dibujar la gr´afica. B.6.2.3. def resultados::ResultsPanel::OnSelect ( self, event) El m´etodo OnSelect es llamado al activar el evento de selecci´on de un resultado medio de la lista de resultados medios con el objetivo de imprimir en la lista de resultados individuales dichos resultados y dibujar la gr´afica. Par´ametros: self Puntero al objeto actual. event Evento que activa el m´etodo al accionarse en el panel. Definici´on en la l´ınea 257 del archivo resultados.py. 257 : 258 259 260 # Recoger el nombre del primer evento seleccionado 261 ev = self.list1.GetItemText(self.list1.GetFirstSelected()) 262 263 # Cogemos el resultado del evento 264 tup = self.dictionaryOfResults[self.list1.GetItemText(self.list1. GetFirstSelected())] 265 266 data1 = [] #linea de resultados 267 data2 = [] #linea de la media 268 269 #Definimos un numero maximo a cero y un numero minimo a infinito
    • 148 B.6. Referencia de la Clase resultados::ResultsPanel 270 maxm = 0 271 minm = 100000000000000000000000000000000000000 272 273 #Implementacion de los elementos de la lista 274 self.list2.DeleteAllItems() 275 276 # Recorremos los resultados que hay, dados por el primer dato de la tupla 277 for i in range(tup[0]): 278 value = int(tup[1][i]) #Valor del resultado i 279 reverseIndex = tup[0] - int(i) - 1 280 281 #Construimos las listas de datos para imprimir 282 data1.append((int(i)+1, value)) 283 data2.append((int(i)+1, tup[2])) 284 285 # Modificando los valores maximos o minimos del resultado 286 if maxm < value: 287 maxm = value 288 if minm > value: 289 minm = value 290 291 #Insertamos los resultados individuales en la lista grafica de 292 # resultados 293 index = self.list2.InsertStringItem(0,str(reverseIndex+1)) 294 self.list2.SetStringItem(index,1,ev) 295 self.list2.SetStringItem(index,2,tup[1][reverseIndex]) 296 297 298 # Damos un margen de 200 por abajo si no es negativo (abajo lo haremos 299 # para el margen de arriba) 300 301 minm = minm -200 302 if minm-200 < 0: 303 minm = 0 304 305 #Dibujamos 306 line1 = plot.PolyLine(data1, legend=’Resultados’, colour=’pink’,width=3) 307 line2 = plot.PolyLine(data2, legend=’Media’, colour=’grey’, width=2) 308 gc = plot.PlotGraphics([line1,line2],"Ejecucion de " + ev, ’Numero de Ejecucion’, 309 ’Resultado’) 310 self.client.Draw(gc, xAxis= (1,tup[0]), yAxis= (minm,maxm+200)) 311 self.isDrawn = True 312 313 La documentaci´on para esta clase fue generada a partir del siguiente fichero: resultados.py
    • Manual de C´odigo 149 B.7. Referencia de la Clase io::IOInterface Esta clase sirve como una interfaz de glperfex a lperfex, de manera que el resto de clases puedan despreocuparse de los aspectos m´as complicados como leer ficheros, escribir en ellos o comunicarse con la entrada y salida de lperfex. M´etodos p´ublicos def init Constructor de la Clase IOInterface ( p. 149). def GetDictionary Este m´etodo devuelve el diccionario de Contadores de la m´aquina. def AddItemToSelectionList Este m´etodo a˜nade un item a la lista de selecci´on. def RemoveItemFromSelectionList Este m´etodo borra un item de la lista de selecci´on. def CleanSelectionList Este m´etodo borra toda la lista de selecci´on. def GetSelectionList Este m´etodo devuelve la lista de selecci´on. def GetResults Este m´etodo devuelve los resultados obtenidos al ejecutar un comando de lperfex, es quiz´a el m´etodo m´as importante de glperfex, ya que es junto al m´etodo que obtiene la lista de eventos el que ofrece la interacci´on con lperfex. def DividePath Este m´etodo obtiene el directorio y lo une al nombre del fichero tras com- probar que se aloja en un directorio v´alido en la variable PATH del siste- ma. def CheckExecutableFile Este m´etodo comprueba si el fichero introducido se trata de un fichero ejecutable v´alido a trav´es de la salida del comando file, es decir, si se trata de un fichero ELF de 32 bits lincado din´amicamente.
    • 150 B.7. Referencia de la Clase io::IOInterface def ReadCSV Este m´etodo lee un fichero .csv dado por par´amametros tal y como esta- blecimos en la definici´on del manual t´ecnico y devuelve un diccionario de resultados tal y como si se hubiera realizado una medici´on normal. def WriteCSV Este m´etodo escribe un fichero .csv dado por par´amametros tal y como establecimos en la definici´on del manual t´ecnico. def SaveDraw Este m´etodo guarda un fichero utilizando el m´etodo SaveFile del objeto cliente. Atributos p´ublicos selectionList dictofCounters command B.7.1. Descripci´on detallada Esta clase sirve como una interfaz de glperfex a lperfex, de manera que el resto de clases puedan despreocuparse de los aspectos m´as complicados como leer ficheros, escribir en ellos o comunicarse con la entrada y salida de lperfex. Definici´on en la l´ınea 21 del archivo io.py. B.7.2. Documentaci´on de las funciones miembro B.7.2.1. def io::IOInterface:: init ( self) Constructor de la Clase IOInterface (p. 149). Par´ametros: self Puntero al objeto actual. Definici´on en la l´ınea 25 del archivo io.py.
    • Manual de C´odigo 151 25 : 26 27 #Inicializamos la lista de slecci´on 28 self.selectionList = [] 29 30 # Inicialixamos el diccionario de contadores y obtenemos los contadores de la 31 # m´aquina con el comando lperfex -l 32 self.dictofCounters = {} 33 command = ’lperfex -l’ 34 pipe = os.popen(command) 35 standardOutput = pipe.readlines() 36 pipe.close() 37 38 # Es necesario eliminar adem´as de datos no relacionados con contadores 39 # dos contadores que no funcionan bien 40 for line in standardOutput: 41 if "PAPI_" in line and not "PAPI_L1_ICH" in line and not "PAPI_L2_LDM" in line: 42 auxList = line.split(’t’) 43 self.dictofCounters[auxList[0]] = auxList[1][:-1] 44 45 #Command 46 self.command = "" 47 ## Este m´etodo devuelve el diccionario de Contadores de la m´aquina B.7.2.2. def io::IOInterface::GetDictionary ( self) Este m´etodo devuelve el diccionario de Contadores de la m´aquina. Par´ametros: self Puntero al objeto actual. Devuelve: self.dictionaryofCounters El diccionario de contadores de la m´aquina. Definici´on en la l´ınea 51 del archivo io.py. 51 : 52 return self.dictofCounters 53 ## Este m´etodo a~nade un item a la lista de selecci´on.
    • 152 B.7. Referencia de la Clase io::IOInterface B.7.2.3. def io::IOInterface::AddItemToSelectionList ( self, item) Este m´etodo a˜nade un item a la lista de selecci´on. Par´ametros: self Puntero al objeto actual. item Elemento a a˜nadir. Definici´on en la l´ınea 57 del archivo io.py. 57 : 58 self.selectionList.append(item) 59 ## Este m´etodo borra un item de la lista de selecci´on. B.7.2.4. def io::IOInterface::RemoveItemFromSelectionList ( self, item) Este m´etodo borra un item de la lista de selecci´on. Par´ametros: self Puntero al objeto actual. item Elemento a borrar. Definici´on en la l´ınea 63 del archivo io.py. 63 : 64 self.selectionList.remove(item) 65 ## Este m´etodo borra toda la lista de selecci´on. B.7.2.5. def io::IOInterface::CleanSelectionList ( self) Este m´etodo borra toda la lista de selecci´on. Par´ametros: self Puntero al objeto actual.
    • Manual de C´odigo 153 Definici´on en la l´ınea 68 del archivo io.py. 68 : 69 self.selectionList = [] 70 ## Este m´etodo devuelve la lista de selecci´on. B.7.2.6. def io::IOInterface::GetSelectionList ( self) Este m´etodo devuelve la lista de selecci´on. Par´ametros: self Puntero al objeto actual. Devuelve: self.selectionList Devuelve la lista de selecci´on. Definici´on en la l´ınea 74 del archivo io.py. 74 : 75 return self.selectionList 76 ## Este m´etodo devuelve los resultados obtenidos al ejecutar un comando de lperfex, es quiz´a el B.7.2.7. def io::IOInterface::GetResults ( self, command) Este m´etodo devuelve los resultados obtenidos al ejecutar un comando de lperfex, es quiz´a el m´etodo m´as importante de glperfex, ya que es junto al m´etodo que obtiene la lista de eventos el que ofrece la interacci´on con lperfex. Dependiendo de si es un path absoluto, o tiene otro tipo de dato se tratar´a de una manera u otra. Una vez se ha desplazado al directorio se ejecuta el comando usando a su vez time para obtener el tiempo que tard´o en realizar la ejecuci´on. En el momento de ejecutarse se obtiene la salida por la stdout y la stderr y se obtiene la informaci´on deseada. Una vez recopilada se devuelven los datos. Par´ametros: self Puntero al objeto actual.
    • 154 B.7. Referencia de la Clase io::IOInterface command Comando a ejecutar. Devuelve: (len(resultsList),resultsList, media, desviacion,treal,tsys) Es una tupla con la lista de resultados de la ejecuci´on, m´as los resultados que se hicieron, la media, desviaci´on, tiempo real y de sistema. Definici´on en la l´ınea 88 del archivo io.py. 88 : 89 resultsList = [] 90 dictofCounters = {} 91 92 commandos = command[1] 93 94 #OPCION CON PATH ABSOLUTO 95 96 if ’/’ in commandos: 97 n = len(commandos) - 1 98 99 while commandos[n-1] != ’/’: 100 n -= 1 101 directory = commandos[0:n] 102 filename = commandos[n:len(commandos)] 103 ok = True 104 105 #OPCION CON OTRO TIPO DE PATH 106 else: 107 tupl = self.DividePath(commandos) 108 ok = tupl[2] 109 directory = tupl[0] 110 filename = tupl[1] 111 112 print directory + filename 113 114 115 if ok == False: 116 return 117 118 realcommand = "cd " + directory + " && " + "/usr/bin/time --format="realt%esnsyst%Ss" " + 119 command[0] + " ./" + filename + " 2>&1" 120 121 122 pipe = os.popen(realcommand) 123 standardOutput = pipe.readlines() 124 pipe.close() 125 media = 0 126 desviacion = 0 127 treal = 0
    • Manual de C´odigo 155 128 tsys = 0 129 130 for line in standardOutput: 131 auxList = line.split(’t’) 132 print auxList 133 134 if("PAPI_" in line and "Evento" not in line): 135 resultsList.append(auxList[2][:-1]) 136 137 elif("PAPI_" and "Evento" and "Media" in line): 138 media = auxList[2][:-1] 139 elif("PAPI_" and "Evento" and "Desvia" in line): 140 desviacion = auxList[2][:-1] 141 elif("sys" in line): 142 tsys = auxList[1][:-1] 143 elif("real" in line): 144 treal = auxList[1][:-1] 145 146 return len(resultsList),resultsList, media, desviacion,treal,tsys 147 148 ## Este m´etodo obtiene el directorio y lo une al nombre del fichero B.7.2.8. def io::IOInterface::DividePath ( self, command) Este m´etodo obtiene el directorio y lo une al nombre del fichero tras comprobar que se aloja en un directorio v´alido en la variable PATH del sistema. Par´ametros: self Puntero al objeto actual. command Comando que se recogi´o sin formato absoluto. Devuelve: directory+’/’,filename,ok Devuelve una tupla con la ruta obtenida in- dicando si fue obtenida correctamente. Definici´on en la l´ınea 156 del archivo io.py. 156 : 157 ok = False 158 pipe = os.popen("echo $PATH") 159 standardOutput = pipe.read() 160 pipe.close() 161 path = standardOutput[0:-1].split(’:’) 162 filename = command
    • 156 B.7. Referencia de la Clase io::IOInterface 163 pipe = os.popen("whereis -b " + command) 164 standardOutput = pipe.read() 165 pipe.close() 166 167 list = standardOutput[0:-1].split(’ ’) 168 print list 169 for elemento in list[1:]: 170 n = len(elemento)-1 171 if ’/’ in elemento : #Hay que curarse en salud ante bucles infinitos 172 while elemento[n] != ’/’: 173 n -= 1 174 if elemento[0:n] in path: 175 directory = elemento[0:n] 176 ok = True 177 178 return directory + ’/’,filename,ok 179 ## Este m´etodo comprueba si el fichero introducido se trata de un fichero ejecutable v´alido B.7.2.9. def io::IOInterface::CheckExecutableFile ( self, filePath) Este m´etodo comprueba si el fichero introducido se trata de un fichero ejecutable v´alido a trav´es de la salida del comando file, es decir, si se trata de un fichero ELF de 32 bits lincado din´amicamente. Par´ametros: self Puntero al objeto actual. filePath Path del fichero a comprobar. Devuelve: True En caso de que sea un fichero v´alido. False En caso en que no sea un fichero v´alido. Definici´on en la l´ınea 187 del archivo io.py. 187 : 188 command = "file " + filePath 189 print command 190 pipe = os.popen(command) 191 standardOutput = pipe.readlines() 192 pipe.close 193
    • Manual de C´odigo 157 194 for line in standardOutput: 195 if "ELF 32-bit LSB executable" and "dynamically linked" in line: 196 return True 197 198 return False 199 ## Este m´etodo lee un fichero .csv dado por par´amametros tal y como establecimos en la B.7.2.10. def io::IOInterface::ReadCSV ( self, filename) Este m´etodo lee un fichero .csv dado por par´amametros tal y como es- tablecimos en la definici´on del manual t´ecnico y devuelve un diccionario de resultados tal y como si se hubiera realizado una medici´on normal. Par´ametros: self Puntero al objeto actual. filename Nombre del fichero a leer. Devuelve: dictofResults Diccionario con los datos del fichero. Definici´on en la l´ınea 206 del archivo io.py. 206 : 208 pf = open(filename,’r’) 209 210 i = 0 211 option = 1 212 n = 4 213 214 dictofResults = {} 215 216 217 for line in pf.readlines(): 218 aux = line.split(’,’) 219 220 # Con estas comprobaciones averiguamos si es un fichero 221 # con varias ejecuciones o con una sola 222 223 # Con m´as de una ejecuci´on 224 if i == 0 and len(aux) == 6: 225 option = 1 226 227 # Con una sola ejecuci´on 228 elif i == 0 and len(aux) == 4:
    • 158 B.7. Referencia de la Clase io::IOInterface 229 option = 0 230 231 # Ahora actuamos conforme a lo averiguado y construimos las listas 232 # que vamos a devolver 233 234 # Con una sola ejecuci´on 235 elif option == 0 : 236 if "PAPI_" in aux[0]: 237 dictofResults[aux[0]] = (1,[aux[1]],0,0,str(aux[2]), str(aux[3][:-1])) 238 239 # Con m´as de una ejecuci´on 240 elif option == 1 : 241 if "PAPI_" in aux[0]: 242 dictofResults[aux[0]] = (int(aux[5]),[],float(aux[1]), float(aux[2]), 243 str(aux[3]),str(aux[4])) 244 n = aux[0] 245 246 elif len(aux) == 2 and "N. Ej" not in aux[0] : 247 dictofResults[n][1].append(aux[1][:-1]) 248 249 i = i + 1 250 251 pf.close() 252 253 return dictofResults 254 ## Este m´etodo escribe un fichero .csv dado por par´amametros tal y como establecimos en la B.7.2.11. def io::IOInterface::WriteCSV ( self, dictOfResults, filename) Este m´etodo escribe un fichero .csv dado por par´amametros tal y como establecimos en la definici´on del manual t´ecnico. Par´ametros: self Puntero al objeto actual. dictOfResults Diccionario con los resultados que se desean escribir en el fichero. filename Nombre del fichero a escribir. Necesitamos comprobar todav´ıa si se abre el fichero. Funci´on para rescatar en una lista los resultados de una ejecuci´on guardados en fichero Definici´on en la l´ınea 260 del archivo io.py.
    • Manual de C´odigo 159 260 : 261 """Necesitamos comprobar todav´ıa si se abre el fichero. 262 Funci´on para rescatar en una lista los resultados de una ejecuci´on guardados en fichero""" 263 264 pf = open(filename,’w’) 265 266 for key in dictOfResults: 267 nex = dictOfResults[key][0] 268 269 270 # En este caso escribimos los datos de ejecuciones individuales simplemente 271 if nex == 1: 272 line1 = "Contador,Resultado,Tiempo,Tiempo Sysnn" 273 pf.write(line1) 274 275 for key in dictOfResults: 276 line2 = key + "," + str(dictOfResults[key][1][0]) + "," + str(dictOfResults[key][4]) 277 + "," + str(dictOfResults[key][5]) + "n" 278 pf.write(line2) 279 280 pf.close() 281 282 283 # En eseta caso escribimos los datos de varias ejecuciones 284 else: 285 286 line1 = "Contador,Resultado medio,Desviaci´on,Tiempo,Tiempo Sys, N. Ejecucionesnn" 287 pf.write(line1) 288 289 290 for key in dictOfResults: 291 desv = str(dictOfResults[key][3]).replace(’,’,’.’) 292 med = str(dictOfResults[key][2]).replace(’,’,’.’) 293 # Resumen medio de las Ejecuciones 294 line2 = key + "," + str(med) + "," + str(desv) + "," + str(dictOfResults[key][4]) 295 + "," + str(dictOfResults[key][5]) + "," + str(nex) + "n" 296 pf.write(line2) 297 298 299 # Empezamos a escribir las ejecuciones individuales 300 line3 = "N. Ejecuci´on,Resultadon" 301 pf.write(line3) 302 303 j = 0 304 305 for i in dictOfResults[key][1]: 306 line4 = str(j+1) + "," + str(dictOfResults[key][1][j]) + "n" 307 pf.write(line4)
    • 160 B.7. Referencia de la Clase io::IOInterface 308 j = j + 1 309 310 line5 = "n" 311 pf.write(line5) 312 313 pf.close() ## Este m´etodo guarda un fichero utilizando el m´etodo SaveFile del objeto cliente. B.7.2.12. def io::IOInterface::SaveDraw ( self, client, filename) Este m´etodo guarda un fichero utilizando el m´etodo SaveFile del objeto cliente. Par´ametros: self Puntero al objeto actual. client Objeto cliente. filename Nombre del fichero a escribir. Definici´on en la l´ınea 318 del archivo io.py. 318 : 319 client.SaveFile(filename) 320 321 La documentaci´on para esta clase fue generada a partir del siguiente fichero: io.py
    • Ap´endice C Licencias Copyleft o copia permitida (=left(de leave) =granted) comprende a un grupo de derechos de autor caracterizados por eliminar las restricciones de distribuci´on o modificaci´on de las que adolece el copyright, con la condici´on de que el trabajo derivado se mantenga con el mismo r´egimen de derechos de autor que el original. Bajo tales licencias pueden protegerse una gran diversidad de obras, tales como programas inform´aticos, arte, cultura y ciencia, es decir pr´acticamente casi cualquier tipo de producci´on creativa. Sus partidarios la proponen como alternativa a las restricciones que im- ponen las normas planteadas en los derechos de autor, a la hora de hacer, modificar y distribuir copias de una obra determinada. Se pretende garan- tizar as´ı una mayor libertad para que cada receptor de una copia, o una versi´on derivada de un trabajo, pueda, a su vez, usar, modificar y redistri- buir tanto el propio trabajo como las versiones derivadas del mismo. As´ı, y en un entorno no legal, puede considerarse como opuesto al copyright o derechos de autor tradicionales. El presente Proyecto contempla dos realidades del desarrollo de un pro- ducto software. Por un lado, contempla una aplicaci´on englobada en un siste- ma software, y por el otro la documentaci´on de todo el proceso de desarrollo y puesta en marcha del mismo. Esto genera contenido tanto inform´atico co- mo documental, lo que obliga a enfocar la forma de licenciar el proyecto de dos maneras diferentes. Pretendemos no obstante, que las licencias escogidas sigan la filosof´ıa Copyleft que hemos definido con anterioridad. Por ello, las licencias escogidas para cada ´ambito han sido, la GNU Ge- neral Public License en su versi´on 3.0, para el programa inform´atico y la GNU Free Documentation License en su versi´on 1.2, para la documentaci´on 161
    • 162 del proyecto. A continuaci´on se incluye el texto completo de las mismas, en ingl´es. Esto es debido a que las traducciones al castellano realizadas, no son reconocidas oficialmente por la Free Software Fundation.
    • Licencias 163 C.1. GNU General Public License Version 3, 29 June 2007 Copyright c 2007 Free Software Foundation, Inc. http://fsf.org/ Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. The GNU General Public License is a free, copyleft license for software and other kinds of works. The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program–to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things. To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others. For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it. For the developers’ and authors’ protection, the GPL clearly explains that there is no warranty for this free software. For both users’ and authors’ sake, the GPL requires that modified versions be marked as changed, so
    • 164 C.1. GNU General Public License that their problems will not be attributed erroneously to authors of previous versions. Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so. This is fundamentally incompatible with the aim of protecting users’ freedom to change the software. The systematic pattern of such abuse occurs in the area of products for individuals to use, which is precisely where it is most unacceptable. Therefore, we have designed this version of the GPL to prohibit the practice for those products. If such problems arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users. Finally, every program is threatened constantly by software patents. Sta- tes should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the spe- cial danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free. The precise terms and conditions for copying, distribution and modifi- cation follow. Terms and Conditions 0. Definitions. “This License” refers to version 3 of the GNU General Public License. “Copyright” also means copyright-like laws that apply to other kinds of works, such as semiconductor masks. “The Program” refers to any copyrightable work licensed under this License. Each licensee is addressed as “you”. “Licensees” and “reci- pients” may be individuals or organizations. To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work. A “covered work” means either the unmodified Program or a work based on the Program. To “propagate” a work means to do anything with it that, without per- mission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution
    • Licencias 165 (with or without modification), making available to the public, and in some countries other activities as well. To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying. An interactive user interface displays “Appropriate Legal Notices” to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that wa- rranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface pre- sents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion. 1. Source Code. The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work. A “Standard Interface” means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language. The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Ma- jor Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work’s System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes in- terface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate
    • 166 C.1. GNU General Public License data communication or control flow between those subprograms and other parts of the work. The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Sour- ce. The Corresponding Source for a work in source code form is that same work. 2. Basic Permissions. All rights granted under this License are granted for the term of copy- right on the Program, and are irrevocable provided the stated condi- tions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law. You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you. Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary. 3. Protecting Users’ Legal Rights From Anti-Circumvention Law. No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures. When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circum- vention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit opera- tion or modification of the work as a means of enforcing, against the work’s users, your or third parties’ legal rights to forbid circumvention of technological measures.
    • Licencias 167 4. Conveying Verbatim Copies. You may convey verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appro- priately publish on each copy an appropriate copyright notice; keep in- tact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all no- tices of the absence of any warranty; and give all recipients a copy of this License along with the Program. You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee. 5. Conveying Modified Source Versions. You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions: a) The work must carry prominent notices stating that you modified it, and giving a relevant date. b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”. c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it. d) If the work has interactive user interfaces, each must display Ap- propriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so. A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation’s users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
    • 168 C.1. GNU General Public License 6. Conveying Non-Source Forms. You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways: a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium custo- marily used for software interchange. b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge. c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alterna- tive is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b. d) Convey the object code by offering access from a designated pla- ce (gratis or for a charge), and offer equivalent access to the Co- rresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements. e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
    • Licencias 169 A separable portion of the object code, whose source code is exclu- ded from the Corresponding Source as a System Library, need not be included in conveying the object code work. A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, “normally used” refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product. A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product. “Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made. If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corres- ponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modi- fied object code on the User Product (for example, the work has been installed in ROM). The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or up- dates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself ma- terially and adversely affects the operation of the network or violates the rules and protocols for communication across the network. Corresponding Source conveyed, and Installation Information provi- ded, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in
    • 170 C.1. GNU General Public License source code form), and must require no special password or key for unpacking, reading or copying. 7. Additional Terms. “Additional permissions” are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Ad- ditional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions ap- ply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions. When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission. Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms: a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or b) Requiring preservation of specified reasonable legal notices or aut- hor attributions in that material or in the Appropriate Legal No- tices displayed by works containing it; or c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or d) Limiting the use for publicity purposes of names of licensors or authors of the material; or e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or f ) Requiring indemnification of licensors and authors of that mate- rial by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors. All other non-permissive additional terms are considered “further res- trictions” within the meaning of section 10. If the Program as you
    • Licencias 171 received it, or any part of it, contains a notice stating that it is gover- ned by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restric- tion but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying. If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms. Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way. 8. Termination. You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11). However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation. Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice. Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10. 9. Acceptance Not Required for Having Copies. You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work
    • 172 C.1. GNU General Public License occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so. 10. Automatic Licensing of Downstream Recipients. Each time you convey a covered work, the recipient automatically re- ceives a license from the original licensors, to run, modify and propa- gate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License. An “entity transaction” is a transaction transferring control of an or- ganization, or substantially all assets of one, or subdividing an orga- nization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party’s predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts. You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (in- cluding a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it. 11. Patents. A “contributor” is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor’s “contributor version”. A contributor’s “essential patent claims” are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, “control” includes the right to grant patent sublicenses in a manner consistent with the requirements of this License. Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor’s essential patent claims, to make,
    • Licencias 173 use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version. In the following three paragraphs, a “patent license” is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To “grant” such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party. If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. “Knowingly relying” means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient’s use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid. If, pursuant to or in connection with a single transaction or arrange- ment, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it. A patent license is “discriminatory” if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.
    • 174 C.1. GNU General Public License Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law. 12. No Surrender of Others’ Freedom. If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot con- vey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a con- sequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program. 13. Use with the GNU Affero General Public License. Notwithstanding any other provision of this License, you have permis- sion to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single com- bined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, sec- tion 13, concerning interaction through a network will apply to the combination as such. 14. Revised Versions of this License. The Free Software Foundation may publish revised and/or new ver- sions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation. If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy’s public statement of acceptance of a version permanently authorizes you to choose that version for the Program.
    • Licencias 175 Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copy- right holder as a result of your choosing to follow a later version. 15. Disclaimer of Warranty. THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EX- TENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOL- DERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EX- PRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PRO- GRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DE- FECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SER- VICING, REPAIR OR CORRECTION. 16. Limitation of Liability. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCI- DENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING REN- DERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPE- RATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOL- DER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSI- BILITY OF SUCH DAMAGES. 17. Interpretation of Sections 15 and 16. If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee. End of Terms and Conditions How to Apply These Terms to Your New Programs
    • 176 C.1. GNU General Public License If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively sta- te the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found. <one line to give the program’s name and a brief idea of what it does.> Copyright (C) <textyear> <name of author> This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>. Also add information on how to contact you by electronic and paper mail. If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode: <program> Copyright (C) <year> <name of author> This program comes with ABSOLUTELY NO WARRANTY; for details type ‘show w’. This is free software, and you are welcome to redistribute it under certain conditions; type ‘show c’ for details. The hypothetical commands show w and show c should show the ap- propriate parts of the General Public License. Of course, your pro- gram’s commands might be different; for a GUI interface, you would use an “about box”. You should also get your employer (if you work as a programmer) or school, if any, to sign a “copyright disclaimer” for the program, if necessary. For more information on this, and how to apply and follow the GNU GPL, see http://www.gnu.org/licenses/. The GNU General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine
    • Licencias 177 library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read http://www.gnu.org/philosophy/why-not-lgpl.html.
    • 178 C.2. GNU Free Documentation License C.2. GNU Free Documentation License Version 1.2, November 2002 Copyright c 2000,2001,2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The purpose of this License is to make a manual, textbook, or other functional and useful document “free” in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this Li- cense preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by ot- hers. This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. 1. APPLICABILITY AND DEFINITIONS This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty- free license, unlimited in duration, to use that work under the conditions stated herein. The “Document”, below, refers to any such manual or work.
    • Licencias 179 Any member of the public is a licensee, and is addressed as “you”. You ac- cept the license if you copy, modify or distribute the work in a way requiring permission under copyright law. A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publis- hers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with ge- neric text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suita- ble for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwi- se Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called “Opaque”. Examples of suitable formats for Transparent copies include plain AS- CII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of
    • 180 C.2. GNU Free Documentation License transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only. The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work’s title, preceding the beginning of the body of the text. A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses follo- wing text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve the Title” of such a section when you modify the Document means that it remains a section “Entitled XYZ” according to this definition. The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License. 2. VERBATIM COPYING You may copy and distribute the Document in any medium, either com- mercially or noncommercially, provided that this License, the copyright no- tices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you dis- tribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies. 3. COPYING IN QUANTITY
    • Licencias 181 If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Do- cument’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they pre- serve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a comple- te Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document. 4. MODIFICATIONS You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which
    • 182 C.2. GNU Free Documentation License should, if there were any, be listed in the History section of the Docu- ment). You may use the same title as a previous version if the original publisher of that version gives permission. B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement. C. State on the Title page the name of the publisher of the Modified Version, as the publisher. D. Preserve all the copyright notices of the Document. E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s license notice. H. Include an unaltered copy of this License. I. Preserve the section Entitled “History”, Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled “History” in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. J. Preserve the network location, if any, given in the Document for pu- blic access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the “History” section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. K. For any section Entitled “Acknowledgements” or “Dedications”, Pre- serve the Title of the section, and preserve in the section all the subs- tance and tone of each of the contributor acknowledgements and/or dedications given therein.
    • Licencias 183 L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. M. Delete any section Entitled “Endorsements”. Such a section may not be included in the Modified Version. N. Do not retitle any existing section to be Entitled “Endorsements” or to conflict in title with any Invariant Section. O. Preserve any Warranty Disclaimers. If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles. You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various parties–for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version. 5. COMBINING DOCUMENTS You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant
    • 184 C.2. GNU Free Documentation License Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections Entitled “History” in the various original documents, forming one section Entitled “History”; likewise combine any sections Entitled “Acknowledgements”, and any sec- tions Entitled “Dedications”. You must delete all sections Entitled “Endor- sements”. 6. COLLECTIONS OF DOCUMENTS You may make a collection consisting of the Document and other docu- ments released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document. 7. AGGREGATION WITH INDEPENDENT WORKS A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an “aggregate” if the copyright resulting from the compilation is not used to limit the legal rights of the compilation’s users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.
    • Licencias 185 If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate. 8. TRANSLATION Translation is considered a kind of modification, so you may distribu- te translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail. If a section in the Document is Entitled “Acknowledgements”, “Dedi- cations”, or “History”, the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title. 9. TERMINATION You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 10. FUTURE REVISIONS OF THIS LICENSE The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
    • 186 C.2. GNU Free Documentation License Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. ADDENDUM: How to use this License for your documents To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page: Copyright c YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”. If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “with . . . Texts.” line with this: with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. If you have Invariant Sections without Cover Texts, or some other com- bination of the three, merge those two alternatives to suit the situation. If your document contains nontrivial examples of program code, we re- commend releasing these examples in parallel under your choice of free soft- ware license, such as the GNU General Public License, to permit their use in free software.