El sistema operativo OSO

Transcripción

1 El sistema operativo OSO Departamento de Ingeniería y Tecnología de Computadores Universidad de Murcia 25 de abril de 2005 Índice 1. Introducción 2 2. Estructura del sistema 3 3. Ejecución del sistema operativo Iniciación del sistema operativo Puntos de entrada al sistema operativo Gestión de procesos y de memoria La tabla de procesos Estado de un proceso Contexto de un proceso Gestión de procesos Creación de procesos Planificación de procesos Apropiación de la CPU Gestión de memoria Sistema de ficheros Gestión de los dispositivos de almacenamiento Gestión del sistema de ficheros Gestión de la E/S Lectura de un dispositivo de almacenamiento Salida por pantalla Entrada por teclado Llamadas al sistema Sincronización de procesos dentro del núcleo La llamada sys_crear_proceso La llamada sys_escribir La llamada sys_leer Funciones auxiliares 31 1

2 1. Introducción Este documento describe la estructura, diseño e implementación del sistema operativo OSO. OSO es un sistema operativo monolítico muy pequeño con el que se pretende mostrar, de manera práctica, algunos de los conceptos fundamentales de los sistemas operativos actuales, en especial, el concepto de multitarea. Entre los objetivos que han guiado el diseño de este sistema operativo podemos destacar los siguientes: El sistema operativo debe ser lo más pequeño posible. Por este motivo OSO sólo implementa tres llamadas al sistema básicas como son: la creación de procesos, la lectura de teclado y la salida por pantalla. La implementación de estas llamadas al sistema también será un aspecto importante ya que muestran cómo el sistema operativo ofrece sus servicios a los procesos de usuario. El sistema operativo debe ser multitarea. La multitarea es uno de los conceptos más importantes y es fundamental entender su funcionamiento. En concreto, se pretende mostrar el funcionamiento del cambio de contexto, el bloqueo/desbloqueo de procesos y la planificación de los mismos. El sistema operativo debe hacer una gestión básica de la memoria. En el caso de OSO la gestión de la memoria la vamos a basar en particiones estáticas de igual tamaño. El sistema operativo debe gestionar algún tipo de sistema de ficheros. La importancia de ver en detalle el funcionamiento de los sistemas de ficheros es que en ellos se almacenan el código y los datos de los distintos programas que ejecuta el sistema operativo. Este objetivo también implica el uso de algún tipo de dispositivo de almacenamiento. Para simplificar estos dos objetivos de diseño se usa el disquete como dispositivo de almacenamiento y FAT12 como sistema de ficheros. Por último, el sistema operativo debe ser interactivo. Esta característica facilita mucho el uso del sistema operativo al permitir al usuario controlar el funcionamiento del mismo. Este objetivo se va a conseguir mediante la entrada de información por teclado y la salida de información por pantalla, lo que supone una gestión básica de la E/S por parte del sistema operativo. Esta gestión de la E/S nos va a permitir, además, mostrar de forma natural uno de los aspectos fundamentales de la gestión de procesos como es el bloqueo de un proceso y su desbloqueo posterior. En cuanto a la implementación son también varios los objetivos que hemos tenido en cuenta. Algunos de ellos son los siguientes: La implementación debe centrarse en el sistema operativo y no en el hardware. Para cumplir este objetivo se utiliza el «modo real» de los procesadores actuales de Intel y compatibles. Este modo ofrece una visión del hardware muy sencilla, aunque tiene como principal problema el que no ofrece ningún mecanismo de protección hardware al sistema operativo. La implementación debe hacerse en un lenguaje de alto nivel. En el caso de OSO, el lenguaje utilizado es C. El lenguaje ensamblador también se utiliza pero sólo en aquellos casos en los que es realmente necesario (como es la implementación del cambio de contexto). Un aspecto importante es entender cómo se relaciona el lenguaje de alto nivel con el lenguaje ensamblador. En el caso de C esta relación es mucho más directa que la proporcionada por otros lenguajes de alto nivel como Pascal o C++, lo que justifica el uso de este lenguaje. El entorno de programación debe ser lo más sencillo y cómodo posible. Este objetivo se consigue de varias maneras, principalmente, utilizando el disquete como dispositivo de almacenamiento y FAT12 como sistema de ficheros, al igual que hace el sistema operativo OSO. Al utilizar un sistema de ficheros real se puede modificar su contenido fácilmente mediante las utilidades que existen en los sistemas operativos actuales (como Windows y Linux). Así, podremos cambiar de manera sencilla el núcleo del sistema operativo cuando lo modifiquemos y los programa a ejecutar en él. 2

3 En las siguientes secciones vamos a describir cómo se han conseguido estos objetivos. En primer lugar describiremos la estructura general del sistema operativo. Después veremos cómo se han implementado cada uno de sus distintos componentes. 2. Estructura del sistema La figura 1 describe la estructura general del sistema en el que se ejecuta el sistema operativo OSO. Crear proceso Escribir en pantalla Leer de teclado Espacio de usuario Llamadas al sistema Núcleo del sistema operativo Espacio del núcleo BIOS Hardware de teclado PIC Hardware Figura 1: Estructura general de OSO Como podemos observar, la interfaz de llamadas al sistema sólo proporciona tres servicios básicos a los programas de usuario: la creación de procesos, la lectura de caracteres de teclado y la salida por pantalla de cadenas de caracteres. Para implementar las tres llamadas al sistema, OSO necesita acceder al hardware. Esto no siempre es así, es decir, podría haber llamadas al sistema que no necesitaran acceder al final al hardware. OSO accede al hardware, bien directamente, bien indirectamente a través de la BIOS. Aunque el sistema operativo puede omitir la BIOS y acceder directamente a cualquier dispositivo hardware, en el caso de OSO se ha optado por hacer uso de algunos servicios de la BIOS en aras de simplificar la implementación del sistema operativo. No obstante, es importante saber que los sistemas operativos actuales rara vez hacen uso de la BIOS ya que ésta presenta algunos problemas para el sistema operativo (no es reentrante, habilita las interrupciones, etc.). Como muestra la figura, OSO hace uso de la BIOS para leer de disco y escribir en pantalla, y accede directamente al hardware para leer de teclado y para indicar al PIC (Programmable Interrupt Controller) que una interrupción ha sido tratada. De las distintas interrupciones existentes, OSO sólo va a controlar dos: la del reloj (o timer) y la del teclado. La interrupción de reloj se va a utilizar para implementar la multitarea. Así, se le va a poder quitar la CPU a un proceso cuando éste lleve demasiado tiempo en ella. La interrupción del teclado, por su parte, se va a utilizar para desbloquear a aquellos procesos bloqueados que esperan un carácter de teclado. 3

