• Author / Uploaded
• MiXizita Navarro Pacheco

• Categories
• Hilo (Computación)
• Kernel (sistema operativo)
• Sistema operativo
• Memoria del ordenador
• Hardware de la computadora

Citation preview

Sistema Operativo Symbian OS

Introduccion Objetivos Desarrollo a. Generalidades sobre Symbian SO b. Procesos e Hilos Symbian OS es un sistema operativo multitareas. 1.3.1 Hilos y nanohilos Symbian OS usa los hilos como base de multitareas. El sistema operativo ve un proceso como una colección de hilos con un bloque de control de proceso y cierto espacio de memoria. El soporte de hilos en Symbian OS se basa en el nanokernel con nanohilos. El nanokernel: Proporciona soporte simple para hilos; cada hilo se sostiene mediante un nanohilo basado en nanokernel. Los nanohilos : Se ejecutan en modo privilegiado (no en modo usuario) y necesitan una pila para almacenar sus datos del entorno en tiempo de ejecución. Necesitan un mínimo de datos para ejecutarse: - Ubicación de su pila - Tamaño (que tan grande es) El sistema operativo controla todo, como el código de cada hilo, y almacena el contexto de un hilo en su pila en tiempo de ejecución. Los nanohilos tienen estados de hilos, así como los procesos tienen estados. Estados agregados del modelo nanokernel de Symbian Os  Suspendido: Cuando un hilo suspende a otro hilo y debe ser distinto al estado en espera, donde un hilo se bloquee algún objeto de nivel superior (por ejemplo, un hilo).  Espera de semáforo rápido: Un hilo en este estado espera a que se señale un semáforo rápido. Son semáforos a nivel de nanokernel.  Espera de DFC: Un hilo esta esperando que se agregue una llamada a función retrasada (DFC) a la cola de DFCs. Las DFCs se utilizan en la implementación de drivers de dispositivos. Representan llamadas al kernel que se pueden poner en cola y programar para ejecutarse mediante el nivel del kernel de Symbian OS.  Inactivo: Los hilos inactivos esperan a que se transcurran una cantidad específica de tiempo.

 Otro…Estado genérico: Cuando los desarrolladores implementan estados adicionales para los nanohilos. Hacen esto cuando extiende la funcionalidad del nanokernel para nuevas plataformas de teléfonos (se conoce como niveles de personalidad). Un nanohilo un proceso ultraligero. Tiene un mini contexto que cambia a medida que los nanohilos se cambian hacia/desde el procesador. Cada nanohilo tiene un estado, al igual que los procesos. Las claves para los nanohilos son el estrecho control que tiene el nanokernel sobre ellos, y los datos mínimos que conforman el contexto de cada uno. Los hilos de Symbian OS se basan en los nanohilos: el kernel agrega el soporte más allá de lo que proporciona el nanokernel. Los hilos en modo de usuario que se utilizan para aplicaciones estándar se implementan mediante los hilos de Symbian OS. Cada hilo contiene un nanohilo y agrega su propia pila en tiempo de ejecución a la pila que utiliza el nanohilo. Symbian OS también agrega a la implementación el manejo de excepciones y la señalización al terminar. Los hilos implementan su propio conjunto de estados encima de la implementación del nanohilo. Como los hilos agregan cierta funcionalidad a la implementación mínima del nanohilo, los nuevos estados reflejan las nuevas ideas integradas en los hilos. Agrega a siete nuevos estados en los que se pueden encontrar sus hilos, con énfasis en las condiciones de bloqueo especiales que pueden ocurrir a un hilo de Symbian OS. Estos estados especiales incluyen el de espera y suspensión e semáforos (normales), variables de mutex y variables de condición. 1.3.2 Procesos Los procesos son hilos de Symbian OS agrupados bajo una sola estructura de bloque de controlde proceso, con un solo espacio de memoria. Puede haber solo un hilo de ejecución, o varios hilos bajo un bloque de control de proceso. Los conceptos de estado del proceso y programación del proceso ya que se han definido los hilos y nanohilos de Symbian OS. Entonces, la programación de un proceso se implementa en realidad mediante la planificación de un hilo y la inicialización del bloque de control de proceso correcto, de manera que el hilo lo utilice para sus necesidades de datos. Los hilos de Symbian OS organizados bajo un solo proceso trabajan juntos de varias formas. En primer lugar, hay un solo hilo individual que se marca como el punto inicial para el proceso. En segundo lugar, los hilos comparten los parámetros de planificación. Si se cambian los parámetros de planificación. Si se cambian los parámetros (método de planificación) para el proceso, se cambian los parámetros para todos los hilos. En tercer lugar, los hilos comparten objetos del espacio de memoria, incluyendo los descriptores de dispositivos y otros descriptores de objetos. Por ultimo, cuando se termina un proceso el kernel termina todos los hilos en el proceso. 1.3.3 Objetos activos Son formas especializadas de hilos, los cuales se implementan de tal forma que se aligere la carga que imponen en el entorno operativo. Los diseñadores de Symbian OS reconocieron el hecho de que había muchas situaciones en la que se bloquearía un hilo en una aplicación. Symbian OS se enfoca en la comunicación, muchas aplicaciones tienen un patrón similar de implementación: escriben datos en unsocket de comunicación o envían información a través

