Llamadas al sistema (3), Estructura de SO

Dr. Alonso Ramírez Manzanares31-Ago-2010

Llamadas al SO de administración de directorios.

La instrucción mount, por ejemplo para montar una unidad de disco

mount(“/dev/fd0”,”/mnt,”0);

Tambien se pueden monar así discos duros o particiones de discos duros. Cuando se deja de utilizar se puede usar UMOUNT.

Llamadas al SO de administración de directorios.

Minix tiene un caché en la memoria pricipal donde almacena los bloques mas usados, evitando con esto leer cada vez.

Si se modifica un bloque y el sistema se cae antes de actualizar el HD (un apagón por ejemplo) el sistema de archivos se dañará.

Se debe de desalojar el caché periodicamente.

La llamada al SO SYNC hace lo anterior. Cuando se inicia Minix se ejecuta update en segundo plano, el cual desaloja el cache cada 30 segs.

Llamadas al SO de administración de directorios.

Tenemos también:

CHDIR, que cambia el directorio actual.

CHROOT que cambia el directorio raiz, es decir desde donde se referencia “/”. Esto solo lo puede hacer el superusuario.

Llamadas al SO para proteccion

Tenemos chmod(“archivo”,0644);

Pero ademas de los 9 bits anteriores tenemos 2 mas: 02000 y 04000, que son SETGID y SETUID (permitir poner id “efectivo” de grupo y de usuario, respectivamente). Esto no cambia para nada el id “real”.

Cuando SETUID esta activado y el ID efectivo se cambia de el del usuario al del propietario del archivo durante la ejecución del proceso.

Esto se usa para permitir que usuarios ejecuten procesos de SU, por ejemplo, crear directorios, es decir MKDIR (de SU con prop. 04755) llama internamente a MKNOD en forma restringida.

Llamadas al SO para proteccion

Se puede investigar cual el el ID efectivo y real de un proceso con:

GETUID, GETEUID, GETGID y GETEGID, que regresan id reales y efectivos.

Los usuarios no pueden cambiar su uid, excepto cuando ejecutan programas con el bit SETUID activado, pero el SU si puede usando:

int setuid(uid_t uid);

Que pone tanto el uid real como efectivo.

Llamadas al SO para proteccion

El superusuario puede cambiar el propietario de un archivo con CHOWN.

Usuarios standard pueden llamar umask(022) que enmascará las futuras creaciones de archivos y directorios, asi, la llamada creat(“f.dat”,0777) realmente asignará 0755 a las propiedades de acceso.

Llamadas al SO para proteccion

Es posible verificar si se puede accesar un determinado archivo por un uid “real” con la llamada al sistema ACCESS (qué pasa si probamos abrirlo y el programa es de SU con SETUID prendido? Pues no obtenemos información).

El parámetro MODE puede verificar lectura(4), escritura(2) y ejecución(1).

Llamadas al SO para administracion del tiempo

TIME, develve el número de segundos desde 1970

STIME, permite al SU poner la hora.

UTIME, permite al propietario cambiar el tiempo almacenado en el i-node de un archivo (es la que usa TOUCH).

y TIMES, que permite contabilizar el tiempo de CPU de un proceso.

Estructura del SO

Estructura del SO

Los 4 diseños más importantes son:

sistemas monolíticos

sistemas por capas

máquinas virtuales

sistemas cliente-servidor

Sistemas monolíticosEs un esquema desordenado.

Es una colección de procedimentos donde cualquiera puede llamar a cualquiera (se debe proveer una definición de interfaz con parámetros y resultados).

No hay ocultación de información.

Los servicios se solicitan colocando los parámetros en lugares definidos (registros) y haciendo una “llamada al kernel” (conocida como captura, trampa o trap), la cual conmuta del modo de usuario al modo de kernel dando el control al SO.

Sistemas monolíticos

- Luego el SO examina parámetros para determinar que llamada se ejecutará.- Después busca en la tabla de procedimientos y lo ejecuta.- Finalmente se devuelve el control al usuario.

Sistemas monolíticosLa organización anterior sugiere:

Aqui se hacen las llamads al

SO

Entonces, para cada llamada al SO hay un procedimiento de servicio.

Sistemas por capasGeneralizando la estructura anterior, se puede diseñar una jerarquía por capas:

SO THE (1968)

Sistemas por capas

CAPA 0: reparto del procesador, conmutando cuando ocurrian interrupciones o expiraban temporizadores, es decir todo lo de multi-programación. Arriba de la capa 0 el sistema consiste en procesos secuenciales.

CAPA 1: Administra la memoria, mas arriba de la capa 1, no se necesita saber en que parte de la memoria se estaba corriendo.

Sistemas por capas

CAPA 2: Maneja la comunicación entre cada proceso y la consola del operador. Por encima de esta capa, cada proceso tenia su propia consola de operador.

CAPA 3: Encargada de administrar los dispositivos de E/S y de colocar en buffers las corrientes de información. Arriba de la capa 3 cada proceso cuenta con dispositivos de E/S abstractos (amigables).

