Tema 3: Estructura Y Servicios Del Sistema Operativo

Transcription

Sistemas operativosTema 3: Estructura del sistemaoperativo1

Contenidos Componentes típicos del SOServicios del SOLlamadas al sistemaProgramas del sistemaEl núcleo o kernelModelos de diseño del SOCómo se implementa un SO2

Componentes típicos de un hivosIntérprete de órdenes3

Gestión de procesos procesosUn proceso es un programa en ejecución. Parapoder ejecutarse, un proceso necesita tiempo deCPU, una porción de memoria, archivos, E/S ydemás recursos.Responsabilidades del S.O.: creación y eliminación de procesosplanificación de procesos: repartir la CPU entre los procesosactivossincronización entre procesoscomunicación entre procesos4

Gestión de memoria memoriaLa memoria es un recurso escaso por el quecompiten los distintos procesos.Responsabilidades del S.O.: conocer qué zonas de memoria están libres y cuáles estánocupadasdecidir qué procesos hay que cargar cuando haya memorialibrereservar y liberar zonas de memoria según se solicitememoria virtual: utilizar el almacenamiento secundario comouna extensión de la memoria principal.5

Gestión de la E/S entrada/salidaLa E/S es un conjunto de dispositivos muy variadosy complejos de programar.Objetivos del S.O.: proporcionar una interfaz uniforme para el acceso a losdispositivos (independencia del dispositivo)proporcionar manejadores para los dispositivosconcretostratar automáticamente los errores más típicospara los dispositivos de almacenamiento, utilizar cachéspara los discos, planificar de forma óptima las peticiones6

Sistema de archivos archivosUn archivo es un conjunto de datos identificadopor un nombre. Los archivos se almacenan endispositivos de E/S. Un archivo es un conceptode alto nivel que no existe en el hardware.Funciones del S.O.: manipulación de archivos: crear, borrar, leer, escribir.manipulación de directoriosubicar los archivos y directorios en los dispositivos dealmacenamiento secundarioautomatizar ciertos servicios: copia de seguridad,versiones, etc.7

Sistema de protección protecciónLa protección abarca los mecanismos destinados acontrolar el acceso de los usuarios a los recursos,de acuerdo con los privilegios que se definan.Objetivos del S.O.: definir el esquema general de protección: clases de usuarios,clases de permisos/privilegios, etc.definir mecanismos de acceso a los recursos: contraseñas,llaves, capacidades, etc.controlar el acceso a los recursos, denegando el accesocuando no esté permitido8

Redes redesEn un sistema distribuido, existen variosordenadores con sus propios recursoslocales (memoria, archivos, etc.),conectados mediante una red.Objetivos del S.O.: proporcionar primitivas para conectarse con equiposremotos y acceder de forma controlada a susrecursos: primitivas de comunicación (enviar yrecibir datos) sistema de ficheros en red (ej. NFS)llamada remota a procedimiento (RPC) etc.9

Intérprete de órdenes(command interpreter) Para que un usuario pueda dialogar directamentecon el S.O., se proporciona una interfaz de usuariobásica para: Intérprete deórdenescargar programasabortar programasintroducir datos a los programastrabajar con archivostrabajar con redesEjemplos: JCL en sistemas por lotes,COMMAND.COM en MS-DOS, shell en UNIX10

Servicios del SO El S.O. ofrece a los programas una serie deservicios para trabajar en el computador: Ejecución de programasOperaciones de E/SManipulación de archivos y directoriosComunicación entre procesosComunicación con equipos remotosAdministración de la protección y seguridadLeer el estado del sistema (hora, nº de procesos, etc.)11

Servicios adicionales Aparte de los servicios básicos, el S.O.puede ofrecer algunas funciones paraoptimizar el uso del sistema:Compartición de recursosContabilidad (accounting) - conocer elconsumo de recursos12

Interfaces conlos servicios del SO Para el programador: LLAMADAS AL SISTEMA en lenguaje máquina oen alto nivel (ej. lenguaje C)Para el usuario: intérprete de órdenesprogramas del sistema13

¿Qué aspecto tiene una llamada alsistema? Windows: UNIX: handle OpenFile(“mifichero”,ofstruct,OF READ)fd open(“mifichero”,O RDONLY);MSDOS: 14

Llamadas al sistema El S.O. ofrece una gama de servicios a losprogramas.Los programas acceden a estos servicios mediantellamadas al sistema.Las llamadas al sistema son la interfaz entre elprograma en ejecución y el S.O.Es la única forma en la que un programa puedesolicitar operaciones al S.O.15

