Arquitectura de Sistemas Operativos

Arquitecturas de Sistemas Operativos
Investigacin en software de sistemas Extensibilidad en SOs: arquitectura Ejemplos de sistemas
Jos Antonio Gmez Hernndez, 2004-05
Introduccin
Esta muerta la investigacin sobre SOs? Motivos para la investigacin Cambios tecnolgicos Avances en software Problemas Repaso de arquitecturas de SOs: Arquitectura Monoltica Arquitectura Microkernel
acitmrofnI .gnI 5 - sOS ed oesiD
Esta desfasada la investigacin en software de sistemas? Rob Pike

Linux y Windows 2000 estn basados en un modelo de SO de los aos 60. El nfasis en la eficiencia esta falto de salud Existen nuevas visiones?
Estamos construyendo los sistemas correctos?

Where virtual reality puts people inside a computer-generated world, ubiquitous computing forces the computer to live out here in the world with people.
Mark Weiser
http://www.ubiq.com/hypertext/weiser/UbiHome.html
4
Cambios tecnolgicos
CPUs muy rpidas, grandes memorias, redes de banda ancha Movilidad, inalmbricas, pticas, fuentes de alimentacin/baterias, tamao Paralelismo, buses, compiladores Dispositivos de E/S, pantallas planas, sonido, video, voz Computacin Bio/Molecular/Cuntica/Optica Sistemas empotrados: nanotecnologa, exploracin espacial, vehculos, medicina
5
Avances en Sistemas Software

Porcupine Elephant 2K Globus Legion Paramecium Redes Activas Cellular DISCO Exokernel Spin Plan 9
Apertos Choices Globe Millenium Off+ Clouds JavaOS Spring OGI OMG CORBA
DCOM DCE Agentes mviles WWW RMI Cool Town Endeavor Oxygen
Classroom 2000 Easy Living Portolano Jini Kerberos Sesame
Problemas
Exokernel
Uso de un grupo de mquinas Gestin de grupos de mquinas MACH Escalabilidad Migracin de tareas y funciones Actualizacin de software Portabilidad Movilidad Seguridad
UNIX SPIN
Dependencias Visin de mundo centrada en la mquina Fiabilidad/robustez

7
Enfoque
Re-evaluar los modelos existentes de SOs Cuestionar suposiciones Visita guiada para el cambio Utilizar la imaginacin atemperada con una preocupacin prctica Mirar 10 aos hacia delante
Temas de Investigacin
Seguridad dinmica Sistemas distribuidos Muchos computadores por persona
! ! ! ! Encriptado / Capacidades Software Autentificacin / Certificados Deteccin de intrusiones Polticas dinmicas, redes activas
! Objeto Bus integra DCOM,OMG,RMi,Jini, .. ! Objetos distribuidos brokers, trader, ! Middleware, personalizacin, especializacin ! Fiabilidad (reliabilty)
! Radio, buses corporales, computadores chip, potencia ! Temas: Mantener el entorno en dispositivos personales; Proteccin, fiabilidad, seguridad ! Configuracin sencilla, control de versiones, mantenimiento de licencias, tiempo de vida de los datos ! Negociacin y colaboracin
Temas investigacin (2)

