E Structur A Sistema So Perati Vos

Sistemas Operativos
Curso 2013
Estructura de los sistemas
operativos
Sistemas Operativos | Curso 2013 | Estructura de los sistemas operativos 2/34
Agenda
Componentes de un sistema operativo.
Servicios del sistema operativo (system services).
Llamados a sistema (system calls).
Estructura del sistema.
!"uinas virtuales
Componentes del sistema operativo
#or su comple$idad un sistema operativo de%e ser& en su dise'o&

modulari(ado en varios componentes)
*dministraci+n de procesos.
*dministraci+n de memoria.
Su%sistema de Entrada/Salida.
*dministraci+n de almacenamiento secundario.
Su%sistema de arc,ivos.
Su%sistema de red.
Sistema de protecci+n.
Administracin de procesos: Proceso
-n pro.rama en la memoria / C#- / acceso a dispositivos / recursos

constitu0en un proceso.
-n pro.rama es una entidad pasiva& mientras "ue un proceso es una

entidad activa.
Cada proceso cuenta con un contador de pro.rama (PC program counter)

"ue determina la pr+1ima instrucci+n de c+di.o a e$ecutar.
El proceso necesita de ciertos recursos (C#-& memoria& arc,ivos& 0

dispositivos de E/S) para reali(ar su tarea.
Administracin de procesos
El sistema al%er.ar! muc,os procesos compitiendo por los recursos 0 ser!

el responsa%le de proveer de medios o servicios para "ue realicen su tarea)
Crear 0 destruir procesos.
Suspensi+n 0 reanudaci+n de procesos.
#roveer mecanismos para la cooperaci+n (sincroni(aci+n) 0 comunicaci+n entre
los procesos.
#roveer mecanismos para prever la .eneraci+n de dead-locks o lo.rar salir de
ellos.
Administracin de memoria
La memoria principal es un arre.lo de pala%ras o bytes.
Es un repositorio de datos de r!pido acceso compartido por los C#-s 0 los

dispositivos.
La memoria es un !rea de almacenamiento com4n a los procesadores 0

dispositivos del sistema d+nde se almacenan pro.ramas& para su
e$ecuci+n& 0 datos.
El vincular pro.ramas a direcciones a%solutas es 5uertemente dependiente

del ,ard6are i.ual "ue la posi%ilidad de reu%icaci+n.
El sistema de%er! administrar el lu.ar li%re 0 ocupado& decidir "ue proceso

podr! comen(ar cu!ndo es car.ado en memoria.
Administracin de memoria
#ara lo.rar la multipro.ramaci+n es necesario mantener varios pro.ramas

en memoria al mismo tiempo.
E1isten varios es"uemas para la administraci+n de la memoria 0 re"uieren

distinto soporte del ,ard6are.
El sistema operativo es responsa%le de las si.uientes tareas)

antener "ue partes de la memoria est!n siendo utili(adas 0 por "ui8n.
9ecidir cuales procesos ser!n car.ados a memoria cuando e1ista espacio de
memoria disponi%le.
*si.nar 0 "uitar espacio de memoria se.4n sea necesario.
Sistemas Operativos | Curso 2013 | Estructura de los sistemas operativos :/34
Subsistema de entrada/salida
El sistema operativo de%er! encapsular 0 ocultar las caracter;sticas

espec;5icas de los di5erentes dispositivos de almacenamiento 0 o5recer
servicios comunes para todos los medios de almacenamiento.
#ara ello proveer! de)

-n con$unto de servicios "ue provean la inter5ase con el su%sistema e
implementen t8cnicas de cache& buffering 0 spooling.
-na inter5ase cliente con el sistema operativo para los mane$adores de
dispositivos o device drivers "ue permitir! interactuar (mediante car.as
din!micas o no) con cual"uier modelo de dispositivo.
Device drivers espec;5icos.
onta$e 0 desmonta$e (Mount/Dismount) de dispositivo.
Sistemas Operativos | Curso 2013 | Estructura de los sistemas operativos </34
Administracin de almacenamiento secundario
La memoria principal es vol!til 0 demasiado pe"ue'a para .uardar todos

