Arquitectura de Sistemas Operativos

Arquitecturas de Sistemas Operativos

Investigación en software de sistemasExtensibilidad en SOs: arquitecturaEjemplos de sistemas

© José Antonio Gómez Hernández, 2004-05

Diseño de SOs - 5º Ing. Informática 2

Introducción

¿Esta muerta la investigación sobre SOs?Motivos para la investigación

Cambios tecnológicosAvances en software

ProblemasRepaso de arquitecturas de SOs:

Arquitectura MonolíticaArquitectura Microkernel


¿Esta desfasada la investigación en software de sistemas? Rob Pike

Linux y Windows 2000 están basados en un modelo de SO de los años 60.El énfasis en la eficiencia esta falto de salud¿Existen nuevas visiones?


¿Estamos construyendo los sistemas correctos?

Mark Weiser

“Where virtual reality puts people inside a computer-generated world, ubiquitous computing forces the computer to live out here in the world with people.”

http://www.ubiq.com/hypertext/weiser/UbiHome.html


Cambios tecnológicos

CPU’s muy rápidas, grandes memorias, redes de banda anchaMovilidad, inalámbricas, ópticas, fuentes de alimentación/baterias, tamañoParalelismo, buses, compiladoresDispositivos de E/S, pantallas planas, sonido, video, vozComputación Bio/Molecular/Cuántica/OpticaSistemas empotrados: nanotecnología, exploración espacial, vehículos, medicina


Avances en Sistemas Software

PorcupineElephant2KGlobusLegionParameciumRedes ActivasCellular DISCOExokernelSpinPlan 9

Classroom2000Easy LivingPortolanoJiniKerberosSesame…

ApertosChoicesGlobeMilleniumOff+CloudsJavaOSSpringOGIOMGCORBA

DCOMDCEAgentes móvilesWWWRMICool TownEndeavorOxygen


Problemas

PortabilidadSeguridadDependenciasVisión de mundo centrada en la máquinaFiabilidad/robustez

SPIN

UNIX

MACH

ExokernelUso de un grupo de máquinasGestión de grupos de máquinasEscalabilidadMigración de tareas y funcionesActualización de softwareMovilidad


Enfoque

Re-evaluar los modelos existentes de SOsCuestionar suposicionesVisita guiada para el cambioUtilizar la imaginación atemperada con una preocupación prácticaMirar 10 años hacia delante


Temas de Investigación

Seguridad dinámica

Sistemas distribuidos

Muchos

computadores

por persona

! Radio, buses corporales, computadores chip, potencia

! Temas: Mantener el entorno en dispositivos personales; Protección, fiabilidad, seguridad

! Configuración sencilla, control de versiones, mantenimiento de licencias, tiempo de vida de los datos

! Negociación y colaboración

! Encriptado / Capacidades Software! Autentificación / Certificados! Detección de intrusiones! Políticas dinámicas, redes activas

! Objeto Bus – integra DCOM,OMG,RMi,Jini, ..! Objetos distribuidos – brokers, trader, …! Middleware, personalización,

especialización! Fiabilidad (reliabilty)


Temas investigación (2)

Centrados en la red

Conscientes de

la arquitectura

Modelo de aplicación

! La migración de usuarios y aplicaciones es un problema de mantenimiento

! Asignación de recursos a usuario en la red

! Igualar los recursos a las necesidades (QoS)

! Autoconfiguración para evitar mantenimiento

! Lo que necesitas es lo que obtienes! Reconfiguración al vuelo, optimización

! Representar usuarios, recursos, y entornos como entidades de red no como entidades máquina.

! Las operaciones se realizan sobre entidades de red, no representaciones en máquinas.


Enfoque ( y ii)

Hacer las aplicaciones centradas en la red a través de middelware personalizable y re-organizable.Añadir mecanismos de ligadura para identificar entidades de red.


En clase

Veremos la investigación en SO de los últimos años.Examinaremos en impacto de nuevas ideas sobre futuros sistemas operativosEvaluaremos algunos ejemplos reales…¿Buscaremos nuevas soluciones?


