2 EL KERNEL

2.1 QU ES EL KERNEL?

El kernel es el sistema central de cualquier sistema operativo. Todos los sistemas operativos constan de una parte encargada de gestionar los diferentes procesos y las posibles comunicaciones entre el hardware de un ordenador con los programas que estn en funcionamiento, entre otras y variadas tareas. Es, por ejemplo, el que facilita el acceso a datos en los distintos soportes posibles (CD-ROM, unidad de disco duro, unidad ZIP, etc.), o el que arranca el ordenador, o el que resetea todos los dispositivos que sean necesarios. La principal propiedad de un kernel es que todas estas operaciones de manejo de memoria o de dispositivos, son, desde un punto de vista de usuario, totalmente transparentes, esto es, no es necesario saber como trabajar a bajo nivel con el procesador para realizar las operaciones que sean necesarias, ya que ser el kernel, a travs de una serie de instrucciones ya implementadas el que lo har por nosotros. Para todo aquel que llegado este punto desee continuar con la lectura de este apartado, quiero advertirle que si est buscando una ayuda rpida de nivel medio-avanzado, no espere encontrarla en esta web. Aqu nicamente trato las diferentes partes de que consta el kernel y su funcionamiento, pero no el uso del sistema operativo. Para el que est interesado en este tema le recomiendo conseguir el libro [MP98], el cual es una introduccin a este gran sistema operativo para un usuario no iniciado en l.

2.1.1 Estructura del sistema

Los kernels de Windows NT o Minix son de tipo micro-kernel, caracterizado porque proveen al sistema de un estado mnimo necesario de funcionalidad, cargando el resto de funciones necesarias en procesos autnomos e independientes unos de otros, comunicndose con este micro-kernel a travs de una interfaz bien definida. Este tipo de estructura es ms fcil de mantener y el desarrollo de nuevos componentes es mucho ms simple, dando a su vez una mayor estabilidad al sistema. Por otro lado, debido a la estructura rgida del interfaz, estos tipos de kernel son mucho ms complicados de reestructurar, y adems, debido a las arquitecturas del hardware actual, el proceso de intercomunicacin dentro del micro-kernel es mucho ms que una simple llamada, por lo que hace que esta estructura sea ms lenta que los kernels de tipo monolticos o macrokernels. No hay que olvidar que Linux ha sido desarrollado como un simple placer por desarrollar un sistema, el cual ha evolucionado gracias a diferentes programadores de todo el mundo.

Debido a esto, una estructura de micro-kernel es prcticamente inconcebible, aunque esto no quiere decir que el kernel de linux sea una simple lista de instrucciones sin estructura alguna. A pesar de la estructura de macro-kernel, se ha intentado equiparar su velocidad utilizando cdigo optimizado en velocidad (aunque complicado de entender), y se ha recuperado algunas de las mejores caractersticas de la estructura de micro-kernel, como puede ser la carga de los diferentes drivers necesarios como mdulos independientes, siempre sin olvidar la estructura monoltica original. En el caso de Linux, la gran parte del kernel est escrito en C, existiendo tambin instrucciones en ensamblador, aunque estas ultimas se usan mayoritariamente en los procesos de arranque y en el control de co-procesador. A continuacin se muestra una tabla con la cantidad de lineas en C y ensamblador que se usan aproximadamente en la versin 2.0 del kernel de Linux, el cual consta de unas 470.000 lineas de cdigo (la versin 1.0 constaba "nicamente" de 165.000 lineas):

Cdigo C Ensamblador Dispositivos de Drivers 377.000 100 Network 25.000 VFS 13.500 13 archivos de sistema 50.000 Inicio 4.000 2.800 Co-Procesador 3.550 Tabla 1 - Proporciones de cdigo fuente por componente