los datos 0 pro.ramas "ue son necesarios para el 5uncionamiento del
sistema.
La ma0or;a de los sistemas actuales utili(an discos como principal medio

para .uardar toda la in5ormaci+n.
El sistema operativo es responsa%le de las si.uientes actividades en

administraci+n de almacenamiento secundario)
*dministrar el espacio li%re.
*si.naci+n del lu.ar de la in5ormaci+n.
*l.oritmos de plani5icaci+n de disco.
Subsistema de arcivos
#roporciona una vista uni5orme de todas las 5ormas de almacenamiento en

los di5erentes dispositivos implementando el concepto de arc,ivo como una
colecci+n ar%itraria de bytes u otras clases o or.ani(aciones m!s
so5isticadas.
=mplementar! los m8todos de)

*%rir& Cerrar& E1tender
Leer& Escri%ir
Crear 0 %orrar directorios
!ed
En un sistema distri%uido (no se comparten 5;sicamente memoria ni

dispositivos) los con$untos de procesos interact4an a trav8s de un canal de
comunicaci+n en el conte1to de una red de comunicaci+n.
En .eneral se .enerali(a el concepto de dispositivo virtual implementando

un mane$ador (driver) "ue encapsula el acceso a dispositivos remotos.
Sistema de proteccin
En un sistema multiusuario donde se e$ecutan procesos en 5orma

concurrente se de%en tomar medidas "ue .aranticen la ausencia de
inter5erencia entre ellos.
#or protecci+n nos re5erimos a los mecanismos por los "ue se controla al
acceso de los procesos a los recursos.
El mecanismo de%e incorporar la posi%ilidad de de5inir re.las de acceso 0

ase.urar su veri5icaci+n en toda ocasi+n "ue corresponda.
Servicios del SO
El sistema %rindar! un entorno de e$ecuci+n de pro.ramas d+nde se

dispondr! de un con$unto de servicios "ue ser!n accesi%le mediante una
inter5ase %ien de5inida.
Servicios %!sicos "ue de%e %rindar un sistema operativo)

E$ecuci+n de pro.ramas.
Operaciones de Entrada/Salida.
anipulaci+n de sistemas de arc,ivos.
Comunicaci+n entre procesos.
anipulaci+n de errores (e1cepciones).
E"ecucin de programas
El sistema de%e ser capa( de car.ar un pro.rama a memoria 0 e$ecutarlo.
El pro.rama de%er! poder en al.4n momento 5inali(ar su e$ecuci+n& 0a sea

de 5orma normal o anormal (indicando un error).
Operaciones de entrada/salida
-n pro.rama en e$ecuci+n necesitar! de operaciones de Entrada/Salida

para acceder a un arc,ivo o dispositivo.
#or e5iciencia 0 protecci+n los usuarios no acceder!n directamente al

dispositivo.
El sistema de%er! proveer un mecanismo de acceso.

#anipulacin del sistema de arcivos
Se de%er! proveer acceso al sistema de arc,ivos.
Las operaciones m;nimas ser!n)

Crear& %orrar& leer& escri%ir& a%rir& cerrar
Comunicacin entre procesos
Es desea%le "ue los procesos puedan comunicarse.
Se de%er! proveer mecanismos de comunicaci+n entre ellos 0a sea "ue

est8n en el mismo computador (a trav8s de memoria compartida)& o en
di5erentes computadores (a trav8s de trans5erencias de pa"uetes de red
entre los sistemas operativos involucrados).
>am%i8n de%e permitir la sincroni(aci+n de procesos "ue tra%a$an en

con$unto.
Sistemas Operativos | Curso 2013 | Estructura de los sistemas operativos 1:/34
$eteccin de errores
El sistema de%er! tomar decisiones adecuadas ante eventuales errores

"ue ocurran)
?allo en un dispositivo de memoria.
?allo en la 5uente de ener.;a.
?allo en un pro.rama.
Etc.
Sistemas Operativos | Curso 2013 | Estructura de los sistemas operativos 1</34
Servicios del SO
Otros servicios de prop+sito .eneral "ue de%er! %rindar el sistema

operativo son)
*si.naci+n de recursos.
Conta%ili(aci+n.
#rotecci+n.
-na ve( "ue est!n de5inidos los servicios "ue %rindar! el sistema
operativo& se puede empe(ar a desarrollar la estructura del sistema.
%lamados al sistema
Los llamados al sistema (system calls) son una inter5a(& provista por el
n4cleo& para "ue los procesos de usuarios accedan a los di5erentes
servicios "ue %rinda el sistema operativo.
*l principio los system calls esta%an desarrollados en len.ua$e de la

ar"uitectura de la m!"uina.
En los sistemas modernos est!n pro.ramados en len.ua$es de

pro.ramaci+n de alto nivel como C o C//.
Los servicios son invocados por los procesos en modo usuario& cuando
e$ecutan lo ,acen en modo monitor& 0 al retornar vuelven al modo usuario.
>;picamente a los system calls se les asocia un n4mero "ue los identi5ica
(en Linu1 son apro1imadamente 320).
%lamados al sistema
La llamada a un system call inclu0e las si.uientes tareas)

Car.ar los par!metros en el lu.ar adecuado (stack o re.istros).
Car.ar el n4mero de system call en al.4n re.istro espec;5ico (E$) ea1 en =ntel).
=nvocar a la interrupci+n por so5t6are (trap) adecuada (system call handler).
El ,ard6are cam%ia el %it de modo a monitor e invoca al mane$ador de la
interrupci+n "ue controla "ue el n4mero de system call pasado en el re.istro
sea menor "ue el ma0or del sistema 0& 5inalmente& invoca al system call
correspondiente.
El valor retornado por el system call es puesto en un re.istro espec;5ico (E$.) ea1
en =ntel).
%lamados al sistema
E1isten 3 5ormas de pasar los par!metros al sistema operativo)

* trav8s de los re.istros) Se utili(an un con$unto de re.istros para pasar los
par!metros. >iene el pro%lema de la cantidad de par!metros es 5i$a 0 "ue
restrin.e el tama'o del valor.
En =ntel se utili(an 2 re.istros) e%1& ec1& ed1& esi& 0 edi.
-n %lo"ue de memoria apuntado a trav8s de un re.istro.
En el stack del proceso "ue reali(a el llamado. El proceso .uarda los
par!metros con operaciones push so%re el stack 0 el sistema operativo los
saca con la operaci+n pop.
9e la misma 5orma se pueden reci%ir los datos de respuesta

%lamados al sistema
%lamados al sistema
Los system calls se clasi5ican en distintos tipos)

Control de procesos
Car.ar& e$ecutar& 5inali(ar& a%ortar& conse.uir atri%utos& car.ar atri%utos& esperar por
tiempo& esperar por un evento o se'al& conse.uir o li%erar memoria& etc.
@esti+n de arc,ivos
Crear& %orrar& a%rir& cerrar& leer& escri%ir& conse.uir o car.ar atri%utos& etc.
@esti+n de dispositivos
Ae"uerir o li%erar un dispositivo& leer o escri%ir& %uscar o car.ar atri%utos de un
dispositivo& etc.
@esti+n de in5ormaci+n del sistema
Conse.uir o car.ar la ,ora del sistema& datos del sistema& de procesos& etc.
Comunicaciones
Crear o destruir cone1iones& enviar o reci%ir mensa$es& etc.
Estructura del sistema
La estructura interna de los sistemas operativos pueden ser mu0 di5erentes.
Se de%en tener en cuenta)

etas de los usuarios) ser ami.a%le& intuitivo& con5ia%le& se.uro& r!pido& etc.
etas del sistema) 5!cil de dise'ar& implementar 0 mantener& tam%i8n 5le1i%le&
con5ia%le 0 e5iciente.
9ise'o del sistema)

