DSO-1: Introducción al diseño de un sistema operativo (v3b)

Lección 1Introducción

Diseño de Sistemas Operativos

Grado en Ingeniería Informática

Grupo ARCOSUniversidad Carlos III de Madrid

Alejandro Calderón Mateos

Lecturas recomendadas

ARCOS @ UC3M2

1. Carretero 2007:

1. Cap. 2

1. Tanenbaum 2006:

1. Cap.1

2. Stallings 2005:

1. Parte uno. Transfondo.

3. Silberschatz 2006:

1. Cap.1

Base Recomendada


A recordar…

ARCOS @ UC3M3

1. Estudiar la teoría asociada.� Estudiar el material asociado a la bibliografía:

las transparencias solo no son suficiente.

� Crear cuestiones con sus respuestas y justificación.

2. Repasar lo visto en clase.� Realizar el cuaderno de prácticas progresivamente.

3. Ejercitar las competencias.� Realizar las prácticas progresivamente.

� Realizar todos los ejercicios posibles.


Contenidos

ARCOS @ UC3M4

1. Qué es un sistema operativo.

1. Definiciones, principales funciones y características

2. Cómo es por dentro.

1. Principales objetivos, estructura y ejecución asíncrona

3. Cómo es por fuera.

1. Núcleo y módulos


Contenidos

ARCOS @ UC3M5








Definición de sistema operativo

ARCOS @ UC3M6

� Sistema operativo: software destinado a permitir la comunicación del usuario con un ordenador y gestionar sus recursos de manera cómoda y eficiente.

Hardware

Sistema Operativo

usuario


Definición de sistema operativo

ARCOS @ UC3M7

� Sistema operativo: software destinado a permitir la comunicación del usuario con un ordenador y gestionar sus recursos de manera cómoda y eficiente.

Hardware

Sistema Operativo

Software de sistema

Software de aplicaciónusuario


Contenidos

ARCOS @ UC3M8








Funciones del sistema operativo

ARCOS @ UC3M9

� Interfaz del usuario.

� Gestor de recursos:

� CPU, memoria, etc.

� Máquina extendida:

� Servicios, interfaz del programador, etc.

Hardware

Usuario

Sistema operativo



ARCOS @ UC3M10






Hardware

Usuario

Sistema operativo


Abstracciones fundamentalesProcesos

ARCOS @ UC3M11

� Procesos, tabla de procesos, árbol de procesos

� Imagen básica, planificación, señales

� Identificación de usuario y grupo

� Intérprete de mandatos (shell)

https://www.microsoft.com/resources/sharedsource/windowsacademic/curriculumresourcekit.mspx

preparado funcionando

bloqueado

finalizadonuevo

A

B C

FED

Árbol de procesos


Abstracciones fundamentalesArchivos

ARCOS @ UC3M12

� Archivos y directorios

� Ruta, directorio de trabajo y raíz

� Protección

� Descriptor de archivo

� Archivos especiales:

� Dispositivos E/S

� E/S de bloque y de caracteres

� Pipes

� Estándares entrada/salida/error


Directorio raíz

tmp usretc

pitmia



ARCOS @ UC3M13






Hardware

Usuario

Sistema operativo


Áreas de gestión

ARCOS @ UC3M14

� Gestión de Procesamiento

� Planificación

� Prioridades, multiusuario

� Gestión de Memoria y Almacenamiento

� Reparto de memoria entre procesos, con protección y compartición

� Persistencia y etiquetación (ej. Sistema de Archivos) con una visión lógica unificada para usuarios y programas que sea independiente del medio físico

� Gestión de Dispositivos

� Encubriendo las dependencias de hardware

� Gestión de accesos concurrentes



ARCOS @ UC3M15






Hardware

Usuario

Sistema operativo


Interfaz del usuario

ARCOS @ UC3M16

� Interfaz del programador:

� Mediante llamadas al sistema.

� Interfaz de usuario:

� Mediante línea de mandatos o CLI

� Interfaz gráfica o GUI

ret = close (filedesc) ;

http://www.guidebookgallery.org/screenshots/commandprompthttp://www.guidebookgallery.org/screenshots/full


Funciones del sistema operativoresumen

ARCOS @ UC3M17






Hardware

Usuario

Sistema operativo


Un detalle más sobre máquina extendida…

ARCOS @ UC3M18






Hardware

Usuario

Sistema operativo


Máquinas virtuales