A modo de curiosidad cabe comentar el significado de la serie de nmeros que acompaan al kernel, tanto compilado como al directorio que contiene las fuentes de ste, que, a pesar de no ser necesarios, se suelen incluir porque aportan una mayor informacin. Este conjunto de cifras tienen el formato X.X.XX y su significado no es ms que la versin del kernel a la que corresponde dicho archivo, aunque no es simplemente as. Como se puede suponer, la variacin en una unidad del primer grupo de cifras significa un cambio muy importante en el kernel, siendo sta menor conforme el grupo de cifras que vara est ms hacia la derecha. El ltimo grupo de cifras tiene, adems del significado anterior como indicador de versin, un significado aadido, que es el de que si la cifra es par, esa versin de kernel se considera como una versin estable, si, en cambio sta es impar, se considera que la versin del kernel es una versin en fase beta o de desarrollo.

2.1.2 Procesos y Tareas

Desde el punto de vista de un proceso ejecutndose en Linux, el kernel es un proveedor de servicios. Cada proceso existe por separado y el espacio de memoria reservado a cada uno de ellos est protegido para que no pueda ser modificado. Desde este punto de vista, se est llevando a cabo un sistema multiproceso real (ver Figura 1). Desde un punto de vista interno, la cosa es distinta. Solo hay un proceso en marcha en el ordenador que puede acceder a todos los recursos, el sistema operativo. El resto de tareas se llevarn a cabo como co-rutinas, las cuales, de una forma totalmente independiente, deciden por ellas mismas a qu tarea y cundo pasarn el control. Debido a esto, un fallo en la programacin del kernel podra bloquear todo el sistema.

Figura 1 - Los procesos desde una vista interna y externa Cuando se ha iniciado un proceso, este puede adquirir distintos estados:

1. Ejecucin (Running) La tarea est activa y en ejecucin. Este proceso solo puede ser interrumpido por una interrupcin o una llamada del sistema. 2. Rutina interrumpida (Interrupt Routine) Est rutina se activa con una interrupcin del sistema (hardware), como puede ser un pulsacin del teclado o una llamada del reloj.

3. Llamada del Sistema (System Call) Las llamadas del sistema se activan debido a una interrupcin producida por el software. Pueden suspender una tarea para llevar acabo un evento. 4. En espera (Waiting) El proceso est en espera de un evento externo. 5. Vuelta de la llamada del sistema (Return from system call) Este estado se adopta automticamente despus de una llamada del sistema y algunas interrupciones. 6. Preparado (Ready) El proceso est en espera de ser atendido por el procesador, que est ocupado con otro proceso en ese momento. Estos estados no pueden ser adquiridos sin orden alguno o porque s, sino que llevan un ciclo el cual debe ser respetado. Adems, como veremos en el siguiente apartado, si observamos la Figura 3 podremos observar que estos procesos no son "islas" independientes unas de otras, sino que hay una relacin familiar entre ellos.

Figura 2 - Estados posibles de un proceso En muchos sistemas operativos actuales se hace la distincin entre procesos y threads. Un thread es una especie de rama o camino en la ejecucin de un programa que puede ser procesado en paralelo con otros threads. Linux no hace esa distincin. En el kernel, nicamente existe el concepto de un proceso, el cual puede compartir recursos con otros procesos. Por eso, una tarea es una generalizacin del concepto de un thread.

2.2 PRINCIPALES ESTRUCTURAS DE DATOS

2.2.1 La estructura Tarea