Sistema monol;tico.
Sistema en capas.
Sistema con micron4cleo (microBernel).
Sistema monol&tico
Co se tiene una estructura de5inida.
El sistema es escrito como una colecci+n de procedimientos& "ue pueden

ser invocados por cual"uier otro.
Co e1iste Docultaci+n de in5ormaci+nE& 0a "ue cual"uier procedimiento

puede invocar a otro.
Si %ien todo procedimiento es p4%lico 0 accesi%le a cual"uiera& es posi%le

tener %uenos dise'os 0 lo.rar& de esa 5orma& %uena e5iciencia en el
sistema.
E$.) SF9OS.
Los componentes pueden invocar procedimientos de cual"uiera.
E$.) Linu1
Linu1 es un n4cleo monol;tico "ue a lo.rado un %uen dise'o orientado a o%$etos
(sistema modular).
Sistema en capas
Se or.ani(a el dise'o en una

$erar"u;a de capas construidas
una encima de la otra.
Los servicios "ue %rinda cada

capa son e1puestos en una
inter5ase p4%lica 0 son
consumidos solamente por los de
la capa de arri%a.
La capa 0 es el ,ard6are 0 la C
es la de procesos de usuario.
Sistemas Operativos | Curso 2013 | Estructura de los sistemas operativos 2:/34
Sistema en capas
Genta$as)
odularidad.
9epuraci+n 0 veri5icaci+n de cada capa por separado.
9esventa$as)
*lto costo de de5inici+n de cada capa en la etapa de dise'o.
enos e5iciente 5rente al sistema monol;tico 0a "ue su5re de overhead al pasar
por cada capa.
Sistemas Operativos | Curso 2013 | Estructura de los sistemas operativos 2</34
Sistema en capas
E$.) en capas H OS/2.