Objetivos del SO

Conveniencia: Debe facilitar la labor de programación de aplicaciones

Abstracción:Esconder los detalles del hardwarePresentar una interfaz uniforme para diferentes dispositivos

GeneralidadCambiar en las características de una aplicación no debe suponer su rediseño

Extensibilidad:Debe permitir el desarrollo, prueba e introducción de nueva funcionalidad sin interferir el servicio actual.


Objetivos (y ii)

Escalabilidad:El sistema debe ser capaz de enfrentarse en todo momento a condiciones de carga crecientes

Eficiencia:Hacer buen uso de los recursos y ser rápido

Robustez:No averías del sistema debidas a aplicaciones maliciosas o erróneas

Protección:Debe suministrar imparcialidad, y seguridad


Arquitectura

“Instead of getting serious about Linux, get serious about architecture … It’s not about the component technology and not about the processor or the operating system. It’s about architecture that delivers the benefits and the technology that enables the architecture”

Michael TiemannCTO of Red Hat


¿Por qué necesitamos arquitectura de sistemas?


¿Por qué la necesitamos (y ii)?

Para diseñar sistemas útiles y extensiblesPara establecer propiedades no funcionales, por ejemplo, Calidad de Servicio (QoS)Para implementar sistemas seguros, correctos y robustos.


Estructura del sistema

Sistema software = Conjunto de componentes y sus interconexiones con varias dependencias.

Interconexiones! Varían en

funcionalidad y rendimiento

!Componentes


Componentes

Aplicación: por ejemplo, simulación de tráfico, predicción meteorológica, edición de textos, etc.Subsistemas con tareas específicas:

Control – ejemplo, shellProtección – ej. FirewallContabilidad – ej. VigilanciaServicio – ej. Servidor de archivosSoporte – ej. Manejador de disco

Funciones básicas: ej. sincronización


Interdependencias entre componentes

Llamada: main() invoca a printf()Serialización: hebra1 después de hebra2Comunicación: mensaje de emisor a receptorMaestro/esclavo: shell invoca a una aplicaciónPares: productor y consumidorCliente/servidor: aplicación utiliza un servidor de archivos….


Estructura de sistemas

¿Cómo implementamos un componentes?¿Podemos imponer alguna ordenación dentro de la estructura del sistema?

Manejadorde disco Main o Procedimiento

Módulo o TADObjeto o claseProceso o hebras

Capa 1

Capa 2

Capa 3


Enfoques para manejar la complejidad

Enfoques monolíticos:Kernels de capasKernels modularesKernels orientados a objetos

Alternativas;Kernels extensiblesMicrokernels


Arquitectura monolítica

La mayoría de servicios dentro del kernel (modo privilegiado) ⇒Protección del kernel frente a las aplicaciones, y las aplicaciones entre si.Componentes del kernel no protegidosLas aplicaciones deben confiar en el kernel.

AplicaciónAplicación

Hardware

Manejador de dispositivo


Planificador

ProtocolosSistema de archivos

SO

Mod

o pr

ivile

giad

o

Llamada al sistema


Arquitectura microkernel

Las características a continuación

AplicaciónAplicación

Hardware



Despachador + IPC básico

ProtocolosSistema de archivos

µ-kernel Modo privilegiado


Pros y contras del µ-kernel

Ventajas:Más fácil de probar, verificar y modificar.Mejora la seguridad y robustezMejora el mantenimientoCoexistencia de varias APIsExtensibilidad

Inconvenientes:Esfuerzo de descomposiciónMenor rendimientoSobrecarga de comunicaciones


El gran argumento contra los sistemas microkernels

Comentario: Esto es verdadero para la primera generación de sistemas, como son:

Mach (CMU, OSF)Chorus (INRIA, Sun)Amoeba (Vrije Universiteit)L3 (GMD)

Mal rendimientoSon grandes e inflexibles