4 Las llamadas al sistema se solicitan con una interrupción software (ejecución de la instrucción de salto int 22h). Esta interrupción software y las dos interrupciones hardware (la de reloj y la de teclado, ambas iniciadas por la activación eléctrica de cables) constituyen los tres únicos puntos de entrada al sistema operativo, es decir, estas tres interrupciones son las que hacen que el procesador deje de ejecutar código de los procesos de usuario para ejecutar código del sistema operativo. Un aspecto a tener en cuenta es que OSO se ejecuta en el modo real de los procesadores de Intel y compatibles. Ya que este modo no ofrece ningún tipo de protección, los procesos de usuario podrán acceder directamente al hardware sin que el sistema operativo lo pueda evitar. También podrán acceder directamente a la memoria de otros procesos o a la del propio sistema operativo e interferir en su ejecución. 3. Ejecución del sistema operativo En esta sección vamos a describir primero qué pasos realiza el sistema operativo cuando comienza a ejecutarse y después veremos los tres puntos de entrada al sistema operativo una vez iniciado el mismo Iniciación del sistema operativo El siguiente fichero fuente, kernel.c, contiene la función main del sistema operativo OSO, es decir, describe lo que hace el sistema operativo cuando comienza su ejecución: #include "string.h" #include "fat.h" #include "procesos.h" #include "sais.h" #include "kernel.h" 5 /* El sistema operativo ejecuta indefinidamente el procedimiento idle * mientras espera la llegada de peticiones de servicio y mientras no * haya otros procesos listos para ejecutarse.*/ static char molinillo[ ] =, /, -, \\ ; 10 void idle(void) long int i; 15 unsigned char j; unsigned char far *pantalla = (char far *)0xb ; j=0; for(;;) 20 for (i = 0; i < ; i++) ; pantalla[0] = molinillo[j]; j = (j + 1) % 4; 25 struct dispositivo * disquete = NULL; void main(void) kputs("inicializando la tabla de dispositivos\n\r"); inicializar tabla dispositivos(); kputs("inicializando la tabla de procesos\n\r"); inicializar tabla procesos();

5 kputs("creando proceso 0 (idle)\n\r"); crearproceso0(); 40 disquete = abrir dispositivo(0); kputs("estableciendo SAIs\n\r"); establecersai(sai timer, 0x08); 45 establecersai(sai teclado, 0x09); establecersai(sai llamadas, 0x22); kputs("cargando programa SHELL.COM... "); if (crearproceso(disquete, "SHELL.COM") < 0) 50 kputs("fallo\n\r"); else kputs("correcto\n\r"); kputs("sistema operativo cargado\n\r"); 55 idle(); /* $Id: kernel.c,v /04/12 17:12:56 piernas Exp $ */ 60 Lo primero que hace el sistema operativo es inicializar algunas estructuras de datos internas para que tengan valores conocidos. Estas estructuras son: la tabla de dispositivos de almacenamiento, configurada por la función inicializar_tabla_dispositivos, y la tabla de procesos, configurada por la función inicializar_tabla_procesos. El siguiente paso es crear el proceso 0 mediante la función crearproceso0. El «proceso 0» va a ser el flujo inicial de la función main de nuestro sistema operativo y es, por tanto, un proceso especial. Este proceso se ejecuta sólo cuando no hay ningún otro proceso listo. En nuestro caso el proceso 0 va a estar ejecutando indefinidamente el código de la función idle a la que se salta al final de la función main. La implementación de la función idle se encuentra justo antes de la función main. Lo único que hace esta función es ejecutar un bucle infinito que dibuja un «molinillo» en la esquina superior izquierda de la pantalla. El molinillo se construye mostrando repetidamente y de forma indefinida la secuencia de caracteres «, /, -, \». Ya que el dispositivo de almacenamiento principal de OSO es el disquete, lo siguiente que se hace, tras crear el proceso 0, es abrir dicho dispositivo de almacenamiento mediante la función abrir_dispositivo. La primera unidad de disquetes se identifica con el número 0 y ése es el número que se pasa como parámetro a la función. El valor devuelto por la función abrir_dispositivo se almacena en la variable disquete y es un puntero a una estructura de datos que contiene información sobre el sistema de ficheros FAT del disquete. Esta información se utilizará cuando se quiera acceder al disquete para, por ejemplo, cargar un programa. Lo siguiente que hace el sistema operativo es establecer los tres puntos de entrada al mismo. Estos tres puntos de entrada ya los hemos descrito en la sección 2 anterior y son: llamadas al sistema (que se solicitan mediante una interrupción software), interrupción de reloj e interrupción de teclado. Para establecer un punto de entrada lo que se hace es modificar un vector de interrupción con la dirección de inicio de la «subrutina de atención a interrupción» (SAI ) correspondiente. La interrupción de reloj tiene asociado el vector 8, la de teclado el vector 9 y la instrucción int 22h el vector 22h. Las subrutinas que se afilian, mediante la función establecersai, con cada uno de estos vectores son, respectivamente, sai_timer, sai_teclado y sai_llamadas, y se describirán en detalle más tarde. Lo último que hace el sistema operativo es crear, mediante la función crearproceso, el primer proceso que se ejecutará en el «espacio de usuario». En este caso se trata del programa SHELL.COM que desempeña un papel similar al del proceso init de los sistemas Unix. El programa SHELL.COM es un pequeño intérprete de órdenes que ejecuta cualquier programa cuyo nombre se introduce por teclado. Puede ver más información sobre este programa en el documento titulado «Desarrollo de aplicaciones en el sistema operativo OSO». 5