ARCOS @ UC3M19

� El sistema operativo virtualiza ciertos elementos del hardware; ¿Por qué no virtualizar todo?

� IBM ha usado esta idea en sus mainframes desde principio de la década de los 70.

� Un hipervisor virtualiza todo el ordenador, de manera que permite que múltiples sistemas operativos (o copias del mismo) ejecuten a la vez.

� La virtualización:

� [I] supone cierta sobrecarga

� [V] ofrece un aislamiento excelente entre sistemas y la flexibilidad en la reserva de recursos lo quemejora el coste, especialmente en «granjas»

http://www-128.ibm.com/developerworks/library/l-linuxvirt/index.html

Hardware

Hipervisor (VMM)

S.O. S.O.

Apl. Apl.

… Mgmt


Máquinas virtuales

ARCOS @ UC3M20 http://www-128.ibm.com/developerworks/library/l-linuxvirt/index.html

Distinto HardwareHW. emulation

Mismo Hardware y…


Máquinas virtuales


Distinto Hardware

… mismo S.O. Containers

HW. emulation

… distinto S.O. y…

Mismo Hardware y…


Máquinas virtuales


Distinto Hardware

… mismo S.O.

… no colaborancon el hipervisor

Containers

Para-virtualization

Full virtualization

HW. emulation

… distinto S.O. y…

… colaborancon el hipervisorMismo Hardware y…


Contenidos

ARCOS @ UC3M23








Principales características

ARCOS @ UC3M24

� Versátil

� Portabilidad

� Adaptativo

� Multidisciplinar

� Complejo

� Delicado


Versatilidad

ARCOS @ UC3M25

MainframeOS/360, z/OS, …

Miniordenadores y PCUnix, MacOs, Windows, …

EmpotradosVxWorks, QNX, LynxOS,

Android, iOS, Windows Embedded, …

SupercomputadorUnix, Linux, …


� Mismo equipo, diferentes SSOO: IBM PC

� Mismo SO, diferentes equipos: Unix

Principales características:

1) Versátil

ARCOS @ UC3M26

IBM PC

DR-DOSLinux

IBM PC

Unix

CRAY-Y/MP

…

…

Portabilidad



2) Continuos cambios para adaptarse

ARCOS @ UC3M27

� A las nuevas demandas de los usuarios:

� Reconocimiento de voz, entrada multitáctil, etc.

� A la evolución o nuevo tipo de hardware:

� Controladores para todo tipo de nuevos dispositivos

� Sistemas multicore, virtualización, etc.

� A integrar soluciones de distintos entornos:

� Procesamiento por lotes, multiprogramación, tiempo compartido, etc.

� Multiusuario, trabajo colaborativo, etc.

� Sistemas distribuidos, servicios en red, etc.


Resumen de la evolución

ARCOS @ UC3M28

� Primera generación (años 50)

� Monitor hardware.

� Segunda generación (años 60)

� Procesamiento por lotes.

� Tercera generación (años 70)

� Multiprogramación, tiempo compartido y multiusuario.

� Cuarta generación (años 80 – actualidad)

� Sistemas distribuidos.

� Interfaz gráfica, reconocimiento de voz, etc.

� Virtualización.

Hw

S.O.


Primera generación (1945-1955)monitor hardware

ARCOS @ UC3M29

� Tubos de vacío.

� ENIAC, UNIVAC, …

� Grandes, lentos y caros.

� Complicación para programar y depurar.

� Monitor hardware.

� Asistente para el diagnóstico.

Hw

S.O.


Segunda generación (1955-1965)procesamiento por lotes

ARCOS @ UC3M30

� Transistores.

� IBM 7090, IBM1620, …

� Más pequeños, rápidos y fiables.

� Ligeras mejoras en su programación.

� Procesamiento por lotes.

� Ejecución de trabajos uno detrás de otro.

� Enlace de rutinas de librerías a programas.

� Gestión de archivos, dispositivos de E/S y almacenamiento secundario.

� Aparición de OS/360

Hw

S.O.


Tercera generación (1965-1980)multiprogramación, multitarea y multiusuario

ARCOS @ UC3M31

� Circuitos integrados.

� PDP-8, …

� Más pequeños, rápidos y fiables.

� Fortran, C, Pascal, Basic, etc.

� Multiprogramación.

� Gestión de recursos compartidos solapando esperas en CPU.

� Tiempo compartido y multiusuario.