En un sistema multitarea es muy importante como una tarea est definida. Es, probablemente, una de los conceptos ms importantes en un sistema operativo de este tipo. De hecho los algoritmos usados en Linux para su manejo constituyen la mayor parte del cdigo del kernel. La descripcin de las caractersticas de un proceso, vienen dadas por la estructura task_struct. Una de las variables usadas es la llamada state, que es la encargada de almacenar el estado actual de la tarea (los valores que puede tomar esta variable los podemos ver en la Figura 2). Otras variables son counter, que es la variable usada por el Programador (scheduler) para seleccionar el siguiente proceso, o signal que contiene un mscara de un bit (bit mask) para las seales recibidas por el proceso. Todos los procesos creados son introducidos en una lista doblemente enlazada gracias a los dos punteros siguientes (el comienzo y final de esta lista estn almacenados en la variable global init_task): struct task_struct *next_task; struct task_struct *previous_task; En un sistema Unix, los procesos no existen independientemente unos de otros, sino que cada proceso est relacionado con los dems, siguiendo una jerarqua familiar segn que proceso lo haya creado, y que al igual que los anteriores estn representados por: struct task_struct p_opptr; /* Padre original */ struct task_struct p_pptr; /* Padre */ struct task_struct p_cptr; /* Hijo ms joven */ STRUCT TASK_STRUCT P_YSPTR; /* YOUNGER SIBLING */ struct task_struct p_osptr; /* OLDER SIBLING */

Figura 3 - Relaciones entre procesos Otras caractersticas de esta estructura son, por ejemplo, que cada proceso posee su propia subestructura para el almacenamiento de datos, o que cada proceso posee un numero identificativo pid, a partir del cual se nos facilitar el manejo de dicha tarea.

2.2.2 La tabla de procesos

Cada proceso en ejecucin que haya en el ordenador, ocupa una entrada en la tabla de proceso, la cual est restringida aen tamao a NR_TASKS. En Linux, la tarea 0 (task[0]) es INIT_TASK, por lo que ser la primera tarea cargada por el kernel. Esto es as por que ella ser la encargada de lanzar el resto de tareas, como los demonios cargados en el inicio (p.ej. lpd) o el controlador del ratn (gpm).

2.2.3 Ficheros e inodes

En los sistemas UNIX se ha hecho tradicionalmente una distincin entre la estructura de archivos y la de inodes. La estructura inode describe un archivo, aunque esto puede ser visto de diferentes formas: por ejemplo, la estructura de datos en el kernel y la del disco duro describen archivos, y, a pesar de ser distintas, se denominan inodes. Los inodes contienen informacin del archivo como propietario, derechos, etc. Cada fichero usado en el sistema se apareja con una nica entrada de inode en el kernel, la cual describe diferentes atributos y propiedades del archivo al que corresponde.

2.3 PRINCIPALES MECANISMOS DEL KERNEL

2.3.1 Seales

Desde los primeros sistemas UNIX, esta caracterstica ha sido un de las que ms ventajas le han aportado: el uso de seales. stas son usadas por el kernel para informar a los procesos sobre ciertos eventos, lo que permite abortarlos o cambiarlos de un estado a otro. Todas estas seales son enviadas con la funcin send_sig(), la cual admite el paso de tres parmetros, siendo stos: el numero de la seal, una descripcin del proceso que va a recibir la seal (o mejor dicho, un puntero a la entrada del proceso en cuestin en la tabla de procesos), y opcionalmente la prioridad del proceso que enva la seal. Este ltimo argumento puede tener dos valores: desde el kernel, el cual puede enviar seales a cualquier proceso, o desde un proceso, para lo que es necesario que ste ltimo tenga derechos de superusuario, o bien que tener el mismo UID y GID que el proceso al que se le enva la seal.

2.3.2 Tuberas

Las tuberas o pipes (... | ...) son unos enlaces que se pueden realizar con cualquier shell, que unen las entradas de algunos programas con las salidas de los otros. Gracias a esto es posible usar gran parte de los comandos de Linux como filtros y, as, construir comandos ms potentes a partir de comandos sencillos. Estas pipes, son consideradas como el mtodo clsico de comunicacin entre procesos. Otra variante de las tuberas son los FIFOs (First In, First Out), que se diferencian de las anteriores en que los FIFOs no son objetos temporales, sino que ellos pueden ser establecidos en un sistema de ficheros.

2.3.3 Interrupciones