Implementación de las llamadas alsistema ¿Cómo se implementa la llamada? Habitualmente, mediante una instrucción especialde la máquina (syscall, int, trap.)La instrucción cambia automáticamente a modoprivilegiadoSi programamos en un lenguaje de alto nivel,escribimos la llamada al sistema como unasubrutina, y el compilador la sustituye por lainstrucción de máquina correspondiente.16

Implementación de las llamadas alsistema (2) Muchas llamadas necesitan parámetros,¿cómo los pasamos al S.O.? guardándolos en registros de la máquina (muytípico)en una tabla en memoria principalponiéndolos en la pila17

Ejemplo:llamadas al sistema de Unix Procesos: crear proceso (fork), enviar señal aun proceso (kill), tratar señales (signal) Memoria: pedir más memoria, liberarmemoria.Archivos: open, close, creat, read, write, mkdir;bloquear fichero (lockf) Redes: crear conexión (socket), cerrarconexión.Protección: cambiar permisos (chmod),cambiar propietario (chown) 18

Programas del sistema Las llamadas al sistema nos proporcionan unainterfaz para el programador. Un usuario finalinteractúa con el S.O. mediante programaspreviamente compilados.El entorno del S.O. Suele proveer utilidadesbásicas, llamadas programas del sistema, para: manipular ficheros (ej. ls, cp, etc.)editar documentos (emacs, edit, etc.)darnos un entorno de trabajo (ej. escritorio Windows)desarrollar programas (compiladores, enlazadores, etc.)comunicarnos con otros equipos (telnet, ftp, etc.)19

El núcleo (kernel) Se suele llamar núcleo (kernel) al softwaredel sistema operativo que residepermanentemente en memoria y que atiendelas llamadas al sistema y demás eventosbásicos.El núcleo se distingue de los programas delsistema (que utilizan los servicios delnúcleo).20

Modelos de diseño de un SO ¿Cómo está construido por dentro unsistema operativo?Hay múltiples técnicas: Diseño monolíticoDiseño en capasmáquinas virtualesModelo cliente-servidorMicronúcleos 21

Diseño monolítico La arquitectura más simple para un S.O. Es unnúcleo compacto, que contiene todas las rutinas deS.O.programaprogramaprogramaLlamadas al sistemaNÚCLEOhardware22

Diseño por capas El S.O. se construye en niveles jerárquicos, cadauno de los cuales aprovecha los servicios del nivelinferior.Diseño más modular y escalable que el monolítico.programacapa 2capa 1capa 023

Diseño por capas (2) Cada capa del SO consistiría en la implementaciónde un objeto abstracto DatosOperacionesoperacionesnuevascapa M.operacionesocultasoperacionesexistentescapa M-1.24

Ejemplo por capas: THE Sistema experimental de los años 60Seis niveles: L5: aplicaciones de usuarioL4: bufferingL3: consola del operadorL2: gestión de memoria paginadaL1: planificación de procesosL0: hardware25

Ejemplo: MS-DOS (Microsoft)programa de aplicaciónprograma del sistema residentecontroladores de dispositivosde MS-DOScontroladores de dispositivos en ROM BIOS26

Ejemplo: Unix (AT&T)(usuarios)shells y órdenescompiladores e intérpretesbibliotecas del sistemaInterfaz con el núcleo mediante llamadas al sistemamanejo de terminales porseñalessistema de E/S por caracteresdrivers de terminalessistema de archivossistema de E/S por intercambiode bloquesdrivers de disco y cintaplanificación de CPUreemplazo de páginaspaginación por demandamemoria virtualInterfaz con el núcleocontroladores de terminalesterminalescontroladores de dispositivosdiscos y cintascontroladores de memoriamemoria física27

Ejemplo: OS/2 nterfaz de programación de aplicaciones (API) extensión APIsubsistemasubsistemasubsistemanúcleo del sistema gestión de memoria planificación de tareas gestión de dispositivoscontroladorde dispositivocontroladorde dispositivocontroladorde dispositivocontroladorde dispositivo28

Diseño por capas: ventajas sobremonolítico La modularidad simplifica: Depuración y verificación Una vez depurada la primera capa se puede dar porsentado su funcionamiento correcto mientras se trabajacon la segunda capa.Mantenimiento Es posible por ejemplo cambiar las rutinas de bajo nivelsiempre que la interfaz externa de la rutina no cambie yla rutina realice la misma tarea anunciada29

Diseño por capas: desventajas sobremonolítico Problema: definición apropiada de las distintascapasTienden a ser menos eficientes Llamadas entre capas paso de parámetrosEn definitiva cada capa implica un gasto extraTendencia: equilibrio, menos capas con más funcionalidad: Ventajas de la modularidadEvitan los problemas de definición e interacción entre capas30