� Compartición de recursos y multiplexación del uso de la CPU.

� Aparición de Multics, Unix, CP/M, etc.

Hw

S.O.


Cuarta generación (1980-)distribuidos, con interfaz gráfica, etc.

ARCOS @ UC3M32

� El microprocesador.

� IBM-PC, …

� Ordenadores personales.

� C++, etc.

� Distribuidos (de tiempo real)

� Conexión a Internet, aplicaciones de trabajo distribuido

� Interfaz gráfica.

� System 5, Windows 1.0, etc.

Hw

S.O.


Cuarta generación (2005-)virtualización, multiprocesamiento, etc.

ARCOS @ UC3M33

� Los system-on-chip y multicores.

� Tables, smartphones, …

� Era post-PC.

� .net, java, python, php, etc.

� Virtualización.

� Cloud computing, legacy computing, desktop móvil, etc.

� Nuevas formas de interacción.

� Reconocimiento del habla, entrada multitáctil, etc..

� Pantallas 3D, holografías, etc.

Hw

S.O.


Evolución de los sistemas operativos

ARCOS @ UC3M34

55

60

65

70

75

80

85

90

95

00

03

IOCS

DOS/360

DOS/VDSE

VS

VS/ESA

OS/360

MVS/370

MVS/XA

MVS/ES

TSO

IBSYS

CTSS

CP/CM5

VM/370

VM/XA

VM/ESA

SYSTEM III

SYSTEM V

SYSTEM V.4

MULTICS

UNIX

UNIXV.7

AIX/370

AIXSUN OS

POSIX

SOLARIS 2

4.1BSD

4.2BSD

4.3BSD

4.4BSD

MACH

OSF/1

AIX/ESA

XENIX MS-DOS 1.0

CP/M

DR/DOS

OS/2WIN 3.0

WIN NT

WIN 2000

WIN 9X

WIN XP

LINUX

RSX-11M

VMS 1.0

VMS 5.4

VMS 7.3

WIN 3.1

SOLARIS 10

RT-11

LINUX 2.6

WIN Server 2003




3) Software multidisciplinar

ARCOS @ UC3M35

� Software multidisciplinar:

� Integra trabajos de diferentes áreas: Interfaces de usuario, software de sistema, inteligencia artificial, seguridad, Ingeniería Software, etc.

http://work-at-home-data-entry.com/wp-content/uploads/2014/10/Work-from-home-team-group-of-workers-icon.png



4) Software complejo

ARCOS @ UC3M36

� Software complejo:

� Muchas líneas de código.

� Muchos equipos de trabajo.




ARCOS @ UC3M37




https://www.openhub.net/p/linux




ARCOS @ UC3M38




http://www.zdnet.co.uk/reviews/desktop-os/2010/11/20/a-quarter-century-of-windows-40090900/5/#top




ARCOS @ UC3M39




http://www.zdnet.co.uk/reviews/desktop-os/2010/11/20/a-quarter-century-of-windows-40090900/5/#top




ARCOS @ UC3M40




http://osdelivers.blackducksoftware.com/2015/05/05/driving-into-the-future-of-automotive-technology-at-genivi-annual-members-meeting/http://www.alexmarchant.com/writing/healthcare-dot-gov-lines-of-code-comparison/



5) Software delicado

ARCOS @ UC3M41

� Software delicado:

� Un fallo en un driver (software controlador de un dispositivo) puede bloquear todo el sistema.

� Trata datos de distintas aplicaciones de distintos usuarios que no deben ser perdidos o trasladados a manos incorrectas.




ARCOS @ UC3M42




http://www.mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio/




ARCOS @ UC3M43




http://www.mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio/


Principales característicasresumen

ARCOS @ UC3M44

� Versátil

� Portabilidad

� Adaptativo

� Multidisciplinar

� Complejo

� Delicado


Contenidos

ARCOS @ UC3M45








Objetivos en el diseño de un sistema operativo

ARCOS @ UC3M46

� Rendimiento: eficiencia y velocidad� Baja sobrecarga,

uso adecuado de los recursos

� Estabilidad: robustez y resistencia� Tiempo de funcionamiento, degradación aceptable, fiabilidad e integridad

� Capacidad: prestaciones, flexibilidad y compatibilidad

� Seguridad y protección� Protección entre usuarios

� Sistema seguro para ‘los malos’

� Portabilidad

� Claridad

� Extensibilidad

Hardware

