Download Introducción

Sistemas de
Computación
2007-1
Cecilia Hernández
chernand@inf.udec.cl
Que veremos hoy?
Detalles del curso
 Aspectos importantes acerca SOs
 Qué es un SO (Sistema Operativo)?
 Contenidos
 Objetivos
 Tendencias

Detalles del curso


Sitio web: http://www.inf.udec.cl/~sc
Bibliografía
 Silberschatz, Galvin, Gagne, "Operating System
Concepts", 5th y 6th edition, John Wiley & Sons, Inc
(2003)
 Silberschatz, Galvin, Gagne, "Operating System Concepts
with Java", 6th edition, John Wiley & Sons, Inc (2004)
 Andrew Tanenbaum, “Sistemas Operativos Modernos”,
Primera Edición, Prentice Hall. 1993.
 Deitel H. M. “Sistemas Operativos”. Segunda Edición,
Addison Wesley Iberoamericana. 1993.
 Bovet Daniel P., Sesati Marco, “Understanding the Linux
Kernel” (2nd Edition). O'Reilly Media, Inc. 2002
 Andrew Tanenbaum, “Sistemas Operativos Distribuidos”,
Primera Edición, Prentice Hall. 1995
Evaluación



2 Certámenes
Aprox. 6 Proyectos
Participación
Nota Presentación: 0.85*prom certs + 0.15*prom proyectos
Si Nota Presentación < 4
Nota Final = Nota Presentación*0.65 + Examen*0.3 +
Nota Participación*0.05
Else
Nota Final = 0.65*prom certs + 0.3*prom proyectos +
Nota Participación*0.05
Reglas del Juego





Trabajos en grupos de 2 o 3 personas.
Penalidad por atraso, 10% por día, sábado y
domingo incluídos
No asistencia a certamen/proyecto/tarea debe
ser avalado con certificado médico
La no entrega de tarea o proyecto tiene como
consecuencia calidad de NCR
La copia de un certamen/proyecto/tarea es
causal de 1 para los involucrados
Aspectos importantes acerca SO

SO: Componente básico de un sistema
computacional moderno


Magia para la mayoría de las personas
SO: ejemplo de sistema complejo

Muy grande, muy caro de construir
• Windows NT, XP: por ~10 años, más de 1000
personas involucradas.

Cómo manejar complejidad?


Abstracción, modularidad, proceso iterativo
Int main() { cout<<“ Hola Mundo”<<endl;}
• Requiere ejecución de muchas líneas de código, no
visible a programador.
Qué es un SO?
emacs
g++
Aplicación/Firefox
SO
Hardware

SO : software entre Hardware y aplicaciones



Proporciona abstracción del hardware
Proporciona protección
Permite utilizar hardware de millones de
maneras
Objetivos de la clase


Perspectiva de los Sistemas Operativos
 Como usuario/programador, como desarrollar
aplicaciones
 Como diseñar/implementar un Sistema Operativo
Aspectos a aprender en esta clase
 Cuáles son las partes de un sistema operativo
 Componentes de SO y su interacción
 Cuáles son las interfaces importantes
 Cuáles son las características/requerimientos de un
sistema operativo (se compromenten y varían en el
tiempo)
 Políticas y mecanismos
 Cuáles son los algoritmos típicos utilizados
Programa Tentativo







Aspectos Generales e Historia
Administración de Procesos
Administración de Memoria
Sistemas de Entrada/Salida
Sistemas de Archivos
Protección y Seguridad
Inroducción a Sistemas Distribuidos
Sistemas Operativos

Qué es ?

Administrador de recursos
• Abstracción
• Desempeño
• Protección

Soporte usuario/programador
• Abstracción
• Normalmente viene con conjunto de utilitarios

Todo el software que el usuario no escribió que
le permite escribir aplicaciones
• No completamente, programador utiliza editores,
compiladores y bibliotecas que no son parte de SO,
pero muchas veces vienen con instalaciones
estandar
Definición de Sistema Operativo

Como administrador de recursos

Nivel de software que maneja y controla los recursos
computacionales y periféricos por el usuario.
• Abstracción de complejidad del hardware.
• Sistema operativo abstrae hardware en recursos lógicos
• CPU -> Procesos, Hebras
• Memoria -> Memoria virtual, paginación
• Disco -> Archivos
• Tarjetas de Red -> sockets
• Control en la ejecución de procesos, protección usuarios, etc.