6 Cuando llegamos a este punto, el sistema operativo ya ha terminado de iniciar todos los componentes del sistema. Lo último que hace es saltar a la función idle cuyo código se ejecutará indefinidamente como un proceso más (el «proceso 0» que hemos comentado antes). El núcleo del sistema operativo es un ejecutable COM que necesita un fichero c0t especial para compilarse. A continuación mostramos dicho fichero que se llama c0t_krnl.asm en nuestro caso: model tiny.code EXTRN main:near.startup call main 5 END ; $Id: c0t krnl.asm,v /04/12 16:31:17 piernas Exp $ El fichero c0t_krnl.asm lo único que contiene es una llamada a la función main que acabamos de describir. No obstante, es importante darse cuenta de que el sistema operativo necesita un entorno adecuado para su ejecución. Como podemos ver, dicho entorno no se establece dentro de este fichero (aunque se podría hacer). Nosotros hemos optado por que sea el programa cargador el que establezca el entorno de ejecución adecuado del sistema operativo antes de cederle el control de la CPU. Finalmente, mostramos el contenido del fichero cabecera kernel.h en el que únicamente podemos destacar la declaración de la variable disquete como variable externa, ya que será utilizada en otros módulos del programa. #ifndef #define KERNEL H KERNEL H /* Las siguientes tres constantes se definen y usan en el cargador. Aquí se * muestran a título informativo */ 5 /* Zona de memoria ocupada por el sistema operativo. La memoria libre empieza a partir de 1000:0000 */ #define INICIO SO ((char far *)0x ) #define FIN SO ((char far *)0x0050FB00) 10 /* Tamaño máximo del sistema operativo: 8 KB */ #define SECTORES SO 16 /* Variable de tipo dispositivo para el disquete (supone que el SO 15 * se ejecuta desde un disquete */ extern struct dispositivo * disquete; #endif 20 /* $Id: kernel.h,v /04/12 16:31:17 piernas Exp $ */ 3.2. Puntos de entrada al sistema operativo Como hemos comentado en el apartado anterior, el proceso 0, que es el flujo inicial de nuestro sistema operativo, sólo se ejecuta cuando no hay ningún proceso listo. En realidad, el proceso 0 no ejecuta todo el código del sistema operativo sino sólo una parte muy pequeña del mismo (la función main y las funciones que ésta invoca). Cuando hay procesos listos, la CPU se reparte entre ellos. El proceso 0 no se ejecuta y el sistema operativo permanece a la espera de ser activado para realizar alguna acción. 6

7 Como ya hemos comentado en la sección 2, el sistema operativo OSO puede ser activado por tres motivos: una llamada al sistema, una interrupción de teclado o una interrupción de reloj. En estos tres casos el control de la CPU pasa al sistema operativo que ejecuta parte de su código para atender a la interrupción. El código de estos tres puntos de entrada al sistema operativo se encuentra en el fichero sais.c que se muestra a continuación: #include "asm.h" #include "llamadas.h" #include "io.h" #include "procesos.h" void establecersai (void (*sai) (void), unsigned char numvector) unsigned long far * vector; 5 asm cli 10 vector = (long far *) ((int)numvector * 4); *vector = (long)sai; asm sti 15 /* SAI para las llamadas al sistema */ void sai llamadas(void) 20 salvar contexto; if ((current >contexto >ax >> 8) > NR LLAMADAS) current >contexto >ax = ENOSYS; else 25 current >contexto >ax = (tabla llamadas[current >contexto >ax >> 8].func)(); restaurar contexto; 30 /* SAI para la interrupción de teclado */ void sai teclado(void) salvar contexto; 35 recoger caracter(); asm /* EOI. Decimos al PIC que la interrupción ha sido tratada. */ 40 mov al, 20h out 20h, al restaurar contexto; 45 /* SAI para la interrupción del timer */ static char molinillo[ ] =, /, -, \\ ; static unsigned char j = 0; 50 static unsigned char far *pantalla = (char far *)0xb ; void sai timer(void) salvar contexto; 55 /* Dibujamos un molinillo usando las interrupciones del timer */ pantalla[2] = molinillo[j]; j = (j + 1) % 4; 60 7

8 /* Comprobar si se deben parar los motores de las disqueteras */ tick pararmotor(); /* Le decimos al PIC que la interrupción ha sido tratada. */ asm 65 mov al, 20h out 20h, al /* Actualizamos diversos valores, según el estado del proceso 70 interrumpido */ switch(current >estado) case PROCESO SYSCALL: current >tiemposys++; break; 75 case PROCESO RUN: current >tiempouser++; current >quantum ; break; default: 80 ; /* Situación de error */ /* Llamamos al planificador por si hay que cambiar de proceso */ planificador(); 85 restaurar contexto; /* $Id: sais.c,v /04/12 16:31:17 piernas Exp $ */ 90 El fichero cabecera asociado a sais.c es sais.h y es el siguiente: #ifndef #define SAIS H SAIS H void establecersai (void (*sai) (void), unsigned char numvector); void sai llamadas(void); 5 void sai teclado(void); void sai timer(void); #endif /* $Id: sais.h,v /04/12 16:31:17 piernas Exp $ */ 10 Se definen tres SAIs, una para cada punto de entrada. Además, se define la función establecersai que se utiliza en la función main del núcleo para asociar cada una de estas SAIs con una interrupción concreta. Como podemos observar, la estructura de las tres SAIs es similar: se salva el contexto del proceso interrumpido, se hace cierto trabajo y se restaura el contexto del proceso al que se le concede la CPU. El proceso reanudado puede ser el mismo proceso interrumpido u otro proceso distinto seleccionado por el planificador. En la sección 4 que hay a continuación podrá encontrar una descripción más detallada sobre el contexto y la planificación de procesos. La función sai_llamadas atiende las llamadas al sistema. Básicamente, lo que hace es comprobar que la llamada existe (línea 23) y ejecutar la función asociada a dicha llamada (línea 27). La función sai_teclado atiende las interrupciones de teclado. Esta función llama a la función recoger_caracter para leer del hardware de teclado el carácter introducido. Ya que la interrupción de teclado es una interrupción hardware, hay que indicar al PIC que la interrupción ha sido tratada (líneas 39 43) para que así el PIC pueda atender a más interrupciones de teclado. 8