! IBM WorkPlace OS: 2.000.000.000 $US! Win NT: 8 años, 1000 personas


El desastre de los 100 µsec


Costes arquitectónicos - monolítico

1 llamada al sistema(incluido la entrada y salida del modo kernel)1 llamada al procedimiento (call+ return)

Aplicación

Hardware

Manejador de disco

Sistema de archivos get_disk_block()

write_file(nombre, reg)

Ambos módulos pueden compartir datos


Coste arquitectónico – µ-kernel

1. 1 llamada al servidor de archivos:! Entrar/salir al/del µk! Transferir mensaje! Cambiar de espacio de

direcciones

2. 1 llamada al manejador *3. Réplica al servidor *4. Réplica a la aplicaciones*

* Cada paso tiene el coste del 1.

Aplicación

Hardware

Manejador de disco

Sistema de archivos

get_disk_block()

write_file(nombre, reg)

x4


Ventajas de arq. monolítica

El kernel tiene acceso a todo, potencialmente:

Todas las optimizaciones son posiblesPodemos implementar todas las técnicas, mecanismos, y conceptos.

Podemos extenderlo bien:añadiendo más código al kernel.módulos P. ej. Linux 2.4.18 tiene 2.7 millones

de líneas de código


Modulos de carga dinámica

Estos permiten añadir nueva funcionalidad al sistema en tiempo de ejecución.Limitaciones:

No podemos afectar a la funcionalidad compilada estáticamente.No es fácil confinar un error dentro del módulo donde se produce. Si bien hay intentos (técnicas Software Fault Isolation) esto no son lo suficientemente eficientes.


¿Por qué nuevas alternativas?

Existen muchos tipos de sistemas (comparable a los tipos de coches), con

Algunos requisitos comunes (ej. cuatro ruedas)Con requisitos específicos (ej. coches con ABS)

¡ No todos los sistemas deben que ser iguales! ¿Utilizarías este piloto y este coche para transportar pescado fresco desde Motril a Granada?


Conclusión

No existe un único sistema que sea ideal para todos los propósitos.Necesitamos sistemas que se puedan adaptar de diferentes formas. ¡Necesitamos sistemas extensibles!.


¿Cómo solventar los problemas de las arquitecturas µ-kernel?

En primera instancia, dado que el problema radica en el coste de comunicaciones, se ataca el problema de reducir este -> 2ª generación de µ-kernel. El ejemplo más avanzado es L4.Actualmente sigue sin resolverse el problema más general: ¿cómo organizamos todos los servicios del SO en modo usuario?

Sistema Monolítico:Linux

Sistema Monolítico:Linux

Arquitectura general del sistemaExtensiones al sistema


Arquitectura de Linux


Arquitectura concreta

La arquitectura concreta hace referencia a como esta construido el sistema.Sirve como especificación para que los desarrolladores extiendan o modifiquen el código fuente actual.


Componente: Planificador


Componente: Memoria


Componente: Sistema de archivos


Componente: IPC


Componente: Subsistema de Red


Extensiones

Dos forma:Extendiendo del código: los desarrolladores implementan, modifican la funcionalidad del kernelmodificando, añadiendo, nuevo código.

• Problemas: el tamaño del código y sus dependencias. Ver siguiente transparencia.

Módulos de carga dinámica – podemos enlazar un módulo en tiempo de ejecución junto con el resto del código del kernel.


Navegación por el código:http://plg.uwaterloo.ca/~itbowman/pbs/


Módulos

El planificador de procesos también suministra soporte para la carga dinámica de módulos (cada módulo representa funcionalidad kernel que puede ser cargada después de que el kernel inicie su ejecución).Esta funcionalidad se utiliza para:

Implementar manejadores de dispositivos, La abstracción de interfaces que utilizan el sistema virtual de archivos y la interfaz de red, …..Para añadir nuestra propia funcionalidad


Un ejemplo de módulo