de una tubería, y después se bloquean al esperar una respuesta del receptor. Los objetos activos están diseñados de manera que cuando regresan de este estado bloqueado, solo se hace la llamada aun punto de entrada en su código. La clave para los objetos activos esta en la planificación. Mientras esperan eventos, todos los objetos activos residen dentro de un solo proceso y pueden actuar como u solo hilo para el sistema. El kernel no necesita comprobar de manera continua cada objeto activo para ver si se puede desbloquear. Por lo tanto, los objetos activos en un solo proceso se pueden coordinar mediante un solo planificador que se implementa en un solo hilo, al crear puntos de entrada fijos en el código y mediante el uso de un solo planificador para coordinar su ejecución, los objetos activos forman una versión eficiente y ligera de los hilos estándar. Es importante tener en cuenta en donde se adaptan los objetos activos en la estructura de procesos de Symbian OS. Cuando un hilo convencional realiza una llamada al sistema que bloquea su ejecución mientras esta en el estado de espera, para determinar si alguno necesita parar al estado listo. Los objetos activos se colocan a si mismo en el estado en espera, y esperan a que ocurra un evento especifico. Por lo tanto, el sistema operativo no necesita comprobarlos pero los desplaza cuando se activa su evento específico. El resultado es que se requieren menos comprobaciones de hilos y aumenta el rendimiento. 1.3.4 Comunicación entre procesos Lacomunicación entre procesos es crucial para el rendimiento del sistema. Los hilos, en especial en forma de servidores del sistema, se comunican de manera constante. Un socket es el modelo básico de comunicación utilizado por Symbian OS. Es una línea de tubería de comunicación abstracta entre dos extremos. La abstracción se utiliza para ocultar los métodos de transporte y la administración de los datos entre los extremos. Symbian OS utiliza el concepto de un socket para comunicarse entre los clientes y servidores, de hilos a dispositivos y entre los mismos hilos. El modelo del socket también forma la base de la E/S de dispositivos. La abstracción, es la clave para que este modelo sea tan útil. Toda la mecánica del intercambio de datos con un dispositivo se administra mediante el sistema operativo, en vez de que lo haga la aplicación. Por ejemplo, los sockets que funcionan a través de TCP/IP en un entorno de red que se puede adaptar con facilidad para trabajar en un entorno Bluetooth, al cambiar los parámetros en el tipo de socket utilizado. El sistema operativo se encarga de la mayor parte del trabajo de intercambio de los datos en un cambio de este tipo.

c. Administración de la memoria Como un sistema operativo de propósito general efectivo, Symbian OS también debe proporcionar un modelo de administración de la memoria. Sin embargo, como el