9 La función sai_timer atiende las interrupciones de reloj. Esta función desempeña tres tareas distintas: llama a la función tick_pararmotor (para parar el motor de la disquetera si ha transcurrido cierto tiempo), actualiza ciertos campos de tiempo que existen en la estructura PCB del proceso actual (líneas 72 82) y llama a la función planificador para cambiar de proceso si es necesario (lo cual ocurrirá cuando el proceso actual haya agotado su quantum). Al ser las interrupciones de reloj interrupciones hardware, la función sai_timer también necesita decirle al PIC que ha tratado la interrupción (líneas 65 68) para así poder recibir más interrupciones de reloj. Como podemos ver, la función sai_timer dibuja otro molinillo (como la función idle descrita anteriormente) para poder ver visualmente cuándo se produce una interrupción de reloj. Este molinillo se dibuja en la segunda posición de la esquina superior izquierda de la pantalla. La explicación completa de cada una de estas SAIs se verá en las sección correspondiente, cuando veamos procesos, entrada/salida y llamadas al sistema. 4. Gestión de procesos y de memoria Esta sección describe la gestión de procesos y de memoria que realiza OSO. En especial, la sección se centra en la gestión de procesos ya que la gestión de memoria implementada es muy sencilla y se describirá de manera breve al final de la sección, en el apartado La tabla de procesos La gestión de procesos en OSO es bastante simple. OSO mantiene una «tabla de procesos» que contiene un «bloque de control de proceso» o PCB para cada proceso. La estructura PCB se define en el fichero cabecera procesos.h que se muestra a continuación: #ifndef #define PROCESOS H PROCESOS H #include "fat.h" #define MAX PROCESOS 10 #define QUANTUM 2 5 struct contexto 10 unsigned int anteriorss; unsigned int anteriorsp; unsigned int ax; unsigned int bx; unsigned int cx; 15 unsigned int dx; unsigned int ds; unsigned int es; unsigned int di; unsigned int si; 20 unsigned int bp; unsigned int ip; unsigned int cs; unsigned int estado; ; 25 struct PCB unsigned int pid; unsigned int registross; 30 9

10 ; unsigned int registrosp; unsigned int estado; unsigned int quantum; int prioridad; unsigned long tiempouser; 35 unsigned long tiemposys; unsigned int memoria; struct contexto far * contexto; extern struct PCB * current; #define PCB LIBRE 0 #define PROCESO LISTO 1 #define PROCESO RUN 2 45 #define PROCESO SYSCALL 3 #define BLOQ TECLADO 4 void inicializar tabla procesos(); void crearproceso0(void); 50 int crearproceso(struct dispositivo far * pdis, char far * programa); void desbloquearprocesos(int bloqueadosen); void planificador(void); void ceder CPU(void); 55 #endif /* $Id: procesos.h,v /04/19 19:12:07 piernas Exp $ */ 40 Para cada proceso la estructura PCB correspondiente almacena: el identificador del proceso (pid), un puntero a la cima de la pila (registross y registrosp), el estado del proceso (estado), unidades de tiempo que le quedan al proceso para agotar su quantum (quantum), la prioridad del proceso (prioridad), unidades de tiempo que el proceso se ha estado ejecutando en modo usuario (tiempouser) y en modo núcleo (tiemposys), segmento de memoria asignado al proceso (memoria) y un puntero al contexto del proceso (contexto). La utilidad de cada uno de estos campos la veremos más tarde. La tabla de procesos es una estructura de datos estática por lo que el número máximo de proceso que se pueden ejecutar a la vez está limitado (en este caso, a 10, tal y como indica la constante MAX_PROCESOS definida en la línea 6 del fichero procesos.h) Estado de un proceso Como podemos ver en el fichero procesos.h (líneas 41 45), un proceso puede estar en 4 estados posibles: PROCESO_LISTO. Indica que el proceso está esperando a que se le conceda la CPU. PROCESO_RUN. Indica que el proceso está usando la CPU. PROCESO_SYSCALL. Este estado indica que el proceso está en mitad de la ejecución de una llamada al sistema y que no se le puede quitar la CPU. Como veremos en la sección 7, este estado se utiliza cuando un proceso ejecuta una llamada al sistema que necesita hacer uso de la BIOS. BLOQ_TECLADO. Indica que el proceso está bloqueado esperando a que se introduzca un carácter por teclado. En este estado al proceso no se le puede dar la CPU. El quinto valor, PCB_LIBRE, no es un estado de proceso y se utiliza para indicar que una entrada de la tabla de procesos está libre. 10

11 4.3. Contexto de un proceso Antes de ver la implementación de procesos en OSO, es importante entender qué es, cómo se guarda y cómo se restaura el contexto de un proceso. Podemos decir que el «contexto» de un proceso lo constituyen todos aquellos datos que es necesario guardar cuando se interrumpe un proceso para que posteriormente, cuando se reanude el proceso, éste pueda continuar su ejecución de forma normal, como si nunca hubiera sido interrumpido. En nuestro caso, el contexto de un proceso está formado por todos los registros del procesador. En el fichero asm.h se definen dos macros que permiten guardar el contexto de un proceso interrumpido y reanudar la ejecución de un proceso. El contenido de este fichero es el siguiente: #ifndef #define ASM H ASM H /* La interrupción ya ha guardado en la pila CS, IP y los flags. Hay que * guardar todos los demás registros. Los registros BP, SI y DI los apila 5 * automáticamente el compilador cuando ve que se usan, como será nuestro * caso al hacer pop di y pop si en restaurar proceso * * Las intrucciones que añade el compilador son: * push bp; 10 * push si; * push di; * * Para poder acceder a las variables dentro del núcleo, debemos poner en * DS y en ES valores correctos. Como el núcleo es un programa COM, debemos 15 * hacer que DS y ES tengan el mismo valor que CS. Esto es lo que hacen las * tres últimas instrucciones en ensamblador. * * La última parte guarda la información de pila del proceso interrumpido * en su PCB (guardando previamente la información anterior del PCB en la 20 * propia pila). Además, se hace que el campo contexto del PCB apunte a * la cima de la pila para poder acceder fácilmente a los registros * almacenados y que configuran el contexto. */ 25 #define salvar contexto \ asm \ push es; \ push ds; \ push dx; \ 30 push cx; \ push bx; \ push ax; \ \ mov ax, cs; \ 35 mov ds, ax; \ mov es, ax; \ \ AX = current >registross; \ asm push ax \ 40 AX = current >registrosp; \ asm push ax \ current >registross = SS; \ current >registrosp = SP; \ current >contexto = (struct contexto far *) \ 45 (((long)current >registross << 16) + current >registrosp); /* Restauramos el contexto para el proceso apuntado por current. * 50 * Los tres últimos pop los tenemos que hacer nosotros porque no llegamos 11

