• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
40,584
On Slideshare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
916
Comments
0
Likes
4

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Estructuras en SOs Cecilia Hernández 2007-1
  • 2. Objetivos SO
    • Definir capa de software cuyos componentes maximicen:
      • Confiabilidad
      • Seguridad
      • Extensibilidad
      • Desempeño
  • 3. Por qué es difícil escribir un SO
    • Complejidad
      • Millones de líneas de código
      • Miles de desarrolladores y probadores
    • Ambiente de programación delicado
      • Se ejecuta sobre HW
      • Un error puede hacer que sistema se caiga dejando todos los usuarios sin servicio
    • Concurrencia e interrupciones
    • Restricciones de compatibilidad con versiones previas
  • 4. Componentes más importantes del SO
    • Procesos
      • Manejo de colas de estados, planificación, protección, comunicación y sincronización
    • Memoria
      • Manejo VM por proceso, protección
    • Almacenamiento secundario
      • Usado por Sistema de archivos y memoria virtual
      • Información persistente, comunicación con controlador de disco, protección
    • E/S
      • Incluyendo redes
    • Autentificación
    • Intérprete de comandos
    • Auditoria de uso de recursos de sistema
      • Tiempo, memoria, disco
  • 5. Estructura de SOs
    • No siempre claro como interactúan todos los módulos del SO
    Administración De Memoria E/S Adm Almacenamiento secundario Sist Archivos Protección Auditoria Adm Procesos Interprete de Comandos Servicios de informacion Manejo de errores
  • 6. Enfoque más simple-Monolítico
    • Una biblioteca grande
    • Cualquier función puede llamar a cualquier otra
    Funcionalidad SO Programas usuario HW SO
  • 7. Diseño monolítico
    • Ventaja
      • Comunicación entre módulos mediante llamadas a procedimientos
        • Barato en tiempo, interfaz simple y homogénea
    • Desventajas
      • Cuando sistema crece se hace
        • Difícil de entender
        • Difícil de modificar
        • Difícil de mantener
      • Baja confiabilidad
        • No exite aislación entre componentes
    • Alternativas?
      • Encontrar manera de estructurar componentes para simplicar su diseño, implementación y mantención
  • 8. Estructura por niveles
    • Idea: Diseñar e implementar SO mediante un conjunto de niveles
    • Primer sistema de este tipo propuesto por DIJKSTRA con el sistem THE (1968)
      • Nivel 5: Adminitrador de tareas
        • Ejecuta programas de usuarios
      • Nivel 4: Manejadores de dispositivos
        • Maneja dispositivos y proporciona buffers
      • Nivel 3: Consola
        • Implementa consolas virtuales
      • Nivel 2: Administrador de Páginas
        • Implementa memoria virtual para cada proceso
      • Nivel 1: kernel
        • Implementa un procesador virtual para cada proceso
      • Nivel 0: hardware
    • Cada nivel puede ser probado y verificado independientemente
  • 9. Desventajas estructura por niveles
    • Estructura jerárquica es demasiado inflexible
      • Sistemas reales tienen ciclos de uso
        • Sistema de archivos requiere servicios de memoria virtual
      • Memoria virtual puede usar archivos para respaldos en discos
    • Bajo desempeño
      • Cada cruce entre niveles involucra una sobrecarga (overhead)
  • 10. Usos
    • En cierto grado se pueden definir algunos niveles
    • Un ejemplo en sistemas modernos
      • Separar rutinas específicas del HW del núcleo del SO
        • Proporciona portabilidad
        • Mejora entendimiento de sistema por la abstracción en cada nivel
    Núcleo SO (sistema archivos, planificador, Llamadas a sistema) Abstracción HW Nivel (manejadores disp, Rutinas en assembly )
  • 11. Microkernels
    • Filosofía
      • Jerarquía estricta no es buena
      • Modularidad es buena
    • Diseño
      • Minimizar que va en el kernel
      • Organizar el resto del SO como procesos de nivel usuario
        • Ejemplo, Sist de Archivos como un servidor
      • Procesos se comunican mediante pasos de mensajes
        • Como en un sistema distribuido
    • Ejemplos
      • Hydra (1970s)
      • Mach (1985-1994)
  • 12. Ilustración SO Microkernel Hardware microkernel Procesos de sistema Procesos usuarios Memoria virtual Comunicación protección Control CPU Sistema de archivos hebras red planificador Paginación Firefox powerpoint apache Modo usuario kernel
  • 13. Ventajas/desventajas microkernels
    • Ventajas
      • Simplicidad
        • Kernel pequeño
      • Extensibilidad
        • Se puede agregar nueva funcionalidad en modo usuario
      • Confiabilidad
        • Servicios SO aislados en modo usuario
    • Desventajas
      • Bajo desempeño
        • Comunicación mediante mensajes no tan bueno como llamadas a sistema
  • 14. Estado del arte: Modulos kernel
    • Idea básica: usuarios pueden proporcionar módulos, los cuales se ejecutan directamente en el espacio de dirección del kernel.
    • También llamados Loadable Kernel Modules (LKM)
      • Son cargados después que kernel base está en ejecución
    • Ventajas
      • Buen desempeño
      • Provee extensibilidad a SO
    • Un módulo interesante accesible en linux 2.6.20
      • KVM (Kernel-based VM for linux) kvm.ko
        • Funciona en arquitecturas que soportan virtualización
        • (Intel Dual Core es una de ellas) ref http://www.linux-watch.com/news/NS5168864143.html
        • Usuarios pueden ejecutar múltiples máquinas virtuales ejecutando linux o Windows. Cada máquina virtual tiene su propio hw virtualizado
    • Desventajas
      • Módulos pueden comprometer seguridad y confiabilidad
        • Manejadores de dispositivo causan el 85% de las caidas en Windows 2000