almacenamiento en los teléfonos inteligentes por lo general esa muy limitado. El modelo de memoria es restringido y no utiliza un modelo de espacio de memoria virtual/intercambio para su administración dela memoria. Sin embargo, utiliza la mayoría de los otros mecanismos que hemos visto para administrar la memoria, incluyendo las MMUs de hardware. 1.4.1 Sistemas sin memoria virtual Muchos sistemas de cómputo no tienen las herramientas para proporcionar memoria virtual completa con paginación bajo demanda. Considere el espacio de memoria utilizado en la mayoría de los dispositivos de plataforma pequeñas. Por lo general, estos sistemas tienen dos tipos de almacenamiento: RAM y memoria flash. La RAM almacena el código del sistema operativo; la memoria flash se utiliza para la memoria operativa y el almacenamiento permanente (archivos). A menudo es posible agregar memoria flash adicional a un dispositivo, y esta memoria se utiliza de manera exclusiva para el almacenamiento definido. La usencia de memoria virtual con paginación bajo demanda no indica la ausencia de la administración de memoria. De hecho, la mayoría de las plataformas más pequeñas se basan en hardware que incluye muchas de las características de administración de los sistemas más grandes. Esto incluye características como la paginación, la traducción de direcciones y la abstracción de direcciones virtuales/físicas. La ausencia de memoria virtual solo indica que las páginas no se pueden intercambiar de la memoria y guardarse en el almacenamiento externo, pero aun se utiliza la abstracción de las páginas de memoria. Las páginas pueden reemplazar, pero la página que se va a reemplazar solo se descarta. Esto significa que solo se pueden reemplazar páginas de código, ya que solo esasse respaldan en la memoria flash. La administración de la memoria consiste en las siguientes tareas:  Administración del tamaño de la aplicación. El tamaño de una aplicación (código y datos) tiene un efecto contundente en cuanto a la forma que se utiliza la memoria. Se requiere habilidad y disciplina para crear software pequeño. La mayoría de los sistemas operativo mas pequeñas no recomiendan la vinculación estática en los módulos.  Administración del montículo. El montículo (espacio para la paginación dinámica de memoria) se debe administrar en forma muy estricta en una plataforma más pequeña. Por lo general, el espacio del montículo se limita en las plataformas mas pequeñas para obligar a los programadores a reclamar y reutilizar es espacio del montículo lo mas que puedan. Si se aventuran más allá de los límites, se producen errores en la asignación de la memoria.  Ejecución en el lugar. Esto significa que la memoria flash se asigna al espacio de direcciones virtuales y los programas se pueden ejecutar directamente de la memoria flash, sin necesidad de copiarlos primero en la RAM. Al hacer esto se reduce a cero el tiempo de carga, las aplicaciones pueden iniciar en forma instantánea y además no hay que ocupar la RAM, que es escasa.  Carga de DLLs. La decisión de cuando se deben cargar las DLLs puede afectar en la percepción del rendimiento del sistema. Por ejemplo, es más aceptable cargar todas las DLLs

cuando se carga una ampliación por primera vez en la memoria, que cargarlas en tiempos de retraso en la carga de una aplicación que losretrasos en la ejecución. Hay que tomar en cuenta que tal ves las DLLs no se necesiten cargar. Podría ser el caso si (a) ya se encuentran en la memoria, o (b) están contenidas en el almacenamiento flash externo.  Transferencia de la administración de la memoria al hardware. Si hay una MMU disponible, se utiliza en toda su extensión. De hecho, entre mas funcionalidad se pueda poner en la MMU, mejor será el rendimiento del sistema. Aun con la regla de ejecución en el lugar, las pequeñas plataformas de todas formas necesitan memoria que esta reservada para la operación del sistema operativo. Esta memoria se comparte con el almacenamiento permanente y por lo general se administra en una de dos formas. 1.4.2 Como direcciona Symbian OS la memoria Como Symbian OS es un sistema operativo de 32 bits, las direcciones pueden variar hasta 4 GB. Emplea las mismas abstracciones que los sistemas más grandes: los programas deben utilizar direcciones virtuales, que el sistema operativo asigna a direcciones físicas. Symbian OS divide la memoria en páginas virtuales y marcos físicos. El tamaño de los marcos es por lo general de 4KB, pero puede ser variable. Con tamaños limitados de memoria, Symbian OS no puede dedicar 1 MB a la tabla de páginas ya que un tamaño de un marco de 4 KB representa a una tabla de páginas con más de un millón de entradas. Además, los tiempos de búsqueda y acceso para una tabla tan grande serian una carga para el sistema. Para solucionar esto, Symbian OS adopta una estrategia de tabla de páginas de dos niveles, como se muestra en la figura.El primer nivel conocido como directorio de páginas, proporciona un vínculo al segundo nivel y se indexa mediante una proporción de la dirección virtual (los 8 bits de en medio). Este directorio se mantiene en la memoria y el TTBR (translation table base register, registro base de tabla de traducción) apunta a el. Una entrada en el directorio de páginas apunta al segundo nivel, que es una colección de tablas de páginas. Estas tablas proporcionan un vínculo a una página específica en memoria y se indexan mediante una porción de la dirección virtual. Por ultimo, la palabra en la página referenciada se indexa mediante los 12 bits de menor orden de la dirección virtual. El hardware ayuda en este cálculo de asignación de dirección virtual a física. Aunque Symbian OS no puede asumir la existencia de ningún tipo de asistencia de hardware, la mayor parte de las arquitecturas en la que se implementa tienen MMUs. Cuando una página no esta en la memoria, se produce una condición de error debido a que todas las páginas de memoria de una aplicación se deben cargar al momento de iniciar esta aplicación (no hay paginación bajo demanda). A pesar de la falta de intercambio, la memoria es sorprendentemente dinámica en Symbian OS. El contexto de las aplicaciones se cambia a través de la memoria, se cargan sus requerimientos en la memoria cuando empiezan su ejecución. Las paginas de memoria que requiere cada aplicación se pueden solicitar de manera estática al sistema operativo, el momento de cargar la aplicación en la memoria.