12 * al final del procedimiento, donde los añade el compilador, ya que * ejecutamos un iret antes. */ #define restaurar contexto \ 55 SS = current >registross; \ SP = current >registrosp; \ asm pop ax \ current >registrosp = AX; \ asm pop ax \ 60 current >registross = AX; \ current >contexto = (struct contexto far *) \ (((long)current >registross << 16) + current >registrosp); \ asm \ pop ax; \ 65 pop bx; \ pop cx; \ pop dx; \ pop ds; \ pop es; \ 70 pop di; \ pop si; \ pop bp; \ iret; \ \ 75 #endif /* $Id: asm.h,v /04/19 19:12:07 piernas Exp $ */ Como podemos ver, la macro salvar_contexto almacena en la pila el valor de todos los registros del procesador a excepción de 3: CS, IP y el «registro de estado». Esto es así porque estos 3 registros los apila automáticamente el hardware cuando se produce una interrupción, que es la única causa por la que la ejecución de un proceso se puede interrumpir. Por tanto, no es necesario guardarlos de nuevo. La macro salvar_contexto hace alguna cosa más. Además de salvar el contexto del proceso actual en la pila del propio proceso, asigna a los registros DS y ES un valor adecuado para así poder acceder a todas las variables definidas dentro del núcleo del sistema operativo (vea las líneas 33 36). Es decir, establece un contexto apropiado para la ejecución del sistema operativo. Ya que no modifica el registro SS podemos decir que cuando un proceso se ejecuta en «modo núcleo» usa la misma pila que usa cuando se ejecuta en «modo usuario». El hecho de que cada proceso tenga su propia pila cuando se ejecuta en «modo núcleo» es importante porque nos permite interrumpir a cualquier proceso dentro del núcleo, haciendo así que el núcleo del sistema operativo sea reentrante. Lo siguiente que se hace en salvar_contexto es guardar en la pila el valor actual de los campos registross y registrosp del PCB del proceso interrumpido (el apuntado por current). Estos campos apuntan en todo momento al último contexto almacenado en la pila. Ya que vamos a almacenar un nuevo contexto, es importante que el valor anterior de registross y registrosp se guarde para no perder así la dirección del contexto anterior. Lo último que hace la macro salvar_contexto es guardar la dirección de la cima de la pila (es decir, la del nuevo contexto) en los campos registross y registrosp, y usar el valor de dichos campos para hacer que el campo contexto del PCB del proceso interrumpido apunte a la pila. El campo contexto, que es de tipo struct contexto far *, nos permite tratar a la pila como a una estructura de datos más y nos facilita el acceso al valor de los registros almacenados en la pila cuando ésta guarda el contexto de un proceso interrumpido. También nos permite modificar fácilmente el valor de uno de dichos registros para así devolver un valor a un proceso cuando éste reanude su ejecución. La utilidad del campo contexto la veremos al estudiar la implementación de las llamadas al sistema, en la sección 7. Para restaurar el contexto de un proceso lo único que hay que hacer es devolver a los registros del procesador el valor que tenían cuando se interrumpió el proceso. Ya que estos registros se salvaron en la pila del proceso basta 12

13 con desapilarlos de la misma para restaurarlos. Al igual que antes, no es necesario desapilar los registros CS, IP y el «registro de estado» puesto que esto lo hace automáticamente el hardware cuando se ejecuta la instrucción iret. La restauración del contexto se hace con la macro restaurar_contexto. Esta macro restaura el contexto del proceso apuntado por la variable current sin importar qué proceso sea éste. Quizás se esté preguntando por qué es necesario el poder guardar y restaurar varios contextos. La respuesta es que un proceso ya interrumpido (y, por tanto, ejecutando código del núcleo del sistema operativo) puede ser interrumpido de nuevo. Vea el apartado 7.1 para más detalles Gestión de procesos Una vez descritos el mecanismo de cambio de contexto y la tabla de procesos, es el momento de ver cómo gestiona OSO los procesos. La gestión de procesos se implementa en el fichero procesos.c, cuyo contenido es el siguiente: #include "io.h" #include "string.h" #include "procesos.h" #include "asm.h" struct PCB tablaprocesos[max PROCESOS]; struct PCB * current = NULL; 5 /* El PCB 0 se asigna al sistema operativo, que ocupa los primeros 64 KB de memoria. El resto de PCBs quedan libres para procesos. */ 10 void inicializar tabla procesos() int i; unsigned int mem = 0; 15 for(i = 0; i < MAX PROCESOS; i++) tablaprocesos[i].estado = PCB LIBRE; tablaprocesos[i].memoria = mem; mem += 0x1000; 20 /* El proceso 0 es un hilo dentro del propio sistema operativo */ void crearproceso0(void) 25 current = tablaprocesos; current >pid = 0; current >estado = PROCESO RUN; current >quantum = QUANTUM; current >prioridad = 0; 30 current >tiempouser = 0; current >tiemposys = 0; current >memoria = 0; 35 /* Crea un nuevo proceso para el fichero ejecutable programa del * dispositivo pdis */ int crearproceso(struct dispositivo far * pdis, char far * programa) int i; 40 struct PCB * proceso; struct contexto far * pila; long memoria; for(i = 0; i < MAX PROCESOS; i++) 45 13

14 if (tablaprocesos[i].estado == PCB LIBRE) break; if (i == MAX PROCESOS) return 1; 50 proceso = tablaprocesos + i; memoria = (long)(proceso >memoria) << 16; 55 if (cargarcom(pdis, programa, (char far *)((long)memoria + 0x100))) return 1; pila = (struct contexto far *)(memoria + 0xFFFE sizeof(struct contexto)); 60 pila >ax = 0; pila >bx = 0; pila >cx = 0; pila >dx = 0; pila >di = 0; 65 pila >si = 0; pila >bp = 0; pila >estado = 0x0200; pila >cs = (long)memoria >> 16; pila >ip = 0x100; 70 pila >ds = pila >cs; pila >es = pila >cs; proceso >pid = i; proceso >registross = pila >cs; 75 proceso >registrosp = 0xFFFE sizeof(struct contexto); proceso >prioridad = 0; proceso >tiempouser = 0; proceso >tiemposys = 0; proceso >quantum = QUANTUM; 80 asm cli proceso >estado = PROCESO LISTO; asm sti return i; 85 /* Desbloquea a todos los procesos que están esperando en bloqueadosen */ void desbloquearprocesos(int bloqueadosen) 90 int i; for (i = 0; i < MAX PROCESOS; i++) if (tablaprocesos[i].estado == bloqueadosen) tablaprocesos[i].estado = PROCESO LISTO; 95 /* Selecciona, de forma circular, al siguiente proceso listo tras el * proceso apuntado por actual */ static struct PCB * round robin(struct PCB * actual) 100 int i = actual tablaprocesos; int n = MAX PROCESOS; while (n) 105 i = (i + 1) % MAX PROCESOS; if (i == 0) n ; 110 continue; 14