Sistema con micron'cleo (micro)ernel*
Se constitu0e de un n4cleo "ue %rinde un mane$o m&nimo de procesos+

memoria 0& adem!s& provea de una capa de comunicacin entre
procesos.
La capa de comunicaci+n es la 5uncionalidad principal del sistema.
Los restantes servicios del sistema son construidos como procesos

separados al micron4cleo "ue e$ecutan en modo usuario.
El acceso los servicios del sistema se reali(a a trav8s de pasa$e de

mensa$es.
Sistema con micron'cleo
Genta$as)
*umenta la porta%ilidad 0 escala%ilidad 0a "ue encapsula las caracter;sticas
5;sicas del sistema
#ara incorporar un nuevo servicio no es necesario modi5icar el n4cleo.
Es m!s se.uro 0a "ue los servicios corren en modo usuario.
El dise'o simple 0 5uncional t;picamente resulta en un sistema m!s con5ia%le.
E$. Iindo6s C>
#,-uinas .irtuales
Se puede ver como una e1tensi+n de los sistemas multipro.ramados pero

a m!s %a$o nivel
Los procesos no solamente tra%a$an so%re el sistema operativo como si
5ueran el 4nico proceso en el sistema sino "ue tienen una copia virtual del
,ard6are de la C#-
Las m!"uinas virtuales corren como procesos a nivel de usuario 0 el
administrador de Gs (hypervisor) implementa un modo usuario virtual 0 un
modo administrador virtual
>am%i8n se implementan discos virtuales so%re los discos reales para las
m!"uinas virtuales
9os modos %!sicos

>ipo 1) el administrador corre directamente so%re el ,ard6are
>ipo 2) el administrador corre como un proceso so%re un sistema operativo
normal
#,-uinas virtuales: bene/icios
Se.uridad
Los procesos en cada m!"uina virtual son completamente independientes de
los procesos en las otras
?acilidad de desarrollo
Se pude correr un sistema operativo de test en una m!"uina virtual sin correr
ries.os con el sistema real
?le1i%ilidad
Correr un sistema operativo de una ar"uitectura en una m!"uina di5erente
*lta disponi%ilidad
En caso de 5alla de una G se puede levantar otra r!pidamente en otro
,ard6are
#,-uinas virtuales: desventa"as
Los tiempos de las operaciones pueden tardar m!s "ue en un sistema real
>iempo adicional por traducir las operaciones
>iempo de respuesta de la m!"uina mu0 poco predeci%le por uso del

sistema operativo de %ase u otras Gs
Co apropiado para sistemas de tiempo real

E Structur A Sistema So Perati Vos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

E Structur A Sistema So Perati Vos

Cargado por

Copyright:

Formatos disponibles

Sistemas Operativos

Componentes de un sistema operativo.

Servicios del sistema operativo (system services).

Llamados a sistema (system calls).