Centrados en la red Conscientes de la arquitectura Modelo de aplicacin
! La migracin de usuarios y aplicaciones es un problema de mantenimiento ! Asignacin de recursos a usuario en la red ! Igualar los recursos a las necesidades (QoS) ! Autoconfiguracin para evitar mantenimiento ! Lo que necesitas es lo que obtienes ! Reconfiguracin al vuelo, optimizacin ! Representar usuarios, recursos, y entornos como entidades de red no como entidades mquina. ! Las operaciones se realizan sobre entidades de red, no representaciones en mquinas.
01
Enfoque ( y ii)
Hacer las aplicaciones centradas en la red a travs de middelware personalizable y re-organizable. Aadir mecanismos de ligadura para identificar entidades de red.
11
En clase
Veremos la investigacin en SO de los ltimos aos. Examinaremos en impacto de nuevas ideas sobre futuros sistemas operativos Evaluaremos algunos ejemplos reales Buscaremos nuevas soluciones?
21
Objetivos del SO
Conveniencia: Debe facilitar la labor de programacin de aplicaciones Abstraccin: Esconder los detalles del hardware Presentar una interfaz uniforme para diferentes dispositivos Generalidad Cambiar en las caractersticas de una aplicacin no debe suponer su rediseo Extensibilidad: Debe permitir el desarrollo, prueba e introduccin de nueva funcionalidad sin interferir el servicio actual.
31
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 rpido Robustez: No averas del sistema debidas a aplicaciones maliciosas o errneas Proteccin: Debe suministrar imparcialidad, y seguridad
41
Arquitectura
Instead of getting serious about Linux, get serious about architecture Its not about the component technology and not about the processor or the operating system. Its about architecture that delivers the benefits and the technology that enables the architecture Michael Tiemann
CTO of Red Hat
51
Por qu necesitamos arquitectura de sistemas?
61
Por qu la necesitamos (y ii)?

Para disear sistemas tiles y extensibles Para establecer propiedades no funcionales, por ejemplo, Calidad de Servicio (QoS) Para implementar sistemas seguros, correctos y robustos.
71
Estructura del sistema

Sistema software = Conjunto de componentes y sus interconexiones con varias dependencias.
!Componentes
Interconexiones ! Varan en funcionalidad y rendimiento
81
Componentes
Aplicacin: por ejemplo, simulacin de trfico, prediccin meteorolgica, edicin de textos, etc. Subsistemas con tareas especficas: Control ejemplo, shell Proteccin ej. Firewall Contabilidad ej. Vigilancia Servicio ej. Servidor de archivos Soporte ej. Manejador de disco Funciones bsicas: ej. sincronizacin
91
Interdependencias entre componentes

Llamada: main() invoca a printf() Serializacin: hebra1 despus de hebra2 Comunicacin: mensaje de emisor a receptor Maestro/esclavo: shell invoca a una aplicacin Pares: productor y consumidor Cliente/servidor: aplicacin utiliza un servidor de archivos .
02
Estructura de sistemas
Cmo implementamos un componentes? Podemos imponer alguna ordenacin dentro de la estructura del sistema?
Capa 1 Capa 2
Capa 3
Manejador de disco
Main o Procedimiento Mdulo o TAD Objeto o clase Proceso o hebras
12
Enfoques para manejar la complejidad

Enfoques monolticos: Kernels de capas Kernels modulares Kernels orientados a objetos Alternativas; Kernels extensibles Microkernels
22
Arquitectura monoltica
Aplicacin
Llamada al sistema
Aplicacin SO Modo privilegiado
Planificador Sistema de archivos Manejador de dispositivo Hardware Protocolos Manejador de dispositivo
La mayora de servicios dentro del kernel (modo privilegiado) Proteccin del kernel frente a las aplicaciones, y las aplicaciones entre si. Componentes del kernel no protegidos Las aplicaciones deben confiar en el kernel.
32
Arquitectura microkernel
Aplicacin Sistema de archivos Manejador de dispositivo -kernel Aplicacin Protocolos Manejador de dispositivo Modo privilegiado
Despachador + IPC bsico Hardware
Las caractersticas a continuacin

42
Pros y contras del -kernel

Ventajas: Ms fcil de probar, verificar y modificar. Mejora la seguridad y robustez Mejora el mantenimiento Coexistencia de varias APIs Extensibilidad Inconvenientes: Esfuerzo de descomposicin Menor rendimiento Sobrecarga de comunicaciones
52
El gran argumento contra los sistemas microkernels

Mal rendimiento Son grandes e inflexibles
! IBM WorkPlace OS: 2.000.000.000 $US ! Win NT: 8 aos, 1000 personas
Comentario: Esto es verdadero para la primera generacin de sistemas, como son: Mach (CMU, OSF) Chorus (INRIA, Sun) Amoeba (Vrije Universiteit) L3 (GMD)
62
72
El desastre de los 100 sec
Costes arquitectnicos - monoltico

