PDF de programación - Ingeniería del Conocimiento

Diseño de Sistemas Operativos

Curso: 2001/2002
Cuatrimestre: Primero
Alumna: Laura M. Castro Souto
Profesor: Ramón Pérez Otero

Índice general

1. Introducción

7

2. El buffer caché

9
9
2.1. Tarea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1. Algoritmo bread() . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.1.2. Algoritmo breada() . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.3. Algoritmo getblk() . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.4. Algoritmo bwrite() . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.5. Algoritmo brelse() . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2. Peculiaridades de BSD frente a UNIX . . . . . . . . . . . . . . . . . . . . . 14
2.2.1. Mejoras que introduce BSD . . . . . . . . . . . . . . . . . . . . . . 14
2.3. Ventajas e inconvenientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3. El sistema de ficheros

3.2.

17
3.1. Representación interna de los ficheros . . . . . . . . . . . . . . . . . . . . . 18
3.1.1. El tamaño importa: ¿grande o pequeño? . . . . . . . . . . . . . . . 20
3.1.2. Algoritmo bmap() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.3. Algoritmo namei() . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Inode caché . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1. Algoritmo iget() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2. Algoritmo iput() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3. Asignación de espacio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.1. Asignación de bloques: algoritmos alloc() y free() . . . . . . . . 24
3.3.2. Asignación de inodos: algoritmos ialloc() e ifree() . . . . . . . . 24
. . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.1. Llamada open() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.2. Llamada close() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.3. Llamada read() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.4. Llamada write() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.5. Llamada lseek() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.6. Llamada cd() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.7. Llamada mknod() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.8. Llamada link() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.9. Llamada unlink() . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.10. Llamada mount() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.4. Llamadas al sistema de ficheros

3

4

ÍNDICE GENERAL

3.5. Otras organizaciones de sistemas de ficheros

3.4.11. Llamada umount() . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
. . . . . . . . . . . . . . . . . 38
3.5.1. Sistemas de Ficheros de Bases de Datos . . . . . . . . . . . . . . . . 38

4. Device Drivers

39
4.1. Librerías dinámicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2. Device drivers para el usuario . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3. Device drivers especiales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.1. Device drivers de disco . . . . . . . . . . . . . . . . . . . . . . . . . 45
. . . . . . . . . . . . . . . . . . . . . . . 46
4.3.2. Device drivers de terminal

5. Procesos

51
5.1. Funciones básicas de procesos y memoria . . . . . . . . . . . . . . . . . . . 53
5.1.1. Mecanismo de llamada al sistema: syscall() . . . . . . . . . . . . 53
5.1.2. Mecanismo de atención de interrupciones: inthand() . . . . . . . . 56
5.1.3. Mecanismo de cambio de contexto: cntswt() . . . . . . . . . . . . 57

Apéndices

58

A. Prácticas

59
A.1. Estructura de directorios de UNIX . . . . . . . . . . . . . . . . . . . . . . 59
A.1.1. Enunciado de la primera práctica . . . . . . . . . . . . . . . . . . . 60
A.1.2. Enunciado de la segunda práctica . . . . . . . . . . . . . . . . . . . 60
A.2. Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.2.1. Creación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.2.2. Características
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.2.3. Enunciado de la tercera práctica . . . . . . . . . . . . . . . . . . . . 61
A.3. Curiosidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.3.1. S.O. basados en disco: arranque configurable . . . . . . . . . . . . . 62

6

ÍNDICE GENERAL

Capítulo 1

Introducción

Un sistema operativo es un programa cuya principal finalidad es hacer que la ejecu-
ción del resto de programas sea independiente del hardware. Para conseguirlo, utiliza dos
conceptos básicos: el concepto de fichero y el concepto de proceso; trata cualquier tipo de
dispositivo igual que si fuese un fichero, salvo dos excepciones: la CPU y la memoria, con
los que emplea el concepto de proceso.

En cuanto a la arquitectura, las dos características principales son:

Las llamadas al sistema.

El kernel no tiene procesos asociados.

Los sistemas operativos han ido evolucionando:
→ Se empezó “incluyendo” el SO1 en la aplicación, esto es, eran las propias aplicaciones

las que accedían directamente al hardware.

→ Más tarde se crea una aplicación que es la única que interactúa con el hardware.
El resto de aplicaciones trabajan sobre ella. Ello hace necesaria la presencia de una
interfaz. El código del SO debe hacer lo que necesita la aplicación del usuario. Para
ello, en teoría, la aplicación debe llamar a las funciones del SO, incluyéndolas, pues,
en su código. Esto implicaría varias copias del SO.