Sistemas por capas

CAPA 4: Aqui se encuentran los programas de usuario que no se tienen que preocupar de todo lo que se provee abajo.

CAPA 5: Aqui se encuentra el proceso del operador del sistema (que ejecuta programas de usuario).

Sistemas por capas

El sistema por capas evolucionó a sistema de anillos en MULTICS, donde los anillos externos hacen llamadas al sistema para obtener servicios de anillos internos.

En MULTICS el hardware permitía desinar segmentos de memoria como protegidos contra lectura, escritura o ejecución (memoria donde se tenían procesos).

Máquinas Virtuales

El sistema VM/370 se basa en proveer a) multi-programación y b) una máquina extendida con una interfaz más cómoda que el hardware tal cual. Donde se separan esas dos funciones.

El “monitor de máquina virtual” proporciona varias máquinas virtuales, pero no daban una máquina “extendida:, sino que proporciona copias exactas del hardware tal cual, con modo kernel/usuario, E/S, interrupciones, etc.

Máquinas Virtuales

Como cada máquina es idéntica al hardware, puede ejecutar cualquier SO. Muchas veces se ejecutaba CMS (Sistema de Monitoreo de Conversaciones).

De esta manera se separó multiprogramacion y máquina extendida.

Este concepto se usó luego en Windows para simular MS-DOS (pero en una máquina inferior, no idéntica).

Modelo cliente-servidorLa idea anterior de mandar código a capas superiores simplificando el kernel se lleva mas allá implementando la mayor parte de de las funciones del SO en procesos de usuario (ahora llamados proceso cliente):

Entonce el kernel maneja la comunicación entre clientes y servidores.

Modelo cliente-servidorEl hecho de que los servidores se ejecuten en modo usuario, hace que si se cae un servidor, no se cae la máquina completa.

La otra ventaja es su adaptabilidad a sistemas distribuidos.

Modelo cliente-servidor

En la realidad

algunos procesos de servidor críticos (por ejemplo los controladores de disp. E/S) se ejecutan realmente en modo de kernel, pero usando el mecanismo de mensajes normal.

Procesos

PROCESOSTodo gira alrededor de los procesos, por eso es imporante entenderlos a detalle.

Todas las computadoras actuales hacen muchas tareas “al mismo tiempo”.

En un instante dado el CPU solo ejecuta un programa, de ahi el concepo de “pseudo paralelismo”, a diferencia del esquema de multiprocesamiento.

Todo el software (a veces inculido el SO) esta organizado en procesos secuenciales.

ProcesosEl proceso no es mas que un programa en ejecución que incluye los valores actuales de contador de programa, registros y las variables.

Con este esquema, el tiempo de ejecución de un proceso no es necesariamente uniforme ni reproducible.

Procesos

Cuál es la diferencia entre un programa (un algoritmo) y un proceso (una actividad).

Entonces el proceso tiene: programa, entrada, salida y un estado.

Y por lo tanto, el procesador se puede compartir entre varios procesos no necesariamente finiquitados.

Jerarquía de ProcesosEn la mayoria de los SO, se necesita crear nuevos procesos y destruir procesos. En MINIX se usa FORK.

Todos los procesos tienen padre, y de cero a n hijos.

En MINIX el proceso especial INIT esta presente en la imagen de arranque. INIT lee cuantas terminales hay y bifurca un proceso por c/u de ellas lanzando login. Si login tiene exito crea un proceso shell, donde los comandos pueden crear nuevos procesos.

Por lo tanto todos los procesos pertenecen al mismo arbol con init en su raiz.

Estados de procesos

Aunque los procesos son entidades independientes, se comunican entre si, ejemplo:

cat a1 a2 a3 | grep alonso

donde GREP se debe de auto-bloquear hasta que le lleguen datos de CAT.

Tambien un proceso que esta listo se puede bloquear porque el SO ha decidido asignar el CPU a otro proceso.

Estados de procesosPor lo tanto tenemos 3 estados con las siguientes transiciones:

En este modelo de transiciones, las interrupciones juegan un papel primordial.

Estados de procesosLo anterior da lugar al siguiente modelo, capa baja es el planificador (interrupciones, inicio, parada y comunicación de procesos) con una serie de procesos arriba de él.

Implementación de procesosSe mantiene una tabla de procesos con una entrada por cada proceso:

Con lo cual tenemos toda la información para poder hacer la conmutación.

¿Cómo funciona el planificador?

Cada clase de disp. E/S tiene un vector de iterrupción que contiene la dirección del procedimiento de servicio de interrupción.

Al dispararse una interrupción, el hardware de interrupciones mete el contador de programa, la palabra de estado de programa y registros en la pila actual.

Luego, la computadora salta a la dirección especificada en el vector de interrupciones.

¿Cómo funciona el planificador?

Lo primero que hace el procedimiento de servicio es guardar todo lo del proceso actual (en la tabla). El proceso actual se almacena en variables globales para acceso rápido. Continuara ...