15 if (tablaprocesos[i].estado == PROCESO LISTO) break; n ; 115 if (n == 0) i = 0; return tablaprocesos + i; 120 /* Este es el procedimiento que selecciona el siguiente proceso a ejecutar */ void planificador(void) 125 /* No le podemos quitar la CPU a un proceso mientras se está atendiendo su llamada al sistema. Y hemos de cambiar de proceso si el proceso está bloqueado o si ha agotado su quantum. */ switch(current >estado) case PROCESO SYSCALL: 130 break; case BLOQ TECLADO: current = round robin(current); current >estado = PROCESO RUN; break; 135 case PROCESO RUN: if (current >quantum) break; current >estado = PROCESO LISTO; current >quantum = QUANTUM; 140 current = round robin(current); current >estado = PROCESO RUN; default: ; /* situación de error */ 145 static void nuevo proceso(void) salvar contexto; 150 planificador(); restaurar contexto; 155 /* El siguiente procedimiento permiten a un proceso ceder la * CPU a otro proceso. Esto es útil cuando un proceso se bloquea */ void ceder CPU(void) 160 /* Simulamos una interrupción */ asm pushf cli push cs 165 nuevo proceso(); /* $Id: procesos.c,v /04/12 16:31:17 piernas Exp $ */ 170 Al principio del fichero se definen las variables tablaprocesos y current. La primera, como su propio nombre indica, es la tabla de procesos que mantiene el sistema operativo. La segunda apunta en todo momento a la entrada de la tabla de procesos correspondiente al proceso actual, es decir, al proceso en ejecución. Vamos a describir ahora los distintos aspectos que se implementan las funciones de este fichero. 15

16 Creación de procesos La primera función, inicializar_tabla_procesos, inicializa la tabla de procesos marcando todas las entradas como libres. Además, inicializa el campo memoria de los distintos PCBs. Para un PCB concreto este campo indica el segmento de memoria que ocupará el proceso al que se le asigne dicho PCB. La siguiente función, crearproceso0, inicializa la entrada PCB del proceso que ocupa la entrada 0 de la tabla de procesos. Como hemos comentado en la sección 3.1, este proceso 0 es el propio sistema operativo que, según la entrada PCB, ocupa los primeros 64 KB de memoria (lo que incluye la tabla de vectores de interrupción y la zona de datos de la BIOS). La función crearproceso, que se describe en las líneas del fichero procesos.c, es la más importante de todas. Esta función crea un nuevo proceso para ejecutar el código del programa COM cuyo nombre se le pasa como argumento. El otro parámetro que se le pasa a esta función es el dispositivo de almacenamiento en el que se encuentra el programa a ejecutar. Lo primero que hace la función crearproceso es buscar una entrada libre en la tabla de procesos. Si no encuentra ninguna la función termina. Si encuentra una entrada libre carga en el segmento de memoria asignado a dicha entrada el programa a ejecutar, haciendo uso de la función cargarcom (líneas 54 58). Observe que el programa no se carga al principio del segmento sino 0x100 bytes más adelante ya que se supone que ése es el desplazamiento en el que comienza un programa COM dentro de un segmento. Si el programa se ha podido cargar en memoria entonces la función crearproceso inicializa su pila (líneas 60 72) y su entrada PCB (líneas 74 83) y termina, devolviendo el identificador o PID del nuevo proceso (que se corresponde con su número de entrada en la tabla de procesos). Lo más interesante es cómo se inicializa la pila ya que debe almacenar un contexto adecuado para así poder ejecutar el nuevo proceso cuando se restaure su contexto. Todos los registros almacenados en la pila van a tener un valor 0 salvo los siguientes: CS, DS, ES y SS: todos van a tener el mismo valor, que será el segmento de memoria asignado a la entrada PCB seleccionada para el proceso. IP: su valor inicial es 0x100 para un programa COM. registro de estado: debe tener activo el bit IF para que se habiliten las interrupciones cuando el programa comience a ejecutarse. Se le asigna el valor 0x0200. SP: apunta a la cima de la pila creada (vea las líneas 60 y 79). Ya que estamos suponiendo segmentos de 64 KB, la pila crece desde la dirección 0xFFFE hacia abajo Planificación de procesos La planificación de procesos realizada por OSO consiste en una planificación circular con un quantum de 2 unidades de tiempo. Cada unidad de tiempo equivale al periodo de los ticks de reloj. Ya que se producen 18 2 ticks por segundo, podemos decir que el quantum equivale a = segundos o 110 milisegundos. La planificación de procesos se realiza en la función planificador (línea 124 del fichero procesos.c). Como vemos, sólo se cambia de proceso cuando el proceso actual está bloqueado (está en el estado BLOQ_TECLADO) o cuando está en ejecución y ha agotado su quantum (su estado es PROCESO_RUN y el campo current->quantum es 0). En estos dos casos se llama a la función round_robin que selecciona de forma circular al siguiente proceso listo tras el proceso actual. En cuanto a la función round_robin, el único aspecto interesante que podemos comentar es que únicamente selecciona al proceso 0 (que es el propio sistema operativo) cuando no hay ningún otro proceso listo. Otra función relacionada con la planificación es la función desbloquearprocesos (línea 89 de procesos.c) que se utiliza para poner como listo a cualquier proceso cuyo estado coincida con el que se pasa 16