Máquinas virtuales La idea: mediante software, se proporciona a losprogramas la emulación de un sistema que nosinteresa reproducir.El sistema emulado puede ser una máquina, unsistema operativo, una red de computadores El software emulador traduce las peticiones hechas ala máquina virtual en operaciones sobre la máquinareal.Se pueden ejecutar varias máquinas virtuales almismo tiempo (ej. mediante tiempo compartido).Los recursos reales se reparten entre las distintasmáquinas virtuales.31

Máquinas virtuales: ejemplos IBM VM: ofrecía a cada usuario su propiamáquina virtual no multiprogramada; las m.v.se planificaban con tiempo compartido.Java: los programas compilados en Javacorren sobre una máquina virtual (JVM).VMware: capaz de ejecutar al mismo tiempovarias sesiones Windows, Linux, Mac OS X,etc. sobre plataforma PC o Mac.Nachos: S.O. que se ejecuta en una máquinavirtual MIPS, cuyo emulador corre sobre Unix.32

Máquinas virtuales: pros y contras Protección: cada máquina virtual está aisladade las otras y no puede interferirIndependencia de la plataforma (ej. Java)Pervivencia de sistemas antiguos (ej.emuladores MSDOS)Experimentación: se puede desarrollar yejecutar para un hardware que no tenemosPero el rendimiento de la m.v. puede sermuy lento33

Modelo cliente-servidor Según este modelo, el SO se organiza como unconjunto de módulos autónomos, cada uno de loscuales tiene a disposición del resto una serie deserviciosCada módulo actúa como un servidor de ciertasfuncionalidades, que atiende las peticiones de otrosmódulos y que su vez puede ser cliente de otrosmódulos34

Modelo cliente-servidor Podemos extender el modelo cliente-servidor hastael infinito, si consideramos cada módulo del sistemacomo un conjunto de módulos con relacionescliente-servidorEl modelo jerárquico no es más que un casoparticular del modelo cliente-servidorIndicado para sistemas distribuidos35

Micronúcleo Objetivo: construir un núcleo del SO con lomínimo imprescindible cambios de contexto, gestión de interrupciones,comunicación entre procesos, etc.Las políticas de gestión de los recursos seimplementan fuera del núcleo, comoprocesos externos a nivel de usuarioPrimer micronúcleo: Mach (1980)36

Micronúcleo (2)37

Micronúcleos: ventajas Se pueden incorporar nuevos módulos sinnecesidad de alterar el núcleoSe cargan en memoria sólo aquellos módulos quesean necesarios en cada momentoPueden aplicarse diferentes políticas para distintasclases de procesos (ej. unos por lotes, otros entiempo real )Puede servir como base de múltiples sistemasoperativos (estos se implementan como coleccionesde módulos cargables)Facilita la implementación de máquinas virtuales38

Micronúcleos: ventajas (2) Fiabilidad “Lo pequeño es bello” el micronúcleo es menos complejo y por tantomás fácil de depurarMuchos módulos se ejecutan como procesos deusuario si un servicio falla, el resto del SO puedeseguir adelante39

Implementación de un sistemaoperativo Como todo software, debe seguirse un proceso dedesarrollo (ingeniería de sw): requisitos, diseño, construcción, pruebas, paso aexplotación, mantenimiento Pero un SO presenta características especiales: Es un sistema crítico (todas las aplicaciones dependen deél)Normalmente hay requisitos más estrictos de portabilidad(respetar versiones anteriores)Es más complicado de depurar ¿cómo probamos unpequeño cambio? ¿tenemos que volverlo a instalar unequipo?40

Separar mecanismos y políticas Los mecanismos definen cómo se realiza algo; laspolíticas definen qué se debe realizar.Ejemplos: Tiempo compartido políticaTemporizador, colas de procesos, gestión de interrupciones mecanismosEs conveniente separar en el código losmecanismos de las políticas. Aunque la políticacambie, los mismos mecanismos pueden seguirsiendo útiles.41

Lenguaje para implementar un SO En el pasado, lenguaje ensamblador (poreficiencia).Hoy día se usan lenguajes de alto nivel, sobre todoC/C . Más legible y fácil de mantener y depurarMás transportable a distintas arquitecturas hardware42

Modelo cliente-servidor Según este modelo, el SO se organiza como un conjunto de módulos autónomos, cada uno de los cuales tiene a disposición del resto una serie de servicios Cada módulo actúa como un servidor de ciertas funcionalidades, que atiende las peticiones de otros módulos y que su vez puede ser cliente de otros módulos