Las interrupciones son usadas para permitir al hardware comunicarse con el sistema operativo. En Linux hay dos tipos de interrupciones: rpidas y lentas. Se podra decir que son tres tipos, considerando el tercero como las llamadas del sistema, tambin desencadenadas por interrupciones. 1. Interrupciones lentas: Son las ms usuales. Se caracterizan porque se puede llevar a cabo otras interrupciones mientras stas son tratadas. Despus de que una interrupcin lenta haya sido procesada, otras tareas adicionales, de carcter peridico, son llevadas a cabo por el sistema (como por ejemplo el scheduler). Un ejemplo tpico de interrupcin lenta es la interrupcin del reloj. 2. Interrupciones rpidas: stas se usan para tareas ms cortas y menos complejas que las comentadas en el apartado anterior. Mientras este tipo de interrupciones son llevadas a cabo, el resto de interrupciones son bloqueadas, a menos que la propia rutina en ejecucin las active. Un ejemplo de este tipo de rutinas es la interrupcin de teclado.

En ambos tipos de interrupciones el proceso que se lleva a cabo es muy similar: primero todos los registros son salvados con SAVE_ALL y la interrupcin enva una confirmacin al controlador de interrupciones con ACK. En caso de un sistema con mltiples procesadores, se ejecuta una llamada a la rutina del kernel ENTER_KERNEL para sincronizar el acceso al kernel de los procesadores. Una vez se ha completado la interrupcin, se ejecuta la rutina RESTORE_MOST que devuelve los registros guardados previamente a sus valores iniciales, llamando despus a iret para continuar con el proceso interrumpido.

2.3.4 Iniciando el sistema

LILO es el encargado de encontrar el kernel de Linux y lo carga a la memoria, inicindolo en el punto start:, que es donde se encuentra el cdigo en ensamblador encargado de inicializar el hardware esencial. Una vez esto se ha llevado a cabo, el proceso se cambia a Modo Protegido. La instruccin en ensamblador
jmp 0x1000, KERNEL_CS

inicia un salto a la direccin de comienzo del cdigo de 32 bit para el kernel del sistema operativo actual y continua desde startup_32:. En este punto se inician ms secciones del hardware (en particular el MMU, el co-procesador y la tabla de descripciones de interrupciones) y el entorno requerido para la ejecucin de funciones en C. Una vez esto