Aplicacin
write_file(nombre, reg)
Sistema de archivos
get_disk_block()
Manejador de disco
1 llamada al sistema (incluido la entrada y salida del modo kernel) 1 llamada al procedimiento (call + return)
Hardware Ambos mdulos pueden compartir datos
82
Coste arquitectnico -kernel

x4
Aplicacin
write_file(nombre, reg)
Manejador de disco Sistema de archivos
1. 1 llamada al servidor de archivos:

! ! !
Entrar/salir al/del k Transferir mensaje Cambiar de espacio de direcciones
get_disk_block()
2. 1 llamada al manejador * 3. Rplica al servidor * 4. Rplica a la aplicaciones*

* Cada paso tiene el coste del 1.
Hardware
92
Ventajas de arq. monoltica

El kernel tiene acceso a todo, potencialmente: Todas las optimizaciones son posibles Podemos implementar todas las tcnicas, mecanismos, y conceptos. Podemos extenderlo bien: aadiendo ms cdigo al kernel. mdulos
P. ej. Linux 2.4.18 tiene 2.7 millones de lneas de cdigo
03
Modulos de carga dinmica

Estos permiten aadir nueva funcionalidad al sistema en tiempo de ejecucin. Limitaciones: No podemos afectar a la funcionalidad compilada estticamente. No es fcil confinar un error dentro del mdulo donde se produce. Si bien hay intentos (tcnicas Software Fault Isolation) esto no son lo suficientemente eficientes.
13
Por qu nuevas alternativas?

Existen muchos tipos de sistemas (comparable a los tipos de coches), con Algunos requisitos comunes (ej. cuatro ruedas) Con requisitos especficos (ej. coches con ABS) No todos los sistemas deben que ser iguales! Utilizaras este piloto y este coche para transportar pescado fresco desde Motril a Granada?
23
Conclusin
No existe un nico sistema que sea ideal para todos los propsitos. Necesitamos sistemas que se puedan adaptar de diferentes formas. Necesitamos sistemas extensibles!.
33
Cmo 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 generacin de -kernel. El ejemplo ms avanzado es L4. Actualmente sigue sin resolverse el problema ms general: cmo organizamos todos los servicios del SO en modo usuario?
43
Sistema Monoltico: Linux

Arquitectura general del sistema Extensiones al sistema
63
Arquitectura de Linux
Arquitectura concreta
La arquitectura concreta hace referencia a como esta construido el sistema. Sirve como especificacin para que los desarrolladores extiendan o modifiquen el cdigo fuente actual.
73
83
Componente: Planificador
93
Componente: Memoria
04
Componente: Sistema de archivos
14
Componente: IPC
24
Componente: Subsistema de Red
Extensiones
Dos forma: Extendiendo del cdigo: los desarrolladores implementan, modifican la funcionalidad del kernel modificando, aadiendo, nuevo cdigo. Problemas: el tamao del cdigo y sus dependencias. Ver siguiente transparencia. Mdulos de carga dinmica podemos enlazar un mdulo en tiempo de ejecucin junto con el resto del cdigo del kernel.
34
Navegacin por el cdigo:

http://plg.uwaterloo.ca/~itbowman/pbs/
44
Mdulos
El planificador de procesos tambin suministra soporte para la carga dinmica de mdulos (cada mdulo representa funcionalidad kernel que puede ser cargada despus de que el kernel inicie su ejecucin). Esta funcionalidad se utiliza para: Implementar manejadores de dispositivos, La abstraccin de interfaces que utilizan el sistema virtual de archivos y la interfaz de red, .. Para aadir nuestra propia funcionalidad
54
Un ejemplo de mdulo
Un versin 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.o Hola, Mundo % rmmod hola Adios mundo cruel %
64
74
Enlazado de un mdulo
Limitaciones de los mdulos

Existe cdigo que debe enlazarse estticamente. Esto ocurre cuando debemos modificar estructuras de datos o funciones enlazadas estticamente. Ejemplos: Necesitamos un campo ms en el descriptor de proceso. No podemos enlazar dinmicamente un mdulo que cambie el algoritmo de asignacin de marcos de pginas, o el algoritmo de paginacin.
84
Anlisis final
Rendimiento: bueno Debemos prestar atencin al IPC en ejecucin. 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.
94
Sistema Microkernel: Windows 2000/XP