Estructura del sistema.

#or su comple$idad un sistema operativo de%e ser& en su dise'o&

-n pro.rama en la memoria / C#- / acceso a dispositivos / recursos

-n pro.rama es una entidad pasiva& mientras "ue un proceso es una

Cada proceso cuenta con un contador de pro.rama (PC program counter)

El proceso necesita de ciertos recursos (C#-& memoria& arc,ivos& 0

El sistema al%er.ar! muc,os procesos compitiendo por los recursos 0 ser!

La memoria principal es un arre.lo de pala%ras o bytes.

Es un repositorio de datos de r!pido acceso compartido por los C#-s 0 los

La memoria es un !rea de almacenamiento com4n a los procesadores 0

El vincular pro.ramas a direcciones a%solutas es 5uertemente dependiente

El sistema de%er! administrar el lu.ar li%re 0 ocupado& decidir "ue proceso

#ara lo.rar la multipro.ramaci+n es necesario mantener varios pro.ramas

E1isten varios es"uemas para la administraci+n de la memoria 0 re"uieren

El sistema operativo es responsa%le de las si.uientes tareas)

El sistema operativo de%er! encapsular 0 ocultar las caracter;sticas

#ara ello proveer! de)

La memoria principal es vol!til 0 demasiado pe"ue'a para .uardar todos

La ma0or;a de los sistemas actuales utili(an discos como principal medio

El sistema operativo es responsa%le de las si.uientes actividades en

#roporciona una vista uni5orme de todas las 5ormas de almacenamiento en

=mplementar! los m8todos de)

En un sistema distri%uido (no se comparten 5;sicamente memoria ni

En .eneral se .enerali(a el concepto de dispositivo virtual implementando

En un sistema multiusuario donde se e$ecutan procesos en 5orma

El mecanismo de%e incorporar la posi%ilidad de de5inir re.las de acceso 0

El sistema %rindar! un entorno de e$ecuci+n de pro.ramas d+nde se

Servicios %!sicos "ue de%e %rindar un sistema operativo)

El sistema de%e ser capa( de car.ar un pro.rama a memoria 0 e$ecutarlo.

El pro.rama de%er! poder en al.4n momento 5inali(ar su e$ecuci+n& 0a sea

-n pro.rama en e$ecuci+n necesitar! de operaciones de Entrada/Salida

#or e5iciencia 0 protecci+n los usuarios no acceder!n directamente al

El sistema de%er! proveer un mecanismo de acceso.

Se de%er! proveer acceso al sistema de arc,ivos.

Las operaciones m;nimas ser!n)

Es desea%le "ue los procesos puedan comunicarse.

Se de%er! proveer mecanismos de comunicaci+n entre ellos 0a sea "ue

>am%i8n de%e permitir la sincroni(aci+n de procesos "ue tra%a$an en

El sistema de%er! tomar decisiones adecuadas ante eventuales errores

Otros servicios de prop+sito .eneral "ue de%er! %rindar el sistema

*l principio los system calls esta%an desarrollados en len.ua$e de la

En los sistemas modernos est!n pro.ramados en len.ua$es de

La llamada a un system call inclu0e las si.uientes tareas)

E1isten 3 5ormas de pasar los par!metros al sistema operativo)

9e la misma 5orma se pueden reci%ir los datos de respuesta

Los system calls se clasi5ican en distintos tipos)

La estructura interna de los sistemas operativos pueden ser mu0 di5erentes.

Se de%en tener en cuenta)

9ise'o del sistema)

Co se tiene una estructura de5inida.

El sistema es escrito como una colecci+n de procedimientos& "ue pueden

Co e1iste Docultaci+n de in5ormaci+nE& 0a "ue cual"uier procedimiento

Si %ien todo procedimiento es p4%lico 0 accesi%le a cual"uiera& es posi%le

Se or.ani(a el dise'o en una

Los servicios "ue %rinda cada

E$.) en capas H OS/2.

Se constitu0e de un n4cleo "ue %rinde un mane$o m&nimo de procesos+

La capa de comunicaci+n es la 5uncionalidad principal del sistema.

Los restantes servicios del sistema son construidos como procesos