17 como parámetro. Esta función la utilizará la SAI del teclado para desbloquear a todo proceso que se encuentre bloqueado esperando un carácter de teclado (el estado de estos procesos será BLOQ_TECLADO). Finalmente, la función ceder_cpu (línea 159) la puede utilizar un proceso para ceder la CPU a otro proceso. Esto ocurrirá cuando un proceso se bloquee dentro del núcleo. En ese caso, el proceso no podrá continuar su ejecución hasta que no se produzca el evento que espera, por lo que tendrá que ceder la CPU para que el sistema no se quede parado. La función ceder_cpu, junto con la función nuevo_proceso, simula una interrupción. Para ello, apila la palabra de estado del procesador (con pushf), el registro CS y el registro IP. Esto último lo hace de forma indirecta llamando a la función nuevo_proceso que actúa como una SAI Apropiación de la CPU Para evitar que un proceso monopolice la CPU hay que desalojar periódicamente al proceso que se encuentre en ella. Para conseguir esto vamos a hacer uso de las interrupciones de reloj que trata la función sai_timer descrita en el apartado 3.2. En cada interrupción de reloj, la SAI decrementa en una unidad el quantum del proceso en ejecución y llama al planificador. Si el quantum es 0, el planificador cambia de proceso. En caso contrario, deja la CPU al proceso interrumpido Gestión de memoria En el apartado hemos visto que cuando se inicializa la tabla de procesos en la función inicializar_tabla_procesos se inicializa también el campo memoria de los distintos PCBs. Como hemos dicho, para un PCB este campo indica el segmento de memoria que ocupará un proceso al que se le asigne dicho PCB. Como podemos observar en dicha función, al PCB 0 se le asigna el segmento de memoria 0, al PCB 1 el segmento de memoria 0x1000, al PCB 2 el 0x2000, y así sucesivamente hasta el PCB 9, al que se le asigna el segmento de memoria 0x9000. Dicho de otra manera, al PCB 0 se le asignan los primeros 64 KB de memoria, al PCB 1 los siguientes 64 KB y así sucesivamente. En total, los 10 procesos que pueden existir a la vez ocuparán los primeros 640 KB de memoria RAM, que es la memoria disponible en el modo real para la ejecución de programas. Como vemos, la gestión de memoria de OSO es muy sencilla y se basa en un esquema de particiones estáticas del mismo tamaño donde a cada proceso se le asignará la partición correspondiente al PCB que use. Esta gestión de memoria también permite cierta «protección» entre procesos. OSO sólo es capaz de ejecutar programas COM. Estos programas se ejecutan haciendo uso de un único segmento porque todos los registros de segmento, incluido el de pila, tienen el mismo valor. Ya que el tamaño del desplazamiento dentro de un segmento es de 16 bits, un programa COM no puede direccionar más de 64 KB y, por tanto, no puede acceder a ninguna dirección de memoria fuera del segmento de memoria asignado (siempre, claro está, que no modifique el valor de ningún registro de segmento). 5. Sistema de ficheros OSO utiliza FAT12 como sistema de ficheros. Este sistema de ficheros es el que utiliza Windows en los disquetes. Como hemos comentado en la introducción, al utilizar un sistema de ficheros real podemos utilizar las herramientas que ya existen en sistemas operativos como Windows o Linux. En esta sección no pretendemos describir de forma detallada cómo funciona FAT12 ya que es un sistema de ficheros ampliamente explicado y documentado. Lo que vamos a hacer es explicar aquellos aspectos de la implementación más interesantes. 17

18 El código fuente que implementa el sistema de ficheros en OSO aparece en los ficheros fat.h y fat.c. Estos ficheros se muestran a continuación: #ifndef #define FAT H FAT H #define TAMA SECTOR 512 #define NUM DISPOSITIVOS 4 5 struct dispositivo unsigned int unidad; unsigned int cabezas; unsigned int sectores por pista; 10 unsigned int bytes por sector; unsigned long total sectores; unsigned int tipo fat; unsigned int inicio fat; unsigned int entradas fat; 15 unsigned int inicio raiz; unsigned int entradas raiz; unsigned int inicio clusters; unsigned int sectores por cluster; ; 20 void inicializar tabla dispositivos(void); struct dispositivo * abrir dispositivo(unsigned char unidad); int cerrar dispositivo(struct dispositivo * pdis); 25 int cargarcom(struct dispositivo far * pdis, char far * programa, char far * direccion); 30 #endif /* $Id: fat.h,v /07/24 15:21:38 piernas Exp $ */ #include "io.h" #include "string.h" #include "fat.h" /* Estructura de un sector de arranque en un sistema de ficheros FAT */ 5 struct boot sector char salto[3]; /* 00h */ char identificacion[8]; /* 03h */ unsigned int bytes por sector; /* 0Bh */ unsigned char sectores por cluster; /* 0Dh */ 10 unsigned int sectores reservados; /* 0Eh */ unsigned char copias fat; /* 10h */ unsigned int entradas raiz; /* 11h */ unsigned int total sectores; /* 13h */ unsigned char formato disco; /* 15h */ 15 unsigned int sectores por fat; /* 16h */ unsigned int sectores por pista; /* 18h */ unsigned int cabezas; /* 1Ah */ unsigned int sectores ocultos; /* 1Ch */ unsigned int pad; 20 unsigned long total sectores long; /* 20h */ unsigned char unidad hd; /* 24h */ char reservado; /* 25h */ char marca; /* 26h */ unsigned long numero serie; /* 27h */ 25 char etiqueta[11]; /* 2Bh */ char reservado dos[8]; /* 36h */ 18