Como apoyo en el desarrollo de aplicaciones

Set de utilitarios y ambientes que ayudan al usuario a crear
aplicaciones
• Shells, sistemas gráficos, etc
Estructura Lógica de un Sistema
Operativo
Servicios para
Aplicaciones
Servicios independientes
del Hardware
Servicios dependientes
del Hardware
Shells
Ambientes gráficos
Administración
de Procesos
TCP/IP
Utilitarios
Sistemas
Archivos
Administración
de Memoria
Drivers
Control de acceso
Interrupciones, Memoria física, TLB,
CPUs, dispositivos
Beneficios usando SO

Para programadores desarrollando aplicaciones

Facilidades para programar
• Es mejor usar archivos a tener que lidiar con el disco
directamente


Portabilidad (configuración entre máquinas y arquitecturas)
Para usuarios

Seguridad
• Sistema operativo proteje procesos (espacios de memoria
independientes). De usuarios, usuario/kernel

Justicia
• Sistema operativo regula que todos los procesos tengan su
oportinidad de ejecución

Eficiencia
• Muchos usuarios pueden compartir un Computador
• Muchos procesos se ejecutan concurrentemente
Características/requerimientos de un
SO







Estructura. Como organizar componentes de SO
Compartir. Como los usuarios comparten los recursos
Nombres. Como los usuarios o programas nombran los
recursos
Protección. Como los usuarios/programas se protejen entre
ellos (usuario/usuario, programa/programa)
Seguridad. Como se proteje el sistema de ataques. Como
se mantiene la integridad del sistema y sus recursos.
Rendimiento. Como mejorarlo (por qué es lento?)
Confiabilidad. Y en caso de falla (programa o hardware),
que ocurre?
Características/requerimientos de un
SO





Extensibilidad. Como podemos incorporar nuevas
características
Comunicación. Como los usuarios se comunican con
otros usuarios en diferentes computadores
Concurrencia. Como son creadas y controladas las
actividades concurrentes/paralelas
Escalabilidad. Como reacciona el sistema cuando la
carga de trabajo o recursos aumentan
Persistencia. Como hacer que los datos perduren en
el tiempo.
Características/requerimientos de un
SO


Distribución. Como múltiple computadores interectuan
entre sí.
Contraloría o Monitoreo. Como se lleva la cuenta del
uso de recursos. En sistemas comerciales, como
cobrar en función de algunos índices (uso disco,
velocidad de conexión, tiempo ejecución, etc)
Por qué deben estudiar SO en su
carrera?

Construir, modificar o administrar un SO o alguno de sus
componentes

Tomando en cuenta el hardware sobre el cual se ejecutan
• Mayor discusión más adelante.

Entender el desempeño de un SO




Aplicación en otras áreas



Comportamiento de SO afecta toda el sistema y usuarios que la
usan
Constituye un desafío para entender sistemas complejos
Midiendo y optimizando desempeño del sistema
Ingeniería de software (diseño e implementación de aplicaciones),
usando recursos y abstracciones disponibles
Desarrollo en la construcción de algoritmos
Más avanzados
 Proponiedo cambios en técnicas, algoritmos que maximicen
la facilidad de configuración y utilización, uso de recursos,
proposiciones en cambio de arquitectura, construcción de
compiladores, mejoras en protección y seguridad, etc
Evolución de SOs

Con el inicio de los computadores digitales



Computadores eran compartidos por programadores
quienes manipulaban hw y escribían su propio código
para acceso a dispositivos y recopilación de resultados
(ejecuciones exitosas o fallidas)
Posteriormente operador realizada trabajo de cargar y
recopilar info en disposivos correspondientes
Inicios



Inicio de compartición. Bibliotecas y manejadores de
dispositivos
Sistema operativo era una biblioteca que se linkeaba
en un programa. Programa se cargaba completamente
en memoria y se ejecutaba.
Básicamente el sistema operativo era una biblioteca
run-time
Evolución de SOs

Sistemas batch







Sistema operativo estaba almacenado en una porción de
la memoria
Cargaba trabajo a ejecutar a memoria usando un lector de
tarjeta
Ejecutaba trabajo e imprimía resultado, contenido de
memoria y registros para depuración
Cargaba próximo trabajo
Tarjetas de control especificaban al computador que
hacer.
Operadores ordenaban trabajos con requerimientos
similares en grupos (batches) y los ejecutaban
Con este enfoque la CPU pasaba mucho tiempo ociosa
• Diferencias entre dispositivos I/O, mecánicos mucho más
lento que electrónicos
• Gap entre velocidad de CPU y dispositivos siempre muy
grande
Evolución de SOs