Un versión del “Hola Mundo”#define MODULE#include <linux/module.h>int init_module(void) {printk(“<1>Hola, Mundo\n”);return 0;}void cleanup_module(void) {printk(“<1>Adios mundo cruel\n”);}

Que compilamos en instalamos:% gcc –c hola.c% insmod ./hola.oHola, Mundo% rmmod holaAdios mundo cruel%


Enlazado de un módulo


Limitaciones de los módulos

Existe código que debe enlazarse estáticamente. Esto ocurre cuando debemos modificar estructuras de datos o funciones enlazadas estáticamente.Ejemplos:

Necesitamos un campo más en el descriptor de proceso.No podemos enlazar dinámicamente un módulo que cambie el algoritmo de asignación de marcos de páginas, o el algoritmo de paginación.


Análisis final

Rendimiento: bueno – Debemos prestar atención al IPC en ejecución. Hay pocas capas-> pocas traducciones y conversiones.Modificabilidad: mala – un cambio en el kernel puede afectar a todos los componentes.Reusabilidad: mala – sistema de archivos y red fuertemente acoplados e integrados al kernel.Portabilidad: buena – unos pocos componentes confinan el manejo de dispositivos.Integrabilidad: buena – el kernel puede soportar diferentes sistemas de archivos y dispositivos.

Sistema Microkernel:Windows 2000/XP

Sistema Microkernel:Windows 2000/XP

Arquitectura general del sistemaExtensiones al sistema


Introducción

En la primera parte del tema hemos visto la estructura general de un sistema microkernel, ahora describiremos dos implementación concretas:

Windows 2000, XP, etc. – veremos la arquitectura interna y el funcionamiento de los componentes de núcleo, y el papel de los subsistemas y su funcionamiento.Hurd – veremos su estructura interna.


Windows 2000: arquitectura

Executive Services APII/O

SystemSecurityMonitor

Win32GDI

ObjectServices

MemoryMgmt

Processes/Threads

Exec.RTL

DeviceDrivers

Hardware Abstraction Layer (HAL)

Kernel

Object ManagementFileSystems

I/ODevices

DMA/BusControl

CacheControl

Clocks/Timers

PrivilegedArchitecture

InterruptDispatch

Registry

User

Kernel

SystemProcesses

Services User Apps EnvironmentSubsystems

Subsystem DLLInterface DLL

Session MgrWinLogon

ReplicatorAlerter

Event Log

Win32POSIXOS/2


Componentes de la arquitectura (i)

Ejecutivo de Windows 2000:Suministra las funciones genéricas del SO de alto nivel:

• Crear y destruir procesos y hebras• Gestión de memoria• Entradas/salidas• IPC• Seguridad

Se ejecuta en modo kernelSu API no esta documentada (Funciones Nt_) – se accede indirectamente a través de las APIs de los subsistemas.


El kernel de Windows 2000 suministra las funciones de bajo nivel del SO:

PlanificaciónDespacho de interrupciones y excepciones.Sincronización en multiprocesadores.

HAL (Capa de Abstracción Hardware):Aísla al Ejecutivo y al Kernel de los detalles de la plataforma, por ejemplo, placas base.Presenta un modelo de interfaz hardware de E/S uniforme para los manejadores.

Componentes de la arquitectura (ii)


Componentes de la arquitectura (3)

Manejadores de dispositivos:Modulos kernel cargables que hacen de interfaz entre el gestor de E/S y el hardware apropiado.

• Manejadores de sistemas de archivos, de protocolosde red, manejadores de dispositivos hardware.

Los manejadores pueden invocar a las funciones HAL para acceder al hardware

Win32 User/GDI (Interfaz Gráfica de Dispositivos)Implementa la interfaz grafica de usuario (GUI)Manipulación de ventanas, controles de la interfaz de usuarioDibujo


Subsistemas de entorno

Tres subsistemas: OS/2, Posix, y Win32.Suministra la interfaz documentada entre las aplicaciones y la API nativa de 2000. Cada subsistema define una API.Los ejecutables están ligados a un único subsistema.Las aplicaciones de usuario no invocan directamente losservicios de Windows – lo hacen vía subsistemas DLL.