El espacio dinámico (montículo)esta limitado, por lo que también se pueden realizar peticiones estáticas para el espacio dinámico. Los marcos de memoria se asignan a las páginas desde una lista de marcos libres, si no hay marcos libres disponibles, entonces se genera una condición de error. Los marcos de memoria utilizados no se pueden reemplazar con paginas de una aplicación entrante, incluso si los marcos son para una aplicación que no se este ejecutando en ese momento. Hay cuatro versiones distintas del modelo implementación de memoria que utiliza Symbian OS. Cada modelo se diseño para ciertos tipos de configuración de hardware.  El modelo de movimiento. Se diseño para las primeras arquitecturas del ARM. El directorio de páginas en el modelo de movimiento es de 4 KB de largo, y cada entrada contiene 4 bytes, para un tamaño del directorio de 16 KB. Las páginas de memoria se protegen mediante bits de acceso asociados con los marcos de memoria y mediante el etiquetado del acceso a la memoria con un dominio. Los dominios se registran en el directorio de páginas y la MMU implementa los permisos de acceso para cada dominio. Aunque no se utiliza la segmentación en forma explicita, hay una organización para la distribución de la memoria: hay una sección para los datos asignados por el usuario y una sección de kernel para los datos asignados por el kernel.  El modelo múltiple. Se desarrollo para la versión 6 y posteriores de la arquitectura ARM. La MMU difiere de la utilizada en versiones anteriores. La nueva versión de la arquitectura ARM reviso y mejoro los bits de acceso encada, marco de pagina, y abandono el concepto principal.  El modelo directo. Modelo directo de memoria asume que no hay MMU. Este modelo no esta permitido en los teléfonos inteligentes. La falta de una MMU ocasionaría severos problemas de rendimiento. Este modelo, es útil para los entornos de desarrollo en lo que la MMU se debe deshabilitar por alguna razón.  El modelo del emulador. Se desarrollo para proveer un emulador de Symbian OS para Windows. Tiene unas cuantas restricciones en comparación con una verdadera CPU de destino. El emulador se ejecuta como un solo proceso de Windows, por lo que el espacio de direcciones esta restringido a 2GB y no a 4GB. Toda la memoria que se proporciona al emulador es accesible para cualquier proceso de Symbian OS, y por lo tanto no hay protección de memoria disponible.

d. Entrada y Salida La estructura de entrada/salida de Symbian OS refleja la de otros diseños de sistemas operativos. Se resaltaran algunas de las características únicas que Symbian OS utiliza para enfocarse en su plataforma de destino. 1.5.1 Drivers de dispositivos Los driver de dispositivos se ejecutan como código privilegiado del kernel para proporcionar

acceso al código de nivel de usuario a los recursos protegidos del sistema. Al igual que en los casos de Linux y Windows, los drivers de dispositivos representan el acceso al hardware mediante el software. En Symbian OS, un driver de dispositivos de divide en dos niveles: un driver de lógico (LDD) y un driver de dispositivos físico (PDD). El LDD presenta una interfaz a losniveles superiores del software, mientras que el PDD interactúa de manera directa con el hardware. En este modelo el LDD puede utilizar la misma implementación para una clase específica de dispositivos, mientras que el PDD cambia con cada dispositivo. Symbian OS suministra muchos LDDs estándar. Algunas veces, si el hardware es muy estándar o común, Symbian OS también proporciona un PDD. Los LDDs y los PDDs se pueden cargar en forma dinámica mediante los programas de usuario, si no existen ya en la memoria. Se proporcionan herramientas de programación si es necesario cargarlos. 1.5.2 Extensiones del kernel Las extensiones del kernel son drivers de dispositivos que Symbian OS carga en tiempo de inicio. Como se cargan en tiempo de inicio, son casos especiales que se necesitan tratar de manera distinta a los drivers de dispositivos normales. Son distintas de los drivers de dispositivos normales. La mayoría de estos drivers de dispositivos se implementan como LDDs y forman parejas con los PDDs; además se cargan cuando es necesario en tiempo de inicio y están orientadas de manera específica a ciertos dispositivos; por lo general no forman parte con PDDs. Están integradas en el procedimiento de inicio. Estos driver de dispositivos especiales se cargan e inician justo después de que inicia el programador. Implementan funciones cruciales para los sistemas operativos: servicios de DMA, administración de la pantalla, control de buses para los dispositivos periféricos. Estos drivers se proporcionan por dos razones. En primer lugar, coinciden con lasabstracciones de diseño orientado a objetos que hemos visto como característica del diseño de microkernels. En segundo lugar, permite que las plataformas separadas en la que se ejecutan Symbian OS ejecuten drivers de dispositivo especializados, los cuales habilitan el hardware para cada plataforma sin tener que volver a compilar el kernel. 1.5.3 Acceso directo a la memoria Symbian OS acepta el uso de hardware de DMA. Consiste en un controlador de un conjunto de canales de DMA. Cada canal proporciona una sola dirección de comunicación entre la memoria y un dispositivo; por lo tanto, la transmisión bidireccional de los datos requiere dos canales de DMA. Hay por lo menos un par de canales de DMA dedicados al controlador LCD de la pantalla. Además, la mayoría de las plataformas ofrecen cierto numero de canales de DMA generales. Cuando un dispositivo transmite datos a la memoria, se activa una interrupción del sistema. El PDD utiliza el servicio de DMA que proporciona el hardware de DMA para el dispositivo