Sistema Operativo

http://www.cc.gatech.edu/~pwh/


Contenidos

ARCOS @ UC3M47








Estructura del sistema operativo

ARCOS @ UC3M48

Hardware

Kernel

Servicios

Shell

Usuarios

AplicacionesAPI

SistemaOperativo

� Gestor de recursos.

� Máquina extendida.

� Interfaz de usuario

� Interfaz de programador


Estructura del Sistema OperativoMonolítico (macrokernel)

ARCOS @ UC3M49

� Sistema monolítico.

� No estructurado.

� Desde cualquier punto del código se puede acceder a cualquier variable o función de otra parte del núcleo (kernel)

� [I] muy difícil de mantener, muy sensible a errores

App App

Servicios del sistema

Hardware

Procedimientos y estructuras del sistema operativo

Modo Usuario

Modo Kernel


Estructura del Sistema OperativoEn subsistemas

ARCOS @ UC3M50

� Sistema monolítico, compuesto de subsistemas lógicos que ofrecen interfaces bien definidas como puntos de entrada.

� Se agrupan procedimientos y estructuras de datos relacionadas.

� Ejemplo:

� Linux

App App


Hardware

Subsistema 1

Modo Usuario

Modo Kernel

…


Estructura del Sistema OperativoPor capas

ARCOS @ UC3M51

� Binario monolítico aunque codificado estructurado de forma lógica en capas.

� Cada capa proporciona acceso únicamente a la interfaz de niveles inferiores.

� Ejemplo:

� THE (Dijkstra)

� Multics, que añadió a la noción de capa la idea de anillos de privilegios

App App


Hardware

Modo Usuario

Modo Kernel

G. dispositivos de E/S

Planificación e IPC

Gestión de memoria


Estructura del Sistema OperativoMicrokernel

ARCOS @ UC3M52

� Además de estructurado, los principales componentes se ejecutan como procesos servidores, fuera del kernel.

� El microkernel tiene:� Planificación y gestión de procesos.

� Gestión de memoria virtual básica.

� Comunicación entre procesos básica.

� Ejemplo:

� Match, QNX, Minix, L4, etc.

Servidorde memoria

AppCliente

Servidorde red

Servidorde procesos

Servidorde ficheros

ServidorPantallas

Microkernel

Hardware

petición

respuesta

Modo Usuario

Modo Kernel


Estructura del Sistema OperativoWindows 2000 (visión simplificada)

ARCOS @ UC3M53

Usuario

Kernel

Ejecutivo

Drivers Kernel

Win32Aplicaciones

Usuario

DLLs de Subsitema L

Procesos del Sistema y Servicios

POSIXOS/2

Win32User/GDI

Subsistemas de entorno

Ntdll.dll

Hardware Abstraction Layer (HAL)

http://technet.microsoft.com/en-us/library/cc750820.aspx


Ejemplo de estructura de subsistemasLinux (versión simplificada)

ARCOS @ UC3M54

Usuario

Kernel

Núcleo

Servicios

Shell


SS.OO. RealesLinux (versión ‘menos’ simplificada)

http://www.makelinux.net/kernel_map.shtml ARCOS @ UC3M55


Contenidos

ARCOS @ UC3M56








Estructura del sistema operativo

ARCOS @ UC3M57

Hardware

Kernel

Servicios

Shell

Usuarios

AplicacionesAPI

SistemaOperativo

� Gestor de recursos.

� Máquina extendida.

� Interfaz de usuario

� Interfaz de programador


Ejecución asíncronaejecución (general)

ARCOS @ UC3M58

------------------------------------------------------------------------------------------



ARCOS @ UC3M59

------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------

Al llegar un evento (ex) se ejecuta el manejador

asociado (hx)



ARCOS @ UC3M60

------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------

Al finalizar el manejador, se continúa la ejecución por donde fue interrumpida


Ejecución asíncronacódigo (general)

ARCOS @ UC3M61

int main ( … ){

…On (event1, handler1) ;…

}

1) Asociar el manejador (handler1) al evento



ARCOS @ UC3M62

int main ( … ){


}

void handler1 ( … ){}

…

2) Codificar la función manejador que tratará el evento




ARCOS @ UC3M63

2) Codificar la función manejador que tratará el evento


3) Para comunicar funciones, se usa variables globalesint global1;

…

int main ( … ){


}

void handler1 ( … ){}

…


Ejemplo de ejecución asíncronaSeñales