Componentes del subsistema de entorno

API DLLs• Para Win32: Kernel32.DLL, Gdi32.DLL, User32.DLL

Proceso subsistema:• Para Win32: CSRSS.EXE

Código GDI modo Kernel (solo Win32)

ExecutiveDeviceDriversHardware Abstraction Layer (HAL)

Kernel

User

Kernel

Win32User AppsSubsystem DLL

System & ServiceProcesses

POSIXOS/2

Win32User/GDI

Environment Subsystems

1

2

3

1

2

3


Papel de los componentes de subsistema

API DLLsExporta las APIs definidas por el subsistemaLas implementa llamando a los servicios nativos, o solicitando al proceso de subsistema que realice el trabajo.Mantienen el estado global del subsistema.

Win32K.SYSImplementa las funciones Win32 User/GDIUtilizada también por los subsistemas POSIX y OS/2 para acceder a la pantalla.


Subsistema Win32

Implementado en el proceso CSRSS.EXE (subsistemacliente/servidor):

Soporta ventanas consola (texto)Crea y destruye procesos y hebras Win32

El manejador en modo kernel WIN32K.SYS contiene:Gestor de ventanas

• Entrada de teclado/ratón, salida pantalla, ..Interfaz de Dispositivo Gráfico (GDI)

Los subsistemas DLLs proyectan las funciones de la API Win32 sobre llamadas de servicio al sistema en modo kernel

USER32.DLL, KERNEL32.GDI -> NTOSKRNL


Subsistema POSIX

Portable Operating System Interface based on UnixIncluido para satisfacer los requistos del Gobierno de EEUU.Windows 2000 implementa POSIX 1003.1Suministra un conjunto limitado de servicios:

• No se pueden crear hebras, ventanas o utilizarsockets.

Los ejecutables se enlazan con la biblioteca del subsistema POSIX (Psxdll.dll)Las bibliotecas comerciales Unix-a-Win32 son una mejorsolución para portar aplicaciones.


La mayoría de APIs kernel Win32La mayoría de APis Win32 User/GDIUnas pocas APIs Win32

Invocación de un subsistema

NtDll.dllUser

Kernel

Win32User AppsSubsystem DLL

System & ServiceProcesses

POSIXOS/2

Win32User/GDI

Environment Subsystems

1 3 2

ExecutiveDeviceDriversHardware Abstraction Layer (HAL)

Kernel

1

2

3


Cabeceras de imágenes

Subsistemas especificados en las cabeceras de lasimagenes .exe:IMAGE_SUBSYSTEM_UNKNOWN 0 Subsitema desconocidoIMAGE_SUBSYSTEM_NATIVE 1 No necesita imagenIMAGE_SUBSYSTEM_WINDOWS_GUI 2 Win32 sub.(app gráfica)IMAGE_SUBSYSTEM_WINDOWS_CUI 3 Win32 sub.(app caracter)IMAGE_SUBSYSTEM_OS2_CUI 5 Subsistema OS/2IMAGE_SUBSYSTEM_POSIX_CUI 7 Subsistema POSIX


Imágenes nativas

.EXE no enlazados contra ningún subsistemaInterfaz directa con el el Ejecutivo via NTDLL.DLL

Dos ejemplos:Smss.exe (Session Manager)Csrss.exe (Win32 subsystem)


Flujo de llamada a función Win32

Call WriteFile(…)

Call NtWriteFileReturn al llamador

Int 2EReturn al llamador

Call NtWriteFileRetorna interrupción

Realiza la operaciónReturn al llamador

Usuario

Kernel

Aplicación Win32

WriteFile en Kernel32.dll

NtWriteFile en NTDll.dll

KiSystemServiceen NtosKrnl.exe

NtWriteFile en NtosKrnl.exe

Específica Win32

Utilizada por todoslos subsistemas

Interrupción software

Call WriteFile(…)