19 char cargador[0x1be 0x3E]; /* 3Eh */ char particiones[512 0x1BE]; /* 1BEh */ ; 30 /* Estructura de datos para guardar información de los distintos * dispositivos abiertos */ struct dispositivo tabla dispositivos[num DISPOSITIVOS]; /* Inicializa la tabla de dispositivos */ void inicializar tabla dispositivos(void) int i; 35 for (i = 0; i < NUM DISPOSITIVOS; i++) 40 tabla dispositivos[i].cabezas = 0; /* Abre el dispositivo especificado por unidad. Se supone que el dispositivo * tiene formato FAT12 o FAT16 */ 45 struct dispositivo * abrir dispositivo(unsigned char unidad) int i; struct dispositivo * pdis; struct boot sector sector; long total clusters; 50 for (i = 0; i < NUM DISPOSITIVOS; i++) if (tabla dispositivos[i].cabezas == 0) break; if (i == NUM DISPOSITIVOS) 55 return NULL; if (leersector((char *)&sector, 0, 0, 1, unidad)) kputs("error: leyendo el sector de arranque\n\r"); return NULL; 60 pdis = tabla dispositivos + i; /* Datos generales del disco */ pdis >unidad = unidad; 65 pdis >cabezas = sector.cabezas; pdis >sectores por pista = sector.sectores por pista; pdis >bytes por sector = sector.bytes por sector; pdis >total sectores = (long) sector.total sectores; if (pdis >total sectores == 0) 70 pdis >total sectores = sector.total sectores long; /* Directorio raiz */ pdis >inicio raiz = sector.sectores reservados + sector.sectores por fat * sector.copias fat; 75 pdis >entradas raiz = sector.entradas raiz; /* Datos sobre clusters */ pdis >inicio clusters = pdis >inicio raiz + (pdis >entradas raiz * 32) / pdis >bytes por sector; pdis >sectores por cluster = sector.sectores por cluster; 80 /* Datos de la FAT */ total clusters = ((unsigned)pdis >total sectores pdis >inicio clusters) / pdis >sectores por cluster; pdis >tipo fat = sector.formato disco; pdis >inicio fat = sector.sectores reservados; 85 pdis >entradas fat = total clusters + 2; return pdis; /* Lee num sectores del dispositivo pdis empezando en el sector nsec. 90 * los sectores leídos se almacenan a partir de la dirección buffer */ static int dispositivo leersectores (struct dispositivo far * pdis, unsigned nsec, 19

20 unsigned int num, char far * buffer) 95 unsigned int sector, cabeza, cilindro; int i; if ((nsec + num 1) >= pdis >total sectores) kputs("intentando acceder mas alla del final del dispositivo\n\r"); 100 kcadvalor("sector: ", nsec); kcadvalor("contador: ", num); return 1; 105 cilindro = nsec / (pdis >cabezas * pdis >sectores por pista); cabeza = (nsec % (pdis >cabezas * pdis >sectores por pista)) / pdis >sectores por pista; sector = (nsec % (pdis >cabezas * pdis >sectores por pista)) % pdis >sectores por pista + 1; 110 for(i = 0; i < num; i++) if (leersector(buffer, cilindro, cabeza, sector, pdis >unidad)) kputs("error: E/S\n\r"); return 1; sector; if (sector > pdis >sectores por pista) sector = 1; ++cabeza; 120 if (cabeza >= pdis >cabezas) cabeza = 0; ++cilindro; 125 buffer += pdis >bytes por sector; return 0; 130 /* Lee el cluster cluster (formado por cualquier número de sectores) del * dispositivo pdis y lo almacena en la dirección buffer de memoria */ static int dispositivo leercluster(struct dispositivo far * pdis, unsigned int cluster, char far * buffer) 135 unsigned sector cluster; sector cluster = (cluster 2) * pdis >sectores por cluster; sector cluster += pdis >inicio clusters; 140 return dispositivo leersectores(pdis, sector cluster, pdis >sectores por cluster, buffer); 145 /* Cierra un dispositivo abierto previamente */ int cerrar dispositivo(struct dispositivo * pdis) int entrada = pdis tabla dispositivos; 150 tabla dispositivos[entrada].cabezas = 0; return 0; /* Formato de la entrada de directorio en un sistema FAT */ struct entrada dir char nombre[8]; char ext[3];

21 ; struct 160 unsigned char r: 1, h: 1, s: 1, e: 1, d: 1, a: 1, pad: 2; atributos; char reservado dos[10]; struct unsigned int s: 5, m: 6, h: 5; 165 hora; struct unsigned int d: 5, m: 4, a: 7; fecha; unsigned int bloque inicio; 170 long tama; /* Devuelve el cluster inicial (cluster) y el tamaño (tama) del fichero * nomfich del directorio raíz. Si el fichero existe, la función devuelve 175 * 0 y -1 en caso contrario. */ static int cluster inicial(struct dispositivo far * pdis, char far * nomfich, unsigned int far * cluster, long far * tama) struct entrada dir far * dir; char bloque[tama SECTOR]; 180 int i, lon; char nombre[8], ext[3], far * psubstr; int raiz; psubstr = kstrchr(nomfich,. ); 185 if (psubstr) lon = psubstr nomfich; if (lon > 8) lon = 8; kstrncpy(nombre, nomfich, lon); 190 for (i = lon; i < 8; i++) nombre[i] = ; lon = kstrlen(++psubstr); if (lon > 3) lon = 3; 195 kstrncpy(ext, psubstr, lon); for (i = lon; i < 3; i++) ext[i] = ; else 200 lon = kstrlen(nomfich); if (lon > 8) lon = 8; kstrncpy(nombre, nomfich, lon); for (i = lon; i < 8; i++) 205 nombre[i] = ; for (i = 0; i < 3; i++) ext[i] = ; 210 raiz = pdis >inicio raiz; if (dispositivo leersectores(pdis, raiz, 1, bloque)) return 1; dir = (struct entrada dir *) bloque; 215 for (i = 0; i < pdis >entradas raiz; i++) if (!kstrncmp(dir >nombre, nombre, 8) &&!kstrncmp(dir >ext, ext, 3)) *cluster = dir >bloque inicio; *tama = dir >tama; 220 return 0; ++dir; if ((char *)dir >= (bloque + pdis >bytes por sector)) ++raiz;

22 if (dispositivo leersectores(pdis, raiz, 1, bloque)) return 1; dir = (struct entrada dir *) bloque; 230 /* No hemos encontrado el fichero */ *cluster = 0; return 1; 235 static int siguiente cluster 12(struct dispositivo far * pdis, int cluster) unsigned int desplazamiento, aleer, bloque1, bloque2; char bloque[2 * TAMA SECTOR]; unsigned int siguiente; 240 desplazamiento = ((cluster << 1) + cluster) >> 1; bloque1 = desplazamiento / pdis >bytes por sector; bloque2 = (desplazamiento + 1) / pdis >bytes por sector; if (bloque1 == bloque2) aleer = 1; else aleer = 2; bloque1 += pdis >inicio fat; if (dispositivo leersectores(pdis, bloque1, aleer, bloque)) return 0; siguiente = *((unsigned int far *)(bloque + desplazamiento % pdis >bytes por sector)); if (cluster & 0x0001) siguiente >>= 4; else 260 siguiente &= 0x0FFF; if (siguiente > 0xFF0) return 0; return siguiente; 265 static int siguiente cluster 16(struct dispositivo far * pdis, int cluster) return 0; 270 /* Devuelve el cluster que sigue a cluster o 0 si cluster es el último * cluster de un fichero o si se produce un error al leer de disco. */ static int siguiente cluster(struct dispositivo far * pdis, int cluster) 275 switch(pdis >tipo fat) case 0xF0: return siguiente cluster 12(pdis, cluster); case 0xF8: return siguiente cluster 16(pdis, cluster); 280 return 0; /* Carga el fichero programa del directorio raíz del dispositivo pdis en 285 * dirección de memoria direccion. */ int cargarcom(struct dispositivo far * pdis, char far * programa, char far * direccion) unsigned int cluster; long tama; 290 unsigned int tama cluster; 22