Arquitectura general del sistema Extensiones al sistema
Introduccin
En la primera parte del tema hemos visto la estructura general de un sistema microkernel, ahora describiremos dos implementacin concretas: Windows 2000, XP, etc. veremos la arquitectura interna y el funcionamiento de los componentes de ncleo, y el papel de los subsistemas y su funcionamiento. Hurd veremos su estructura interna.
15
Windows 2000: arquitectura

Session Mgr WinLogon Replicator Alerter Event Log Win32 POSIX OS/2
System Processes
Services
Interface DLL
User Apps
Subsystem DLL
Environment Subsystems
User Kernel Executive Services API

I/O System File Systems Security Monitor Device Drivers DMA/Bus Control Cache Control Clocks/ Timers Win32 GDI Object Services Memory Mgmt Processes/ Threads Exec. RTL
Object Management
Kernel
Hardware Abstraction Layer (HAL)

I/O Devices Privileged Architecture Interrupt Dispatch
Registry
25
Componentes de la arquitectura (i)

Ejecutivo de Windows 2000: Suministra las funciones genricas del SO de alto nivel: Crear y destruir procesos y hebras Gestin de memoria Entradas/salidas IPC Seguridad Se ejecuta en modo kernel Su API no esta documentada (Funciones Nt_) se accede indirectamente a travs de las APIs de los subsistemas.
35
Componentes de la arquitectura (ii)

El kernel de Windows 2000 suministra las funciones de bajo nivel del SO: Planificacin Despacho de interrupciones y excepciones. Sincronizacin en multiprocesadores. HAL (Capa de Abstraccin Hardware): Asla 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.
45
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 protocolos de red, manejadores de dispositivos hardware. Los manejadores pueden invocar a las funciones HAL para acceder al hardware Win32 User/GDI (Interfaz Grfica de Dispositivos) Implementa la interfaz grafica de usuario (GUI) Manipulacin de ventanas, controles de la interfaz de usuario Dibujo
55
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 estn ligados a un nico subsistema. Las aplicaciones de usuario no invocan directamente los servicios de Windows lo hacen va subsistemas DLL.
65
Componentes del subsistema de entorno

1 API DLLs Para Win32: Kernel32.DLL, Gdi32.DLL, User32.DLL 2 Proceso subsistema: Para Win32: CSRSS.EXE 3 Cdigo GDI modo Kernel (solo Win32)
System & Service Processes
User Apps
Subsystem DLL
2
OS/2 Win32
POSIX
User Kernel
Executive
Device Kernel Drivers Hardware Abstraction Layer (HAL)
Win32 User/GDI
75
Papel de los componentes de subsistema