Spooling (Simultaneous Peripheral Operation
On-Line)







Con la invensión de Discos más rápidos que lectores
de tarjeta y acceso a dispositivos de salida como
impresoras
Sobreponer lectura/escritura a dispositivos de E/S
mientras se ejecuta proceso en CPU
Spool : buffer que mantiene info de entrada o salida
de un dispositivo
Leer de dispositivos de entrada a disco
Escribir de dispositivos de salida a disco
Usar CPU mientras se lee y escribe a disco
Grupo de trabajos pueden ser leídos a disco
• Sistema operativo elige trabajo a ejecutar
(planificación)

Sin embargo, CPU aun sigue ociosa por mucho
tiempo cuando programa interactua con periférico
Evolución de SOs

Sistemas Multiprogramados

Para aumentar la utilización del sistema

Mantiene varios programas cargados en memoria
simultáneamente
• Protección es importante


Mientras un programa espera por I/O otro puede
estar ejecutándose
beneficios por el uso de dispositivos I/O asincrónicos
• necesita saber cuando el disposito termina
• interrupciones
• polling

Objetivo es optimizar throughput (#trabajos/tiempo)
aunque castiga tiempo de respuesta
Evolución de SOs

Sistemas de Tiempo Compartido

Para soportar uso interactivo
• En un principio un servidor para varios terminales



Cada usuario cree que el sistema esta dedicado a él
Tiempo de respuesta es preferido a throughput
Sistema operativo divide el tiempo de CPU entre los
usuarios
• Procesos se ejecutan por un pequeño periodo de
tiempo o hasta que requieran I/O, entonces el próximo
proceso en la lista entra en ejecución



Usuarios pueden ejecutar procesos interactivos,
como editores, depuradores, etc
Primer sistema: MULTICS ( ~ 1960)
Protección es importante
Sistemas actuales

Sistemas de Escritorio

Maximización de utilización de CPU no es tan
importante como lo es facilidad de uso para el usuario
• Sistemas gráficos (ventanas, menus, etc)



Seguridad es un aspecto importante, sobretodo ahora
que la mayoría de los computadores modernos están
conectados en red
Estaciones de trabajo, son básicamente
computadores para ser usados por usuarios, pero
poseen hw más poderoso, como buenas tarjetas
gráficas y CPUs
Actualmente computadores de escritorio están
incluyendo la tecnología multicore
Sistemas actuales

Sistemas Distribuidos




Sistemas que facilitan el uso de recursos distribuidos
geográficamente
Computadores conectados en red (LAN, WAN)
Soportan comunicación entre trabajos (procesos)
Permite la compartición de recursos (hardware, software)
• balance de carga, autentificación y control de
acceso


Permite algo de paralelismo, pero no es el objetivo principal
Algunos modelos que se usan en el desarrollo de
aplicaciones distribuidas
• Sistemas Peer to Peer
• Servidores y clientes. No hay distinción entre el cliente y el
servidor, ambos actúan como los dos. Se conocen como peers
• Sistemas Cliente/servidor
• Clientes envian requerimientos que servidores procesan y
responden a clientes.
• SO distribuidos
• Proporcionan ilusión que existe un solo SO que controla recursos
distribuidos en red.
Sistemas actuales

Sistemas basados en clusters



Compuestos por dos o más sistemas individuales
acoplados
Definición general : computadores comparten
almacenamiento y están conectados mediante una LAN
con alto ancho de banda
Tipos
• Asimétricos: uno es el principal y otro monitorea principal y
pasa a ser el principal en caso de falla
• Simétricos: dos o más computadores ejecutan las aplicaciones
y se monitorean entre ellas

Sistemas basados en Multiprocesadores



Mejoran productividad, confiabilidad
Comúnmente utilizados en aplicaciones científicas
Computadores paralelos
•
•
•
•
SMPs (Symmetric Multi-Processors)
MPPs (Massively Parallel Processors)
NOWs (Networks Of Workstations)
Grid Computacional
• Incluye clusters y almacemamiento distribuido geográficamente
Sistemas actuales

Sistemas incrustados



CPUs baratas presentes en muchos artículos
Celulares, PDAs, juegos, iPods
Sistemas Handheld


PDAs (Personal Digital Assistants)
Limitados por tamaño
• CPU lenta comparada con PC
• si no requeriría una batería grande
• Pequeña memoria
• La mayoría no implementan memoria virtual


Usan tecnología como BlueTooth e infrarojo para
comunicarse con otros PDAs y PCs
Comunicación inalámbrica ahora también esta accesible
para PDAs
Sistemas actuales

Sistemas de tiempo real


Especialmente diseñados con restricciones de tiempo
importantes
Deben responder a eventos que ocurren con alta precisión
de tiempo
• Sistemas computacionales de emergencia
• Control de tráfico aéreo
• Se agrupan de acuerdo a los requerimientos en tiempos de
respuesta
• Tipos
• Duros: Con restricciones de tiempo importantes. Algunas
características avanzadas de SOs no se encuentran, por ejemplo,
memoria virtual normalmente no es implementada. Se usan en
sistemas de control industrial y robótica.
• Suaves: Menos restrictivo sólo requiere que procesos no esperen
indifinidamente y tengan prioridad sobre otros.
Tendencias en SOs
Mejoras tecnológicas avanzan
rápidamente
 Código de SOs tiende a cambiar
mucho más lentamente que Hardware
 Construcción de sistemas se extiende
mucho más allá que el SO

Citas famosas

“I think there is a world market for maybe
five computers”


“There is no reason for any individual to
have a computer in their home”


Thomas Watson, IBM, 1943
Ken Olson, Digital, 1977
“640K ought to be enough for anybody”

Bill Gates, 1981
Citas famosas
Scientists from RAND Corporation have created this model to illustrate how a
"home computer" could look in the year 2004. However the needed
technology will not be economically feasible for the average home. Also the
scientists readily admit that the computer will require not yet invented
technology to actually work, but 50 years from now scientific progress is
expected to solve these problems. With teletype interface and the Fortran
language, the computer will be easy to use and only
Tendencia en Desempeño de CPU

Desempeño de CPU paró de doblarse cada
18 meses en el 2002
Fuente: David Patterson
Ley de Moore

Continúa mejorando la cantidad de transistores por
chip
Por qué desempeño crece a
menor pendiente?


Según la ley de Moore, es posible conseguir
más transistores por chip
Problema con CPUs




Diseño de chips se está haciendo más
complejo
Tiempos de comunicación se hacen más
importantes
Ruido en los circuitos pasa a ser un factor
importante
Problemas para seguir aumentando la
velocidad del reloj (uso de energía y
disipación de calor)
• Tecnologías multicore permiten aumentar
desempeño a costo de velocidad de reloj
Qué ofrece las empresa ahora?
Qué pasa con la Educación en
Computación?
“Given this sea change, how much of the curriculum
and what fraction of the CS faculty is oblivious to
concurrency? How many algorithms, data structures,
languages, compilers, debuggers, operating
systems, books, and lectures must change to match
the transformation in underlying technology if they
are to remain relevant in the 21st century?”
David Patterson -- Computer Science Education in
the 21st Century
Aparece en Communications of the ACM : Documento completo
aparece en http://www.inf.udec.cl/~chernand/sc/2007-1/links/p27patterson.h
Desafío en computación paralela

Cómo podemos obtener una aceleración de
N en un multiprocesador de N
procesadores?


Software debe ser paralelizable
Métricas para medir aceleración?


Latencia: Tiempo para completar una tarea
(tambien puede referirse a tiempo de
respuesta)
Throghput (productividad): Razón a la cual
tareas son completadas
Un ejemplo de la vida diaria
Problema: Producir cachorros
 Se puede paralelizar el problema?


Latencia : No se puede mejorar
• Cada perrita no puede parir en una
semana
• Latencia 2 meses

Productividad : Si
• 10 perritas pueden producir un cachorro
por mes
• Productividad : 10/mes
Un ejemplo del área

Qué será más importante para una
empresa que vende por internet
Ser capaz de manejar más clientes?
 Hacer que cada transacción se realice
más rápido?

Paralelismo en teoría

Ley de Amdahl: Predice desempeño total
en base a una mejora local.

En una máquina paralela mejora dada por el
número de CPUs
• N : número de procesadores
• F : Factor que no se puede mejorar, en este caso
fracción de computación secuencial
• Que significa F = 0 ???
S=
1
F + (1 - F) / N
Ejemplo: Ley de Amdahl
Programa ocupa el 70% del tiempo ejecutando
código fácilmente paralelizable, y un 30%
en código completamente secuencial (no
paralelizable).
¿Cúal es la aceleración al ejecutar este programa
en un computador paralelo con 2, 3, 4 y 5 CPUs?
¿Cuál es la máxima aceleración posible de
alcanzar a través de paralelismo?
1
S
(1  0.7) 
0.7
N
N
2
3
4
5
inf.
S
1.54
1.85
2.1
2.3
3.3
Evaluación en la práctica

Predecir desempeño es difícil porque
hay muchas formas de paralelismo

Múltiple procesadores
• SMP (Symmetric multiprocessors)
Procesadores multicore
 Procesadores multithreaded
 Clusters


Ejecución de software permite evaluar
experimentalmente
Soporte de la arquitectura para el
Sistema Operativo


En parte el sistema operativo está sujeto a la
arquitectura que lo soporta
 Lista de instrucciones de la CPU (s)
 Controladores como MMU y DMA
Arquitectura construida para soportar SO
 Reloj
 Intrucción Test and Set (para sincronización atómica)
 Protección de memoria
 Operaciones de control I/O
 Interrupciones y excepciones
• Diferencia entre ellas?
Protección en SO

Objetivos



Evitar que sistema se caiga producto de una
aplicación con errores
Evitar que una aplicación/usuario maliciosa(o)
tome el control del sistema (seguridad)
Proteger datos de usuarios de usuarios y
aplicaciones no confiables
Ideas utilizadas en protección



Apropiación: entregar a usuarios y aplicaciones lo que
puede quitar
 Tiempo CPU (uso de reloj de sistema)
Interposición: Llevar cuenta de lo que aplicación está
usando. En cada acceso verificar acceso es legal
 Estructuras de datos usadas en SO para ello
Modo protegido/no protegido
 Aplicaciones usuarios ejecutadas en modo no protegido
 SO ejecutadas en modo protegido
• Operaciones de seguridad sólo permitidas en modo
protegido

Como sabe el procesador que una instrucción protegida
debe ser ejecutada?
• Arquitectura debe soportar modo kernel y modo usuario
Intrucciones Protegidas

Algunas instrucciones son de uso exclusivo del
SO


Directamente accesar dispositivos I/O (discos,
tarjetas de red)
Manipulación de administración de memoria
• punteros a tablas de página, carga a TLBs, etc

Manipulación de bits de modo
• nivel de interrupción de prioridades

Cruce de modo usuario a kernel


Código usuario debe llamar un procedimiento del SO
SO define una secuencia de llamados a sistema
Arquitectura y SO

Frontera entre aplicaciones usuario y sistema
(kernel)


Permite a SO ejecutar instrucciones protegidas
Aplicaciones entran a modo kernel ejecutando
llamadas a sistema
Llamadas a sistema

Transición de modo usuario a modo kernel

Hay una intrucción de llamado a sistema que
• Causa una excepción (a través de una interrupción
software) que direcciona a un handler del kernel
• Pasa un parámetro indicando el llamado a sistema que
debe invocar
• Guarda el estado del que llama (caller) (registros, bit de
modo) para ser restaurados al terminar
• SO verifica los parámetros (punteros) del que llama
(caller)
• Debe retornar al modo usuario cuando termine
Ilustración de la transición de modo
usuario a kernel
Applicación
usuario (llamado a sistema req)
Modo usuario
Modo kernel
Llamado
a sistema
Almacena
estado app
Manejador
llamadas sistema
Ejecuta
Llamada
sistema
Restablece
estado app,
retorna modo
usuario
continua
ejecución
Preguntas




Qué pasaría si el SO no salvara el estado de
las aplicaciones antes de ejecutar un llamado a
sistema?
Por qué el sistema debe verificar parámetros
en los llamados a sistema?
Qué pasaría si una aplicación de usuario
modificara el vector de interrupciones del
sistema?
Cómo el sistema evita que una aplicación lea
directamente del disco en lugar de pasar por
las verificaciones de control de acceso del
sistema de archivos?
Protección de Memoria

Problema1. SO debe protejer programas unos
de otros.

Programas de diferentes usuarios. Malintencionados
o no.
• Solución: Memoria Virtual, donde cada aplicación tiene
su propio espacio de direccionamiento, el cual se
mapea a memoria física a medida que la aplicación lo
requiera

Problema2. Kernel debe proteger sus
programas y datos

Solución: Dividir el espacio de direccionamiento en
la mitad
• La que corresponde al kernel requiere modo de
acceso priviligiado

TLBs y registro para puntero a tabla de páginas
proporcionados por HW
Espacio de direccionamiento
en linux
Operación de SO

Sistema computacional compuesto por CPU y
controladores de dispositivos incluyendo memoria.



Antes de SO. Programa inicial para empezar
(bootstrap program) (en ROM).
Inicializa todos los aspectos del sistema, Registros de
CPU, controladores de dispositivos, contenido de
memoria
 Debe cargar SO en memoria para ejecutarlo.
SO empieza ejecución con algún programa como init
(Unix) y luego espera por la ocurrencia de eventos.


Cada tipo de dispositivo tiene asociado un
controlador.
Controladores funcionan en base a eventos.
Operación de SO


Una vez que el kernel esta en ejecución cualquier
entrada al kernel ocurre mediante un evento.
 Eventos detienen ejecución actual
 cambia modo a modo kernel. SO llama a manejador de
eventos
Kernel define manejadores para cada tipo de evento
 La arquitectura define los tipos (ejemplos, reloj,
interrupciones I/O)
 Cuando el procesador recibe un evento de un tipo
•
•
•
•
transfiere el control al manejador de eventos en el SO
manejador salva estado de proceso actual
manejador llama a la rutina que atiende evento
manejador restaura estado del proceso
Interrupciones y Excepciones

Eventos en el sistema ocurren a través de
interrupciones y excepciones
 Excepciones. Causadas por ejecución de
intrucciones de SW
• x86 assembly: instrucción “int”
• falta de página: intento de escribir en una página
con permisos de lectura solamente

Interrupciones. Causadas por dispositivos HW
• reloj (ha pasado el tiempo programado)
• dispositivo termina con I/O (click on mouse, o
termino copia de bloque a disco, etc)
• llega un paquete de red
Estructura I/O

Secuencia en una operación de I/O
 SO ejecuta intrucciones especiales de I/O o I/O
mapeada a memoria
 CPU carga datos en registros de controlador de
dispositivo
 Controlador de dispositivo examina datos y determina
que acción tomar
 2 posibilidades de acción una vez que empieza I/O
• sincrónica (espera término I/O)
• asincrónica (control transferido a proceso de usuario
mientras I/O termina)

I/O asincrónica (más eficiente uso de recursos)
• dispositivo realiza una operación asincrónica a la CPU
Estructura I/O



Dispositivo envía una interrupción a
través del bus cuando termina
En memoria hay una tabla que contiene
la lista de direcciones de kernel de
rutinas para manejar varios tipos de
interrupciones
CPU se cambia a la dirección indicada
por el vector mediante la señal de
interrupción
Relojes

Como controla el SO que un proceso se acapare
la CPU?
 Reloj que genera una interrupción
periódicamente
 Antes de ejecutar un proceso, el SO carga el
reloj con un tiempo para que luego de expirado
se genere una interrupción (quantum)
 Cuando el quantum expira el control es
transferido al SO para la ejecución del siguiente
proceso (planificación de procesos)
Sincronización


Interrupciones pueden ocurrir en cualquier momento
 proceso a ejecutarse puede interferir con proceso que
esta siendo ejecutado
 SO debe poder sincronizar procesos concurrentes
sanamente
Sincronización
 debe permitir la ejecución de set de instrucciones que
lean-modifiquen-escriban atomicamente (sin ser
interrumpida)
 una forma: desabilitando interrumpciones (arquitectura
debe soportarlo). No aceptable en un sistema
multiprocesador
 otra forma: teniendo una intrucción atómica special que
conste de estas tres operaciones (test-and-set)
Preguntas




Qué pasaría si el SO no salvara el estado de
las aplicaciones antes de ejecutar un llamado a
sistema?
Por qué el sistema debe verificar parámetros
en los llamados a sistema?
Qué pasaría si una aplicación de usuario
modificara el vector de interrupciones del
sistema?
Cómo el sistema evita que una aplicación lea
directamente del disco en lugar de pasar por
las verificaciones de control de acceso del
sistema de archivos?