Call NtWriteFileReturn to caller

Int 2EReturn to caller

Call NtWriteFileDismiss interrupt

Do the operationReturn to caller

WriteFile en Kernel32.dll


Windows XP: características

La distribución viene con:DirectX 8.0aCOM+ 1.5 MSMQ 3.0

Asistencia remotaCambio rápido entre usuarioCopias de seguridad y restauraciónNueva apariencia con Temas.Ejecución de DLLs lado-a-ladoVersión de 64-bits sobre Intel Itanium.


XP: mejoras del kernel (1)

Arranque más rápido del sistema – los manejadores de dispositivos y de serie se inicializan en paralelo.Logon más rápido – la ventana de dialogo aparece antes.Llamadas al sistema más rápidas – SustituyeINT0x2E por las instrucciones SYSENT/SYSEXITdel Pentium II o superior.Verificador de manejadores mejorado.



Espacio de sistema y manejadores de dispositivos:Manejadores: 220MB(2000), 960MB(XP)Sistema virtual del sistema: 660MB(2000), 1.3GB(XP)

Cerrojos de espera ocupada encolados – permiten una acquisición más rápida de los cerrojos.Rollback de manejadores y protección – salva los antiguos manejadores y los reinstala si es necesario.



Tamaño ilimitado de archivos proyectados en memoria –antes estaba limitado a 200GB.Tamaño ilimitado del Registro – ahora se utilizan archivos proyectados en memoria en lugar de depósito de páginas.El recorte de Conjunto Activo (de Trabajo) se realiza con el algoritmo LRU incluso en multiprocesadores.Depuración

Se permite la depuración del kernel vía FirewireEl depurador puede desligarse del proceso sin matarlo.


Hurd es un SO multiservidor compatible POSIX que se ejecurta sobre Mach.Proyecto para disponer de un SO libre desarrollado integramente por GNU para sustituir a Unix:

http://hurd.gnu.orgEsta basado en el microkernel de Mach .Si bien se esta trabajando en su construcción sobre L4(www.nongnu.org/l4hurd/).Debian GNU/Hurd – versión binaria de Hurd más fácil de instalar ( www.debian.org/ports/hurd).


HURD: arquitectura

Hardware

OSKit

Manejadordispositivos

Manejadordispositivos

GNUMach

MensajesMMU

Hebras de tareas

GlibCServidores Hurd

…

Autentificación

Red

Aplicación POSIXAplicación


Servidores Hurd

La funcionalidad suministrada por Hurd corre a cabo de un conjunto de servidores:

Cada servidor ejecuta una labor concreta.Una función realizada por varios servidores.Podemos sustituir los servidores dinámicamente – un usuario “normal” puede instalar y construir sus propios servidores (existen algunas bibliotecas de apoyo)Ejemplos: auth, exec, ext2fs, fifo, mouse, proc, streamio, symlink, term, tmpfs, ufs, usermux, …


OSKit

Es un marco y un conjunto de 34 bibliotecas de componentes orientadas a la construcción de SO.OSKit permite más fácilmente crear un SO, transportar un SO a un x86, o mejorar el soporte de un SO para un amplio rango de dispositivos, sistemas de archivos, formatos ejecutables, y servicios de red.http://www.cs.utah.edu/flux/oskit/


Mach

Suministra las abstracciones:

Tarea y hebraPuerto o grupo de puertosMensajeObjeto memoria Aplicación

Servidor Unixmultihebrado

Hebras dedispositivos

Paginadorinodos

Hebras de servicio

fdarchivo

Biblioteca deemulación

Falta depágina

Manejador de faltade página

Redirecciónllamada al sistema

Mach


Trabajos actuales

Después de los microkernels han surgido los sistemas exokernels, nanokernels, …Sistemas operativos orientados a componentes.Sistemas operativos orientados a aspectos.

La semana próxima comenzaremos el tema de Sistemas Operativos Distribuidos …

Documents

Arquitectura de Sistemas Operativos