transmisor: la parte del dispositivo que se interconecta con el hardware. Symbian OS implementa dos niveles de software entre el PDD y el controlador de DMA: un nivel de DMA de software y una extensión del kernel que se interconecta con el hardware de DMA. El mismo nivel de DMA se divide en un nivel independiente de la plataforma y en un dependiente. Como extensión del kernel, el nivel de DMA es uno de los primeros drivers de dispositivos que el kernel inicia durante el procedimiento de inicio. El soporte para el DMA es complicado. Symbian OS soportamuchas configuraciones de hardware distintas, por lo cual se puede suponer una sola configuración de DMA. La interfaz de DMA se estandariza entre una plataforma y otra, y se suministra en el nivel independiente de la plataforma. Como el hardware de DMA se ve como un dispositivo en su propio derecho, esta forma de implementar el soporte tiene sentido, debido a que es paralela a la forma en que Symbian OS admite todos los dispositivos. 1.5.4 Caso especial: medios de almacenamiento Los drivers de los medios son una forma especial de PDD en Symbian OS, que el servidor de archivos utiliza de manera exclusiva para implementar el acceso a los dispositivos de los medios de almacenamiento. Como los teléfonos inteligentes pueden contener medios fijos y removibles, los drivers de medios deben reconocer y soportar una variedad de formas de almacenamiento. El soporte de Symbian OS incluye para los medios un LDD estándar y una API de interfaz para los usuarios. El servidor de archivos en Symbian OS puede aceptar hasta 26 unidades distintas al mismo tiempo. Las unidades locales se distinguen mediante su letra de unidad, como en Windows. 1.5.5 Bloqueo de E/S Symbian OS trata con el bloqueo de E/S por medio de objetos activos. Los diseñadores se dieron cuenta que el peso de todos los hilos que esperan un evento de E/S afecta a los demás hilos en el sistema. Los objetos activos permiten que el sistema operativo maneje las llamadas del bloque de E/S, en vez de que lo haga el mismo proceso los objetos activos se coordinan mediante un solo planificador y se implementanen un solo hilo. Cuando el objeto activo utiliza una llamada de bloqueo de E/S, lo señala el sistema operativo y se suspende al proceso suspendido a si mismo. Cuando se completa la llamada de bloqueo, el sistema operativo despierta al proceso suspendido y esta continua su ejecución como si una función hubiera regresado con datos. 1.5.6 Medios removibles Representan un dilema interesante para los diseñadores de sistemas operativos. Cuando se inserta una tarjeta SD en la ranura del lector, es un dispositivo justo igual que los demás. Necesita un driver, una estructura de bus y tal vez se comunique con la CPU por medio de DMA. Sin embargo, el hecho de quitar este medio es un problema grave para este dispositivo ¿Cómo detecta el sistema operativo la inserción y remoción, y como debe tener en cuenta el modelo la ausencia de una tarjeta de medios? Symbian OS empieza su implementación de los medios removibles con sus similitudes. Cada tipo de medio removible tiene características comunes para todos los demás:

1. Todos los dispositivos se pueden insertar y remover. 2. Todos los medios removibles se pueden remover, es decir, mientras están en uso. 3. Cada medio puede reportar sus capacidades. 4. Las tarjetas incompatibles se deben rechazar. 5. Cada tarjeta necesita energía. Para aceptar medios removibles, Symbian OS proporciona controladores de software que controlan cada tarjeta admitida. Los controladores funcionan con los drivers de dispositivos para cada tarjeta, también en software. Cuando se inserta una tarjeta se crea un objeto de socket.

e. Sistema de Almacenamiento f. Seguridad g. Comunicación

CONCLUSIONES REFERENCIAS