se ha llevado a cabo, la primera funcin en C, start_kernel(), es llamada, la cual salvar todos los datos que el cdigo ensamblador ha encontrado sobre el hardware hasta este punto. Entonces se inicializan todas las reas del kernel.
asmlinkage void start_kernel(void) { memory_start = paging_init(memory_start,memory_end); trap_init(); init_IRQ(); sched_init(); time_init(); parse_options(command_line); init_modules(); memory_start = console_init(memory_start,memory_end); memory_start = pci_init(memory_start,memory_end); memory_start = kmalloc_init(memory_start,memory_end); sti(); memory_start = inode_nit(memory_start,memory_end); memory_start = file_table_init(memory_start,memory_end); memory_start = name_cache_init(memory_start,memory_end); mem_init(memory_start,memory_end); buffer_init(); sock_init(); ipc_init(); ...

El proceso actualmente en curso es el proceso 0, el cual ejecuta la funcin init(), que ser la encargada de llevar a cabo el resto de la inicializacin, cargando los demonios bdflush y kswap. Entonces se hace una llamada a setup, que ser la encargada de montar el sistema de archivos root.

2.3.5 Interrupcin del Reloj

Todos los sistemas operativos necesitan una forma de medir el tiempo y de mantener una hora en el sistema. El sistema de medida se implementa normalmente haciendo interrupciones en intervalos ya predefinidos. Bajo Linux, el tiempo se mide en ticks desde que el sistema es arrancado. Un tick representa 10 milisegundos, as que la interrupcin del reloj se efecta 100 veces por segundo. El tiempo se almacena en la variable
unsigned long volatile jiffies;

la cual deber ser modificado nicamente por esta interrupcin. Sin embargo, este mtodo provee solo de un base interna de tiempo.

La interrupcin del reloj es llamada relativamente a menudo y, por eso, es un tanto dependiente del tiempo. La rutina de interrupcin en la versin 2.0, simplemente actualiza la variable jiffies y marca como activa una parte de la interrupcin del reloj, la cual es llamada por el sistema ms adelante, y se desarrolla el resto del trabajo. Como pueden ocurrir varias interrupciones de reloj antes de activar el resto de rutinas, la interrupcin del reloj tambin puede incrementar las variables
unsigned long lost_ticks; unsigned long lost_ticks_system;

para que as estas puedan ser evaluadas al final de la rutina. lost_ticks cuenta las interrupciones de reloj producidas desde la ultima activacin; lost_ticks_system cuenta, en cambio el numero de interrupciones transcurridas mientras el proceso de interrupcin estaba en Modo de Sistema. A mi parecer opino que un comentario ms extenso de este apartado se sale excesivamente del ideal de este apartado, que no es ms que una leve introduccin al funcionamiento de los algoritmos y procesos ms importantes usados en el kernel. Si alguien quiere ms informacin sobre ste, o algunos de los apartados incluidos en el punto 3.3,le aconsejo que consulte el libro [BBD+97], captulo 3, el nico inconveniente es para aquellos que no se desenvuelvan bien con el ingls, aunque si alguien est interesado es un muy buen libro para conocer el funcionamiento del kernel con mayor precisin.

2.4 EL SISTEMA DE ARCHIVOS DE LINUX

Actualmente es normal encontrar un PC con su disco duro con distintas particiones, cada una de ellas con un sistema de ficheros distinta. Esta variedad es debida a que prcticamente cada sistema operativo tiene su propio sistema de ficheros, alegando que ste es ms rpido y seguro que el resto. Puede que una de las razones por las que Linux ha tenido tanta popularidad, sea por la cantidad de sistemas de ficheros distintos que soporta (FAT16 y FAT32 de Windows, NTFS de WinNT, HPFS de OS/2, ISO 9660 y Joliet, que son los estndares ms comunes en CD, etc.). El soporte de esta gran cantidad de sistema de ficheros es debido a la interfaz unificada que usa el kernel llamada Virtual File System Switch (VFS) o ms sencillamente Virtual File System. Este sistema virtual de ficheros es el encargado de cada proceso pueda manejar informacin desde los distintos ficheros sin necesidad de saber donde se encuentran, o de saber si pertenecen a un tipo de sistema de ficheros u otro. Toda la informacin obtenida en este apartado ha sido obtenida a partir del libro [BBD+97] y de la pgina web [Rusling98], los cuales recomiendo para todo aquel que

est interesado en profundizar en este tema. Como nota comentar que, como ya hemos dicho antes, [BBD+97] est en ingls, y la web [Rusling98] aunque el original est en ingls, se puede encontrar una traduccin al castellano, aunque en estas fechas (Mayo 2000) se encuentra en fase de desarrollo, por lo que hay secciones traducidas parcialmente, as como tambin otras no traducidas.

2.4.1 Conocimientos bsicos

La CPU no es el nico elemento "inteligente" que existe en la computadora. Cada elemento hardware que la compone lleva incluido su propio controlador (por ejemplo el ratn y el teclado son controlados por el chip SuperIO, el disco IDE por el controlador IDE o el SCSI por la controladora SCSI). Esto implica que el acceso a cada uno de estos dispositivos se realizar de forma distinta, por lo que cada utilidad debera incluir unos controladores. En vez de eso, los controladores se incluyen en el kernel como unas libreras conocidas como device drivers (controlador de dispositivo), de tal forma que se puede acceder a todos los dispositivos as configurados, sin necesidad de conocer cmo funciona el dispositivo a bajo nivel. De esta forma se consigue una abstraccin en lo que se refiere al acceso a dispositivos. En Linux, como en Unix, a los distintos sistemas de ficheros que el sistema puede usar no se accede por identificadores de dispositivo (como un nmero o nombre de unidad) pero, en cambio se combinan en una estructura jerrquica de rbol que representa el sistema de ficheros como una entidad nica y sencilla. Linux aade cada sistema de ficheros nuevo en este rbol de sistemas de ficheros cuando se monta. Todos los sistemas de ficheros, de cualquier tipo, se montan sobre un directorio y los ficheros del sistema de ficheros son el contenido de ese directorio. Este directorio se conoce como directorio de montaje o punto de montaje. Cuando el sistema de ficheros se desmonta, los ficheros propios del directorio de montaje son visibles de nuevo. Adems, gracias a esta forma de trabajo, no es necesario implementar el cdigo necesario para acceder a los distintos dispositivos, sino que cada proceso se comunica con los dispositivos que necesite a travs del acceso que le es proporcionado a travs del VFS, como se puede observar en la figura siguiente.

Figura 4 - Estructura del VFS El primer sistema de ficheros diseado especficamente para Linux, el sistema de Ficheros Extendido, o EXT, fue introducido en Abril de 1992 y solvent muchos problemas pero era an falto de rapidez. As, en 1993, el Segundo sistema de Ficheros Extendido, o EXT2, fue aadido al kernel como sistema principal de ficheros. En ese momento un importante desarrollo tuvo lugar en Linux. El sistema de ficheros real se separ del sistema operativo y servicios del sistema a favor de un interfaz conocido como el Sistema de Ficheros Virtual, o VFS. VFS permite a Linux soportar muchos, incluso muy diferentes, sistemas de ficheros, cada uno presentando un interfaz software comn a travs del VFS. Todos los detalles del sistema de ficheros de Linux son traducidos mediante software de forma que todo el sistema de ficheros parece idntico al resto del kernel de Linux y a los programas que se ejecutan en el sistema. La capa del sistema de Ficheros Virtual de Linux permite al usuario montar de forma transparente diferentes sistemas de ficheros al mismo tiempo. El sistema de Ficheros Virtual est implementado de forma que el acceso a los ficheros es tan rpido y eficiente como sea posible. Tambin debe asegurar que los ficheros y los datos que contiene son correctos. Estos dos requisitos pueden ser incompatibles entre si. El VFS de Linux mantiene una antememoria con informacin de cada sistema de ficheros montado y en uso. Se debe tener mucho cuidado al actualizar correctamente el sistema de ficheros ya que los datos contenidos en las antememorias se modifican cuando se crean,

escriben y borran ficheros y directorios. Si se pudieran ver las estructuras de datos del sistema de ficheros dentro del kernel en ejecucin, se podra ver los bloques de datos que se leen y escriben por el sistema de ficheros. Las estructuras de datos, que describen los ficheros y directorios que son accedidos serian creadas y destruidas y todo el tiempo los controladores de los dispositivo estaran trabajando, buscando y guardando datos. La antememoria o cach ms importantes es la llamada Buffer Cache, que est integrada entre cada sistema de ficheros y su dispositivo de bloque. Tal y como se accede a los bloques se ponen en el Buffer Cache y se almacenan en varias colas dependiendo de sus estados. El Buffer Cache no slo mantiene buffers de datos, tambin ayuda a administrar el interfaz asncrono con los controladores de dispositivos de bloque.

2.4.2 El Virtual File System

Como en el sistema de ficheros EXT2, cada fichero, directorio y dems se representan en el VFS por un y slo un inodo VFS. La informacin en cada inodo VFS se construye a partir de informacin del sistema de ficheros por las rutinas especficas del sistema de ficheros. Los inodos VFS existen slo en la memoria del ncleo y se mantienen en el cach de inodos VFS tanto tiempo como sean tiles para el sistema. Entre otra informacin, los inodos VFS contienen los siguientes campos: 1. device: Este es el identificador de dispositivo del dispositivo que contiene el fichero o lo que este inodo VFS represente, 2. inode number: Este es el nmero del inodo y es nico en este sistema de ficheros. La combinacin de device y inode number es nica dentro del Sistema de Ficheros Virtual, 3. mode: Como en EXT2 este campo describe qu representa este inodo VFS y los permisos de acceso (r-lectura, w-escritura, x-ejecucin para propietario, grupo y otros usuarios), 4. user ids: Los identificadores de propietario, 5. times: Los tiempos de creacin, modificacin y escritura, 6. block size: El tamao de bloque en bytes para este fichero, por ejemplo 1024 bytes, 7. inode operations: Un puntero a un bloque de direcciones de rutina. Estas rutinas son especficas del sistema de ficheros y realizan operaciones para este inodo, por ejemplo, truncar el fichero que representa este inodo. 8. count: El nmero de componentes del sistema que estn usando actualmente este inodo VFS. Un contador de cero indica que el inodo est libre para ser descartado o rehusado, 9. lock: Este campo se usa para bloquear el inodo VFS, por ejemplo, cuando se lee del sistema de ficheros, 10. dirty: Indica si se ha escrito en este inodo, si es as, el sistema de ficheros necesitar modificarlo, 11. file system specific information.

2.4.3 El sistema de ficheros Ext2

El Segundo sistema de ficheros Extendido de Linux ha sido el que mayor xito ha cosechado, siendo bsico en cualquier distribucin de este S.O. Su construccin se basa en que los datos son guardados en bloques, los cuales son, en principio, del mismo tamao, aunque pueden variar de un sistema a otro (ya que esta eleccin del tamao se hace al crear el sistema con mke2fs). Cuando se almacena un fichero, se hace de tal forma que ocupe un nmero entero de bloques, quedando gran parte de la capacidad del ltimo bloque usado bastante desperdiciada, a no ser que el fichero de datos ocupe exactamente un numero de bloques. No todos los bloques del sistema de ficheros contienen datos, algunos deben usarse para mantener la informacin que describe la estructura del sistema de ficheros. EXT2 define la topologa del sistema de ficheros describiendo cada fichero del sistema con una estructura de datos inodo. Un inodo describe que bloques ocupan los datos de un fichero y tambin los permisos de acceso del fichero, las horas de modificacin del fichero y el tipo del fichero. Cada fichero en el sistema de ficheros EXT2 se describe por un nico inodo y cada inodo tiene un nico nmero que lo identifica. Los inodos del sistema de ficheros se almacenan juntos en tablas de inodos. Los directorios EXT2 son simplemente ficheros especiales (ellos mismos descritos por inodos) que contienen punteros a los inodos de sus entradas de directorio. El sistema de ficheros EXT2 divide las particiones lgicas que ocupa en Grupos de Bloque (Block Groups). Cada grupo duplica informacin crtica para la integridad del sistema de ficheros ya sea valindose de ficheros y directorios como de bloques de informacin y datos. Esta duplicacin es necesaria por si ocurriera un desastre y el sistema de ficheros necesitara recuperarse. En el sistema de ficheros EXT2, el inodo es el bloque de construccin bsico; cada fichero y directorio del sistema de ficheros es descrito por un y slo un inodo. Los inodos EXT2 para cada Grupo de Bloque se almacenan juntos en la tabla de inodos con un mapa de bits que permite al sistema seguir la pista de inodos reservados y libres. Un inodo EXT2, entre otra informacin, contiene los siguientes campos: 1. mode: Esto mantiene dos partes de informacin; qu inodo describe y los permisos que tienen los usuarios. Para EXT2, un inodo puede describir un ficheros, directorio, enlace simblico, dispositivo de bloque, dispositivo de carcter o FIFO. 2. owner Information: Los identificadores de usuario y grupo de los dueos de este fichero o directorio. Esto permite al sistema de ficheros aplicar correctamente el tipo de acceso, 3. size: El tamao en del fichero en bytes, 4. timestamps: La hora en la que el inodo fue creado y la ltima hora en que se modific, 5. datablocks: Punteros a los bloques que contienen los datos que este inodo describe. Los doce primeros son punteros a los bloques fsicos que contienen los datos descritos por este inodo y los tres ltimos punteros contienen ms y ms niveles de indireccin. Por ejemplo, el puntero de doble indireccin apunta a un bloque de punteros que apuntan a bloques de punteros que apuntan a bloques de

datos. Esto significa que ficheros menores o iguales a doce bloques de datos en longitud son ms fcilmente accedidos que ficheros ms grandes. Los inodos EXT2 pueden describir ficheros de dispositivo especiales. No son ficheros reales pero permiten que los programas puedan usarlos para acceder a los dispositivos. Todos los ficheros de dispositivo de /dev estn ah para permitir a los programas acceder a los dispositivos de Linux. Por ejemplo el programa mount toma como argumento el fichero de dispositivo que el usuario desee montar. El Superbloque contiene una descripcin del tamao y forma base del sistema de ficheros. La informacin contenida permite al administrador del sistema de ficheros usar y mantener el sistema de ficheros. Normalmente slo se lee el Superbloque del Grupo de Bloque 0 cuando se monta el sistema de ficheros pero cada Grupo de Bloque contiene una copia duplicada en caso de que se corrompa sistema de ficheros. Entre otra informacin contiene: 1. Magic Number: Esto permite al software de montaje comprobar que es realmente el Superbloque para un sistema de ficheros EXT2. Para la versin actual de EXT2 ste es 0xEF53. 2. Revision Level: Los niveles de revisin mayor y menor permiten al cdigo de montaje determinar si este sistema de ficheros soporta o no caractersticas que slo son disponibles para revisiones particulares del sistema de ficheros. Tambin hay campos de compatibilidad que ayudan al cdigo de montaje determinar que nuevas caractersticas se pueden usar con seguridad en ese sistema de ficheros, 3. Mount Count and Maximum Mount Count: Juntos permiten al sistema determinar si el sistema de ficheros fue comprobado correctamente. El contador de montaje se incrementa cada vez que se monta el sistema de ficheros y cuando es igual al contador mximo de montaje muestra el mensaje de aviso maximal mount count reached, running e2fsck is recommended, 4. Block Group Number: El nmero del Grupo de Bloque que tiene la copia de este Superbloque, 5. Block Size: El tamao de bloque para este sistema de ficheros en bytes, por ejemplo 1024 bytes, 6. Blocks per Group: El nmero de bloques en un grupo. Como el tamao de bloque ste se fija cuando se crea el sistema de ficheros, 7. Free Blocks: EL nmero de bloques libres en el sistema de ficheros, 8. Free Inodes: El nmero de Inodos libres en el sistema de ficheros, 9. First Inode: Este es el nmero de inodo del primer inodo en el sistema de ficheros. El primer inodo en un sistema de ficheros EXT2 raz seria la entrada directorio para el directorio '/'.

2.4.4 Sistema de Ficheros Proc

El sistema de ficheros /proc muestra realmente la potencia del Sistema Virtual de Ficheros. Este sistema no existe en realidad. ste como el resto de sistemas de ficheros, se registra en el VFS. Sin embargo, cuando el VFS hace llamadas al /proc, ste crea los

ficheros que le son pedidos con informacin sobre el kernel. Por ejemplo la llamada al fichero /proc/devices genera a partir de las estructuras del kernel, un archivo describiendo sus dispositivos. El sistema de ficheros /proc representa una ventana hacia el interior del kernel.