→ Se dieron dos soluciones a la duplicación del código del SO:

→ Existencia de un proceso independiente del resto para el kernel; los otros proce-
sos se comunican con él pidiéndole la ejecución de funciones. Ejemplo: antiguo
SO de IBM.

→ El propio kernel es un trozo único de código que se une a todos los programas.
La llamada a funciones del kernel es más compleja, pues hay que acceder a una
zona de código que no pertenece al proceso. Ejemplo: UNIX (arquitectura con
la que nos quedamos).

1Abreviaremos así sistema operativo.

7

8

CAPÍTULO 1. INTRODUCCI ÓN

La arquitectura UNIX, que estudiaremos, presenta las siguientes propiedades:

1. El SO es un programa que no acaba. Puede llamarse a cualquiera de sus funciones,

aunque no a todas: a un grupo de ellas denominadas llamadas al sistema.

2. El kernel puede ser llamado por varios procesos a la vez. Se utilizan semáforos o

bien modo exclusivo para regularlo.

El código del SO también está dividido en ficheros y procesos. El código se organiza

desde el nivel hardware hasta el nivel del usuario:

Figura 1.1: Organización de la interfaz usuario-hardware (sistema operativo).

Las zonas más cercanas al hardware llaman a controladores, que sí son ya, obviamente,

dependientes de aquél. El resto del kernel es independiente.

Capítulo 2

El buffer caché

El buffer caché es una estructura software del sistema operativo formada por una
serie de buffers organizados en colas hash (para agilizar su acceso) y enlazados en una
lista de buffers libres o free list en la que se mantiene un orden de reemplazo LRU.

Todo buffer está siempre en una cola hash, y puede o no estar en la free list.

2.1. Tarea

La tarea del buffer caché es bastante concreta. Su presencia se debe a que el disco es
mucho más lento que la memoria; para paliar esto, lo que hace es guardar los datos que
ha leído del disco en un buffer, cuya velocidad de acceso es mucho mayor.

Estudiaremos las funciones del kernel y las llamadas al sistema que implementan las

operaciones necesarias (ver figura 2.1).

Figura 2.1: Funciones del buffer caché.

2.1.1. Algoritmo bread()

La función bread() es la función a la que llama el sistema como consecuencia de
cualquier operación/instrucción en cualquier aplicación o programa que produzca como
resultado la demanda de una lectura de datos. Su esquema es el que se expone en la tabla
2.1.1, página 10.

9

10

CAPÍTULO 2. EL BUFFER CACH É

entrada: identificación de un bloque
salida: buffer ocupado con los datos del bloque
{

obtener buffer -getblk()-;
if (datos validos)
return (buffer);

iniciar lectura en disco;
sleep (hasta que termine la lectura);
marcar datos como válidos;
return (buffer);

}

Cuadro 2.1: Algoritmo bread().

2.1.2. Algoritmo breada()

El algoritmo breada() (tabla 2.1.2, página 11), también llamado de lectura anti-
cipada (bread ahead) es una ampliación al algoritmo bread() que además de leer el
bloque solicitado, ordena la lectura asíncrona de otro bloque más, normalmente, el blo-
que siguiente. La razón de esto es la gran probabilidad que existe de que un proceso
que necesita leer un bloque necesite más tarde leer el que le sigue1 –localidad de datos,
secuencialidad de programas–.

2.1.3. Algoritmo getblk()

La función getblk(), que hemos visto referenciada en el código anterior, se describe

en la tabla 2.1.3, página 12.

La existencia del flag ocupado es necesario, independientemente de que tengamos
la lista de libres, porque aunque un bloque estará en la lista de libres si y sólo si no
está ocupado, ésta nos sirve para mantener un orden LRU a la hora de seleccionar un
bloque para ser utilizado (para traer datos de un bloque en disco que no se encuentre en
cache y cuya lectura haya sido demandada).

2.1.4. Algoritmo bwrite()

De acuerdo con la política de eficiencia que venimos estudiando, las escrituras a disco
sólo se realizan cuando es estrictamente necesario. Esto evitará muchas veces que escriba-
mos a disco bloques de buffers que aún van a ser modificados más veces, aunque también
es la razón de por qué los apagados no ordenados de las máquinas pueden dañar los
sistemas de ficheros.

1No nos referimos al bl