API DLLs Exporta las APIs definidas por el subsistema Las implementa llamando a los servicios nativos, o solicitando al proceso de subsistema que realice el trabajo. Mantienen el estado global del subsistema. Win32K.SYS Implementa las funciones Win32 User/GDI Utilizada tambin por los subsistemas POSIX y OS/2 para acceder a la pantalla.
85
Subsistema Win32
Implementado en el proceso CSRSS.EXE (subsistema cliente/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/ratn, salida pantalla, .. Interfaz de Dispositivo Grfico (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
95
Subsistema POSIX
Portable Operating System Interface based on Unix Incluido para satisfacer los requistos del Gobierno de EEUU. Windows 2000 implementa POSIX 1003.1 Suministra un conjunto limitado de servicios: No se pueden crear hebras, ventanas o utilizar sockets. Los ejecutables se enlazan con la biblioteca del subsistema POSIX (Psxdll.dll) Las bibliotecas comerciales Unix-a-Win32 son una mejor solucin para portar aplicaciones.
06
Invocacin de un subsistema
System & Service Processes
User Apps
Subsystem DLL
OS/2
Win32
POSIX
1
User Kernel
NtDll.dll
Executive
Device Kernel Drivers Hardware Abstraction Layer (HAL)
Win32 User/GDI
1 2 3
La mayora de APIs kernel Win32 La mayora de APis Win32 User/GDI Unas pocas APIs Win32
16
Cabeceras de imgenes
Subsistemas especificados en las cabeceras de las imagenes .exe:
IMAGE_SUBSYSTEM_UNKNOWN IMAGE_SUBSYSTEM_NATIVE IMAGE_SUBSYSTEM_WINDOWS_GUI IMAGE_SUBSYSTEM_WINDOWS_CUI IMAGE_SUBSYSTEM_OS2_CUI IMAGE_SUBSYSTEM_POSIX_CUI 0 1 2 3 5 7 Subsitema desconocido No necesita imagen Win32 sub.(app grfica) Win32 sub.(app caracter) Subsistema OS/2 Subsistema POSIX
26
Imgenes nativas
.EXE no enlazados contra ningn subsistema Interfaz directa con el el Ejecutivo via NTDLL.DLL Dos ejemplos: Smss.exe (Session Manager) Csrss.exe (Win32 subsystem)
36
Flujo de llamada a funcin Win32

Aplicacin Win32
Call WriteFile() Call NtWriteFile Return alto caller Return llamador Int 2E Return alto caller Return llamador
WriteFile en Kernel32.dll NtWriteFile en NTDll.dll Interrupcin software KiSystemService en NtosKrnl.exe
Especfica Win32
Utilizada por todos los subsistemas
Usuario Kernel
Call NtWriteFile Retorna interrupcin Dismiss interrupt Realiza la operacin Do the operation Return alto caller Return llamador
NtWriteFile en NtosKrnl.exe
46
Windows XP: caractersticas

La distribucin viene con: DirectX 8.0a COM+ 1.5 MSMQ 3.0 Asistencia remota Cambio rpido entre usuario Copias de seguridad y restauracin Nueva apariencia con Temas. Ejecucin de DLLs lado-a-lado Versin de 64-bits sobre Intel Itanium.
56
XP: mejoras del kernel (1)

Arranque ms rpido del sistema los manejadores de dispositivos y de serie se inicializan en paralelo. Logon ms rpido la ventana de dialogo aparece antes. Llamadas al sistema ms rpidas Sustituye INT0x2E por las instrucciones SYSENT/SYSEXIT del Pentium II o superior. Verificador de manejadores mejorado.
66

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 acquisicin ms rpida de los cerrojos. Rollback de manejadores y proteccin salva los antiguos manejadores y los reinstala si es necesario.
76

Tamao ilimitado de archivos proyectados en memoria antes estaba limitado a 200GB. Tamao ilimitado del Registro ahora se utilizan archivos proyectados en memoria en lugar de depsito de pginas. El recorte de Conjunto Activo (de Trabajo) se realiza con el algoritmo LRU incluso en multiprocesadores. Depuracin Se permite la depuracin del kernel va Firewire El depurador puede desligarse del proceso sin matarlo.
86
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.org Esta basado en el microkernel de Mach .Si bien se esta trabajando en su construccin sobre L4 (www.nongnu.org/l4hurd/). Debian GNU/Hurd versin binaria de Hurd ms fcil de instalar ( www.debian.org/ports/hurd).
96
HURD: arquitectura
Aplicacin Servidores Hurd
Autentificacin Red
Aplicacin POSIX GlibC
GNUMach Hebras de tareas MMU Mensajes OSKit Manejador dispositivos Hardware Manejador dispositivos
07
Servidores Hurd
La funcionalidad suministrada por Hurd corre a cabo de un conjunto de servidores: Cada servidor ejecuta una labor concreta. Una funcin realizada por varios servidores. Podemos sustituir los servidores dinmicamente 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,
17
OSKit
Es un marco y un conjunto de 34 bibliotecas de componentes orientadas a la construccin de SO. OSKit permite ms fcilmente 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/
27
Mach
Suministra las abstracciones: Tarea y hebra Puerto o grupo de puertos Mensaje Objeto memoria
Biblioteca de emulacin archivo fd Hebras de dispositivos Paginador inodos Servidor Unix multihebrado Hebras de servicio
Aplicacin
Falta de Redireccin Manejador de falta pgina llamada al sistema de pgina Mach

37
Trabajos actuales
Despus de los microkernels han surgido los sistemas exokernels, nanokernels, Sistemas operativos orientados a componentes. Sistemas operativos orientados a aspectos.
La semana prxima comenzaremos el tema de Sistemas Operativos Distribuidos
47

Arquitectura de Sistemas Operativos

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Arquitectura de Sistemas Operativos

Uploaded by

Copyright:

Available Formats

Arquitecturas de Sistemas Operativos

Investigacin en software de sistemas Extensibilidad en SOs: arquitectura Ejemplos de sistemas

Jos Antonio Gmez Hernndez, 2004-05

acitmrofnI .gnI 5 - sOS ed oesiD

Esta desfasada la investigacin en software de sistemas? Rob Pike

acitmrofnI .gnI 5 - sOS ed oesiD

Estamos construyendo los sistemas correctos?

acitmrofnI .gnI 5 - sOS ed oesiD

acitmrofnI .gnI 5 - sOS ed oesiD

Avances en Sistemas Software

Classroom 2000 Easy Living Portolano Jini Kerberos Sesame

Dependencias Visin de mundo centrada en la mquina Fiabilidad/robustez

acitmrofnI .gnI 5 - sOS ed oesiD

Temas investigacin (2)

acitmrofnI .gnI 5 - sOS ed oesiD

acitmrofnI .gnI 5 - sOS ed oesiD

acitmrofnI .gnI 5 - sOS ed oesiD

acitmrofnI .gnI 5 - sOS ed oesiD

acitmrofnI .gnI 5 - sOS ed oesiD

Por qu necesitamos arquitectura de sistemas?

acitmrofnI .gnI 5 - sOS ed oesiD

Por qu la necesitamos (y ii)?

acitmrofnI .gnI 5 - sOS ed oesiD

Estructura del sistema

Interconexiones ! Varan en funcionalidad y rendimiento

acitmrofnI .gnI 5 - sOS ed oesiD

acitmrofnI .gnI 5 - sOS ed oesiD

Interdependencias entre componentes

acitmrofnI .gnI 5 - sOS ed oesiD

Main o Procedimiento Mdulo o TAD Objeto o clase Proceso o hebras

acitmrofnI .gnI 5 - sOS ed oesiD

Enfoques para manejar la complejidad

acitmrofnI .gnI 5 - sOS ed oesiD

Aplicacin SO Modo privilegiado

Planificador Sistema de archivos Manejador de dispositivo Hardware Protocolos Manejador de dispositivo

acitmrofnI .gnI 5 - sOS ed oesiD

Despachador + IPC bsico Hardware

Las caractersticas a continuacin

acitmrofnI .gnI 5 - sOS ed oesiD

Pros y contras del -kernel

acitmrofnI .gnI 5 - sOS ed oesiD

El gran argumento contra los sistemas microkernels

acitmrofnI .gnI 5 - sOS ed oesiD

acitmrofnI .gnI 5 - sOS ed oesiD

El desastre de los 100 sec

Costes arquitectnicos - monoltico

Hardware Ambos mdulos pueden compartir datos

acitmrofnI .gnI 5 - sOS ed oesiD

Coste arquitectnico -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. Rplica al servidor * 4. Rplica a la aplicaciones*

acitmrofnI .gnI 5 - sOS ed oesiD

Ventajas de arq. monoltica

P. ej. Linux 2.4.18 tiene 2.7 millones de lneas de cdigo

Modulos de carga dinmica

Por qu nuevas alternativas?

acitmrofnI .gnI 5 - sOS ed oesiD

acitmrofnI .gnI 5 - sOS ed oesiD

Cmo solventar los problemas de las arquitecturas -kernel?

acitmrofnI .gnI 5 - sOS ed oesiD

Sistema Monoltico: Linux

acitmrofnI .gnI 5 - sOS ed oesiD

acitmrofnI .gnI 5 - sOS ed oesiD