ARCOS @ UC3M64

#include<stdio.h>#include<signal.h>#include<unistd.h>

void sig_handler (int signo){

if (signo == SIGINT)printf("received SIGINT\n");

}

int main(void){

if (signal (SIGINT, sig_handler ) == SIG_ERR) printf("\ncan't catch SIGINT\n");

sleep(60); // simula un proceso largo.

return 0;}

signal.h

http://www.thegeekstuff.com/2012/03/catch-signals-sample-c-code/


Ejecución asíncronaejemplo simplificado

ARCOS @ UC3M65

S.O.

HW.

App.

CPU Disco RAM

• char buffer[1024];…

• read(fd,buffer)•

Pi



ARCOS @ UC3M66

S.O.

HW.

App.

CPU Disco RAM

• Pedir bloque• Ejecutar Pi +1

• char buffer[1024];…


ll. sistema

Pi



ARCOS @ UC3M67

S.O.

HW.

App.

CPU Disco RAM


Pi • char buffer[1024];…


ll. sistema

Pi +1 • int x;…

• for (x=0; x<900; x++);

•



ARCOS @ UC3M68

S.O.

HW.

App.

CPU Disco RAM




ll. sistema

Pi +1 • int x;…

• for (x=0; x<900; x++);

•



ARCOS @ UC3M69

S.O.

HW.

App.

CPU Disco RAM


int. hw

• Copiar a RAM• Pi listo• Continuar Pi +1



ll. sistema

Pi +1 • int x;…

• for (x=0; x<900; x++);

•



ARCOS @ UC3M70

S.O.

HW.

App.

CPU Disco RAM


int. hw

• Copiar a RAM• Pi listo• Continuar Pi +1



ll. sistema

Pi +1 • int x;…

• for (x=0; x<900; x++);

•


Estructura base del sistema operativocódigo (general)

ARCOS @ UC3M71

int global1; …

int main ( … ){

…On (event1, handler1) ;On (event2, handler2) ;On (event3, handler3) ;…

}

void handler1 ( … ) { xxx }

…

void handler2 ( … ) { xxx }

void handler3 ( … ) { }i.h. 1

ll. sistema

i.h. 2

Disco

Red

App 1

…

• Copiar a RAM• Pu listo• Continuar Pv


Ejecución asíncronasoporte hardware

ARCOS @ UC3M72

S.O.

HW.

App.

CPU Disco RAM

int. hw

• Copiar a RAM• Pu listo• Continuar Pv



X

int. hw

• Dato a RAM• Px listo• Continuar Py


Interrupciones hardwarerepaso (1/4)

ARCOS @ UC3M73

� Cada periférico (capaz de generar una petición de interrupción) dispone de una línea denominada IRQ (Interrupt ReQuest)

� Puede haber múltiples dispositivos en una línea, se precisa muestreo para conocer el peticionario

� Todas las líneas se conectan a un PIC (Programmable Interrupt Controller)

� Actualmente se usa un APIC (Advanced Programmable Interrupt Controller)

� El PIC se conecta a la CPU por una línea de aviso de interrupción pendiente (INT)

� El PIC y la CPU también están conectados por el bus de datos

Understanding the Linux kernel (2nd edition)

Periférico iPIC

CPU...

Bus Datos

INT

IDT

IRQi_interrupt()

do_IRQ(i)

IRQ

vector

Int. i descriptor

...



ARCOS @ UC3M74

� El PIC monitoriza las líneas de IRQ esperando la llegada de una señal

� Si llega una señal entonces:

� Asocia al IRQ del periférico un valor que guarda en un registro del PIC (llamado vector)

� Avisa a la CPU a través de la línea de interrupción pendiente (INT)

� La CPU lee del registro (como puerto de E/S o como dirección de memoria) el vector

� La CPU escribe en el registro de control del PIC que ya leyó el vector

� El PIC desactiva la línea de interrupción pendiente. borra el vector y vuelve a monitorizar…


Periférico iPIC

CPU...

Bus Datos

INT

IDT

IRQi_interrupt()

do_IRQ(i)

IRQ

vector

Int. i descriptor

...



ARCOS @ UC3M75

� El PIC puede permitir deshabilitar selectivamente las IRQ

� El PIC deja de avisar a la CPU de la petición de una IRQ hasta que se habiliten: no se pierden.

� Deshabilitar a nivel de CPU (mask/unmask) es diferente: ignora la INT

� El PIC puede permitir tener niveles de prioridad de interrupción

� Se asocia a cada IRQ con una prioridad

� Si hay varias IRQ, el PIC ‘atiende’ primero las de mayor prioridad (resto: deshabilitado temporalmente)

� Si el PIC no tiene niveles de prioridad, se pueden simular por software en el sistema operativo


Periférico iPIC

CPU...

Bus Datos

INT

IDT

IRQi_interrupt()

do_IRQ(i)

IRQ

vector

Int. i descriptor

...



ARCOS @ UC3M76

� La CPU detecta la petición de INT

� Acepta la interrupción: copia el vector por el bus de datos y ACK al PIC

� Busca en la Interrupt Descriptor Table (IDT) la rutina de tratamiento asociada

� Guarda el estado del procesador en pila, pasa a modo privilegiado y ejecuta la RTI

� Puede que varias RTI (do_IRQ) compartan una misma interrupción (uso de enumeración)

� Puede que varias interrupciones compartan una rutina genérica común a ellas

� Recupera el estado de pila, y ejecuta RETI (paso a modo previo y vuelta a lo interrumpido)

Periférico iPIC

CPU...

Bus Datos

INT

IDT

IRQi_interrupt()

do_IRQ(i)

IRQ

vector

Int. i descriptor

...


Llamada al sistemasoporte hardware

ARCOS @ UC3M77

S.O.

HW.

App.

CPU Disco RAM




ll. sistema


Llamada al sistema

ARCOS @ UC3M78

� Existe una instrucción en ensamblador que genera una interrupción por software

� La CPU detecta la petición de INT

� Busca en la Interrupt Descriptor Table (IDT) la rutina de tratamiento asociada

� Guarda el estado del procesador en pila, pasa a modo privilegiado y ejecuta la RTI

� Puede que varias RTI (do_IRQ) compartan una misma interrupción (uso de enumeración)

� Puede que varias interrupciones compartan una rutina genérica común a ellas

� Recupera el estado de pila, y ejecuta RETI (paso a modo previo y vuelta a lo interrumpido)

CPU

Bus Datos

INT

IDT

IRQi_interrupt()

do_IRQ(i)

Int. i descriptor

...


Contenidos

ARCOS @ UC3M79








Ejecutables (1/1)

ARCOS @ UC3M80

� Los primeros kernels tenían que:

� Incluir código para todos los posibles dispositivos.

� Cada cierto tiempo se recompilaba para añadir los nuevos dispositivos.

� Se distribuía como un conjunto de ejecutables.



D#10D#15


Módulos (1/2)

ARCOS @ UC3M81

� Los módulos inicialmente se desarrollaron para permitir la inclusión condicional de controladores de dispositivos (drivers)

� Los módulos ofrecen añadir dinámicamente código de un driver pre-compilado.

� Se distribuyen como bibliotecas dinámicas para el kernel (.so/.dll).

� El módulo puede descargarse cuando el dispositivo deje de usarse.



D#10

D#15


Módulos (2/2)

ARCOS @ UC3M82

� La gran mayoría de sistemas operativos modernos tienen un kernel que permite el uso de módulos:

� Linux, Solaris, BSD, Windows, etc.

� Los módulos se utilizan no solo para los drivers de los dispositivos, actualmente también se utilizan para añadir otro tipos de funcionalidad:

� El kernel de Linux lo utiliza extensivamente para sistemas de ficheros, protocolos de red, llamadas al sistema, etc.


App App

Kernel

F#18


Ejemplo de módulosWindows 2000

ARCOS @ UC3M83

System Service Dispatcher

Sistema E/S

MonitorSeguridad

Procesos/Threads

Serviciosde objetos

MemoriaMgmt

Win32GDI

Exec.RTL

Drivers

Hardware Abstraction Layer (HAL)

Kernel

Gestión de ObjectosSistemasficheros

Procesosde sistema

ServiciosAplicacs.Usuario

Subsistemasde entorno

Subsystem DLLInterface DLL

Session MgrWinLogon

ReplicatorAlerter

Event Log

Win32POSIXOS/2

Ntdll.dllUsuario

Kernel

Lección 1Introducción

Grupo ARCOS

Diseño de Sistemas Operativos

Grado en Ingeniería Informática

Universidad Carlos III de Madrid

Education

DSO-1: Introducción al diseño de un sistema operativo (v3b)