Análisis del Sistema Operativo BSD4.4 (Berkeley Software Distributions 4.4) UNIX

Indice1. Objetivo del Software 2. Arquitectura 3. Componentes 4. Comunicación entre procesos 5. La administración de los procesos y el procesador 6. Coordinación y sincronización de procesos 7. Administración de memoria 8. La administración de los archivos 9. La seguridad y protección 10. Conclusión final del trabajo 11. Referencia Bibliográfica

1. Objetivo del Software

El sistema UNIX ha sido usado ampliamente por mas de 28 años, y ha ayudado a definir muchas áreas de computación. Numerosas organizaciones han contribuido y todavía contribuyen al desarrollo del sistema UNIX.

• El sistema UNIX se invento en los Laboratorios Bell
• El Grupo de Investigación de Sistemas de Computo (CSRG) en la Universidad de California en Berkeley, le dio memoria virtual a UNIX y la implementación de referencia de TCP/IP.

Diseño de Software Berkeley, Incorporado (BSDI), El Proyecto FreeBSD, y El Proyecto NetBSD continúan con los trabajos empezados por el CSRG. El BSD4.4 amplió la base de hardware del BSD4.3, y ahora soporta numerosas arquitecturas, incluyendo Motorola 68000, Sun de SAPARC, MIPS, y PCs de Intel. Remedia varias deficiencias del BSD4.3. En particular el sistema de memoria-virtual necesitado fue completamente reemplazado. Añade una implementación de protocolos de red de la suite ISO, además aumenta y mejora el rendimiento de TCP/IP. El manejador de terminal ha sido cuidadosamente conservado compatible no solamente con Séptima Edición (Seventh Edition), sino incluso con Sexta Edición (Sixth Edition). Lo mas critico del BSD4.3 fue la falta de soporte para sistemas de archivo múltiple. El BSD 4.4 incluye una interface orientada a objetos para sistemas de archivos similar al marco de trabajo vnode de Sun. El BSD 4.4 hizo pequeñas extensiones a la interface de socket para permitir la implementación de los protocolos de red ISO.

Quien lo desarrollo. Distribuciones de Software Berkeley (Berkeley Software Distributions) Estos sistemas Berkeley han introducido varios programas y facilidades útiles para la comunidad UNIX.

En que fechas lo desarrollo. La ultima versión de CSRG fue tener dos versiones del BSD 4.4 , para ser liberadas en Junio de 1993. Una fue para seguir teniendo una distribución tradicional de código fuente y binario total, llamadoBSD4.4-Sobrecargado, que requirió el receptor para tener una licencia de código UNIX. La otra fue para tener un subconjunto del fuente, llamado BSD4.4 Lite, este fue liberado un año mas tarde, en 1994. Y una versión corregida de BSD 4.4 Lite fue distribuida en Junio de 1995.

Características principales.

• Soporta numerosas arquitecturas (Motorola 68000, Sun SPARC, MIPS, y PCs de Intel.
• Sistema de memoria-virtual reemplazado y mejorado.
• implementación de protocolos de red en la suite ISO.
• Mejoramiento de la funcionalidad de TCP/IP.
• Manejador de terminal compatible con Sexta y Séptima Edición.
• Interface orientada a objetos para sistemas de archivos, soporta sistemas de archivo múltiples locales y remotos.
• Soporta numerosos tipos de sistemas de archivos, incluyendo : Loopback, Unión, y capas de mapeo uid/gid. Además un sistemas de archivos ISO9660 útil para CDROMs.
• Soporta Sistema de Archivos de Red(NFS) de Sun Versión 2 y 3 y un sistema de archivo lógico estructurado basado en disco.
• Pequeñas extensiones para la interface de sockets para permitir la implementación de los protocolos ISO.

Que impacto ha tenido Mucho del trabajo de desarrollo de Berkeley fue hecho en respuesta a la comunidad de usuarios. Expectativas e ideas vinieron no solo de DARPA, la organización principal directamente fundadora, sino también de usuarios del sistema en compañías y universidades de todo el mundo. Los investigadores de Berkeley aceptaron no solo ideas de la comunidad de usuarios, sino también a usuarios del software actual. Contribuciones al BSD 4 vinieron de universidades y otras organizaciones en Australia, Canadá, Europa y los Estados Unidos. Estas contribuciones incluyeron características de importancia, tales como auto configuración y tiempos de disco. Berkeley solicito correo electrónico para corregir bugs y propuestas. La casa de software MT XINU de UNIX distribuyo una lista de bugs compilados de ese correo. Muchos de los bugs corregidos fueron incorporados en distribuciones posteriores. Hay una constante discusión de UNIX en general (incluyendo el BSD 4.4) en el grupo de noticias USENET comp.unix, los cuales son distribuidos en la Internet; ambos la Internet y la USENET son de alcance internacional. Existe otro grupo de noticias USENET dedicado a los bugs del BSD 4: comp.bugs.4bsd. Después, fue creado un grupo de noticias moderado dedicado a las correcciones CSRG-sancionado para tales bugs, llamado comp.bugs.4bsd.bug-fixes.

2. Arquitectura

El kernel del BSD4.4 provee 4 características básicas: Procesos, un sistema de archivos, comunicaciones, y un sistema de arranque.

• Procesos:

Constituye un hilo de control en un espacio de dirección. Cuenta con mecanismos para crear, terminar y controlar procesos. El sistema múltiplexa espacios separados de dirección – virtual para cada proceso.

• Sistema de archivos

El conjunto de archivos es un conjunto de archivos nombrados, organizados en una estructura de árbol jerárquico de directorios, y de operaciones para manipularlos. Los archivos residen en un medio físico tal como discos. El BSD 4.4 soporta varias organizaciones de datos en disco. Acceso a archivos en maquinas remotas. Las terminales son usadas para acceder el sistema.

• Comunicaciones

Los mecanismos de comunicación proporcionados por sistemas tradicionales de UNIX incluye flujo simple de byte confiable entre procesos relacionados, y notificación de eventos excepcional, el BSD4.4 también tiene una característica general de comunicación – ínter procesos. Esta característica usa mecanismos de acceso distintos del sistema de archivo, pero una vez que una conexión se hace, un proceso puede accesarla como si fuera una conexión directa (pipe). Existe un marco general de red, que es normalmente usado como una capa por debajo de la característica IPC( Interprocessing comunications).

• Sistema de arranque

Cualquier sistema operativo real tiene asuntos operacionales, tales como, como arrancarlo y ponerlo en operación. Sistema operativo base El sistema operativo base como se ha insinuado antes es el UNIX, del cual la primer versión fue desarrollado en los Laboratorios Bell en 1969 por Ken Thompson como un proyecto de investigación privado para usar una de otra manera ociosa PDP-7. Pronto Dennis Ritchie se unió a Thompson, quien no solo contribuye al diseño e implementación del sistema, sino que también invento el lenguaje de programación C. El sistema fue completamente reescrito en C, dejando muy poco lenguaje ensamblador.

Plataforma en la que trabaja El BSD4.4 amplió la base de hardware del BSD4.3, y ahora soporta numerosas arquitecturas, incluyendo Motorola 68000, Sun de SAPARC, MIPS, y PCs de Intel.

3. Componentes

Podemos ver la organización del Kernel del BSD 4.4 en dos formas.

1. Como un cuerpo estático de software, categorizado por la funcionalidad ofrecida por los módulos que componen el kernel.
2. Por su operación dinámica, categorizada de acuerdo a los servicios proporcionados a los usuarios.

La parte mas larga de las implementaciones del Kernel los servicios del sistema que las aplicaciones accedan a través de llamadas al sistema. En BSD 4.4, este software ha sido organizado de acuerdo a lo siguiente:

• Facilidades básicas del kernel:

Manejo del timer y del reloj del sistema, administración de descriptor y administración de procesos.

• Soporte de administración – de memoria:

Paginación e intercambio.

• Interfaces del sistema genéricas:

Las Entradas/Salidas, control, y operaciones de multiplexado ejecutadas en descriptores.

• El sistema de archivos:

Archivos, directorios, conversión de nombres de ruta, bloqueado de archivo, y administración de Entradas / salidas del buffer.

• Soporte para manejo de terminal:

El manejador de interface – de – terminal y las disciplinas de terminal en línea.

• Facilidades de comunicación – ínter procesos:

Sockets

• Soporte de comunicación de red:

Protocolos de comunicación y facilidades genéricas de red, tal como encaminado. Mas del software en estas categorías es independiente de maquina y es portable en diferentes arquitecturas de hardware. Los aspectos dependientes-de-maquina del kernel son aislados del código principal. En particular, ninguno del código independiente-de-maquina contiene código condicional para una arquitectura especifica. Cuando una acción dependiente-de-arquitectura es necesitada, el código independiente-de-maquina llama una función dependiente-de-arquitectura que es localizada en el código dependiente-de-maquina. El software que es dependiente de maquina incluye:

• Acciones de sistema-de-arranque de bajo nivel.
• Manejo de fallas y trampas.
• Manipulación de bajo nivel del contexto en tiempo de ejecución de un proceso.
• Configuración e inicialización de dispositivos de hardware.
• Soporte de tiempo de ejecución para dispositivos de Entrada/Salida.

Tabla

Software independiente de maquina en el kernel BSD 4.4.

Tabla

Software dependiente de maquina para la HP300 en el kernel BSD 4.4.

Aplicaciones

El sistema UNIX corre en computadoras desde sistemas de casa personales hasta grandes supercomputadoras. Es el sistema operativo de selección para sistemas multiprocesador, gráficos, y procesamiento de vector, y es ampliamente usado para su propósito original de compartimento de tiempo. Es la plataforma mas común para proveer servicios de red (desde FTP hasta WWW) en la Internet. Es el sistema operativo mas portable jamas desarrollado.

4. Comunicación entre procesos

La comunicación entre procesos en BSD 4.4 es organizada en Dominios de Comunicación. Los dominios actualmente soportados incluyen:

• Dominio Local

Para comunicación entre procesos ejecutándose en la misma maquina

• Dominio de Internet

Para comunicación entre procesos usando la suite de protocolos TCP/IP (quizás dentro de la Internet)La familia de protocolos para comunicación entre sitios requeridos para correrlos.

• El dominio XNS

Para comunicación entre procesos usando los protocolos de Sistemas de Red XEROX (XNS: XEROX Network Systems) Dentro de un dominio, la comunicación toma lugar entre puntos finales de comunicación conocidos como Sockets. La llamada al sistema de Socket crea un socket y regresa un descriptor. Cada Socket tiene un tipo que define su semántica de comunicación; esta semántica incluye propiedades tales como confiabilidad, ordenación, y prevención de duplicación de mensajes. Cada Socket tiene asociado con el un Protocolo de Comunicación. Este protocolo proporciona la semántica requerida por el Socket de acuerdo con los tipos mas recientes. Las aplicaciones pueden requerir un protocolo especifico cuando crea un Socket, o puede permitirle al sistema seleccionar un protocolo que sea apropiado para el tipo de socket que ha sido creado. Los Sockets pueden tener direcciones consecutivas. La forma y significado de direcciones de socket son dependientes del Dominio de Comunicación en el cual el socket es creado. Comprometer un nombre a un socket en el Dominio Local causa la creación de un archivo en el sistema de archivos. Datos normales transmitidos y recibidos a través de socket son sin tipo. Asuntos de representación de datos son la responsabilidad de librerías construidas en la parte superior de las facilidades de Comunicación – ínter procesos. Además de la transportación de datos normales, los Dominios de Comunicación pueden soportar la transmisión y recepción de especialmente datos con tipo, Derechos de Acceso establecidos. El Dominio Local por ejemplo, usa esta prestación para pasar descriptores entre procesos. Implementaciones de red en UNIX antes del BSD 4.2 usualmente trabajan sobrecargando las interfaces de dispositivo de carácter. Una meta de la interface de socket fue para programas ingenuos para ser capaz de trabajar sin cambio en conexiones de estilo – flujo. Tales programas pueden trabajar solamente si las llamadas de sistemas de Lectura y Escritura son incambiables. Consecuentemente, las interfaces originales fueron dejadas intactas, y fueron hechas para trabajar sobre socktes tipo flujo. Una nueva interface fue añadida para sockets mas complicados, tales como los usados para envía datagramas, con los cuales una dirección de destino debe ser presentada con cada llamada send. Otro beneficio es que la nueva interface es altamente portable. Poco después una edición de prueba estuvo disponible desde Berkeley, la interface de socket había sido portada a System III por proveedor de UNIX. La interface de socket fue también portada para correr en muchas tarjetas Ethernet de proveedores, tales como Excelan e Interlan, que fueron vendidas en el mercado de Pcs, donde las maquinas fueron muy pequeñas para correr redes en el procesador principal. Mas recientemente, la interface de socket fue usada como la base para la interface de red Winsock de Microsoft para Windows.

5. La administración de los procesos y el procesador

Un Proceso es un programa en ejecución. Un proceso debe tener recursos del sistema, tal como memoria y la CPU. El Kernel soporta la ilusión de ejecución de concurrencia de múltiple procesos planificando los recursos del sistema entre el conjunto de procesos que están listos para ejecutarse. Un proceso tiene su propia composición, se usa un método para switchear entre procesos, y existen políticas de planificación que se usan para compartir la CPU. Los procesos se crean y se terminan, existen prestaciones de señal y prestaciones para la depuración de procesos. Un proceso opera de dos modos modo usuario (user mode) o modo kernel (kernel mode). En modo usuario un proceso ejecuta código de aplicación con la maquina en un modo de protección no privilegiado. Cuando un proceso solicita servicios del sistema operativo con una llamada al sistema, el proceso switchea del modo de protección privilegiado de la maquina vía un mecanismo protegido, y después opera en modo kernel. Los recursos usados por un proceso son similarmente divididos en dos partes. Los recursos necesitados para ejecución en modo usuario son definidos por la arquitectura de CPU y típicamente incluye registros de propósito general de CPU, el contador de programa, el registro del estado de procesador, y registros relacionados con la pila, así como el contenido de los segmentos de memoria que constituye la noción del BSD 4.4 de un programa (en texto, datos, y segmentos de pila). Los recursos del modo kernel incluyen los requeridos por el hardware fundamental (tal como registros, contador de programa, y apuntador de pila) y por el estado requerido por el kernel del BSD4.4 para proveer servicios de sistemas para un proceso. Este Estado del Kernel incluye parámetros para llamadas al sistema actual, la identidad de usuario del proceso actual, información de planificación, y así sucesivamente. El estado de kernel para cada proceso es dividido en varias estructuras de datos separadas, con dos estructuras primarias : La Estructura de Proceso y la Estructura de Usuario. La Estructura de Proceso contiene información que debe siempre permanecer residente en memoria principal, junto con referencias a un numero de otras estructuras que permanecen residentes; donde la estrucutra de usuario contiene informacion que necesita estar residente solo cuando el proceso esta ejecutando (aunque las estructuras de usuario de otros procesos tambien pueden estar residente). Las Estructuras de Usuario son ubicadas dinámicamente por medio de las prestaciones de administración de memoria. Históricamente, mas de la mitad del estado de proceso fue almacenado en la estructura de usuario. En el BSD 4.4, la estructura de usuario es usada solamente para la pila de kernel por proceso y un par de estructuras que son referenciadas desde la estructura de proceso. Las Estructuras de Proceso son ubicadas dinámicamente como parte de creación de proceso, y son liberadas como parte del proceso de salida.

6. Coordinación y sincronización de procesos

La sincronización entre procesos del usuario de un recurso típicamente es implementada por la asociación con el recurso de dos banderas; la bandera locked y la bandera wanted. Cuando un proceso quiere usar un recurso, primero checa la bandera locked. Si el recurso actualmente no esta en uso por otro proceso, esta bandera no debería estar activada, y el proceso puede simplemente activar la bandera locked y usar el recurso. Si el recurso esta en uso, el proceso activaría la bandera wanted y llamar la función sleep() con un canal de espera asociado con el recurso ( típicamente la dirección de la estructura de datos usada para describir el recurso). Cuando un proceso ya no necesita el recurso, limpia la bandera locked y, si la bandera wanted esta activa, invoca la función wakeup() para despertar todos los procesos que llamaron la función sleep() para esperar el acceso al recurso.

Las rutinas que corren en la primer mitad del kernel no tienen un contexto y consecuentemente no puede esperar que un recurso se vuelva disponible llamando la función sleep(). Cuando la segunda mitad del kernel accesa recursos que son compartidos con la primer mitad del kernel, no puede usar la bandera locked para asegurar uso exclusivo. En su lugar, debe prevenir la primer mitad de no correrlo mientras esta usando el recurso. Acceso de sincronización con rutinas que se ejecutan en la primer mitad del kernel requiere conocimiento de cuando estas rutinas pueden correr. Aunque las prioridades de interrupción son dependiente de maquina, la mayoría de las implementaciones del BSD 4.4 las ordenan de acuerdo a la siguiente tabla.

Tabla Asignaciones de prioridad de interrupciones, ordenados desde lo mas bajo hasta lo mas alto.

Para bloquear rutinas de interrupción a un cierto nivel de prioridad y por debajo de este, una sección critica debe hacer una llamada apropiada de set-priority-level (establecer nivel de prioridad). Todas las llamadas a set-priority-level regresan el nivel de prioridad previo. Cuando la sección critica es hecha, la prioridad es regresada a su nivel previo usando splx( ). Por ejemplo, cuando un proceso necesita manipular una cola de datos de una terminal, el código que acesa la cola es escrita en el siguiente estilo: s = spltty ( ); /* eleva la prioridad al bloque de procesamiento tty */ . . . /* manipula el tty */ splx(s); /*reestablece el nivel de prioridad al valor previo*/

Los procesos deben cuidar evitar bloqueo mutuo cuando busquen múltiples recursos. Suponga que dos procesos, A y B, requieren acceso exclusivo a dos recursos, R1 y R2, para hacer alguna operación. Si el proceso A adquiere R1 y el proceso B adquiere R2, entonces un bloqueo mutuo ocurre cuando el proceso A trata de adquirir R2 y el proceso B trata de adquirir R1. Ya que un proceso de BSD4.4 ejecutándose en modo kernel nunca es sustituido por otro proceso, protección de recursos múltiples es simple, aunque debe llevarse a cabo cuidadosamente. Si un proceso sabe que múltiples recursos son requeridos para hacer una operación, entonces el proceso puede seguramente proteger uno o mas de esos recursos en cualquier orden, si y solo si el proceso nunca renuncia el control del CPU. Si, como sea , un proceso no puede adquirir todos los recursos que este necesita, entonces este debe liberar algunos recursos que tiene antes de llamar a sleep( ) para esperar que el recurso inaccesible actualmente este disponible. Alternativamente, si los recursos pueden ser parcialmente ordenados, es necesario solamente que estén ubicados en un orden creciente. Por ejemplo, como la rutina namei( ) recorre el espacio de nombre del sistema de archivos, debe proteger el siguiente componente de una ruta de acceso antes de renunciar al componente actual. Un ordenamiento parcial de componentes de rutas de acceso existe desde la raíz del espacio de nombre hasta las hojas. Por lo tanto traducciones del árbol de nombres pueden solicitar un bloqueo en el siguiente componente sin preocuparse por el bloqueo mutuo. Como sea, cuando esta recorriendo arriba el árbol de nombres (p.e. siguiendo un componente de ruta de acceso de punto-punto (..)), el kernel debe cuidar evitar dormir mientras mantiene algunos bloqueos. Elevar el nivel de prioridad del procesador para protegerse contra actividad de interrupción funciona para una arquitectura uniprocesador, pero no para una maquina multiprocesador de memoria compartida. Similarmente, mucho del kernel del BSD 4.4 implícitamente asume que el procesamiento de kernel nunca se llevara a cabo concurrentemente. Numerosos proveedores (tal como Sequent, OSF/1, AT&T, y Sun Microsystem) han rediseñado el esquema de sincronización y han eliminado la asunción de uniprocesador implícita en el kernel de UNIX estándar, para que UNIX corra en arquitecturas de multiprocesador ajustadamente acopladas.

7. Administración de memoria

Un componente central de cualquier sistema operativo es el sistema de administración de memoria. Como su nombre lo dice, las prestaciones de administración de memoria son responsable de la administración de los recursos de memoria disponible en una maquina. Típicamente estos recursos caen en una moda jerárquica, con tiempos de acceso a memoria inversamente relacionados a su proximidad con la CPU. El sistema de memoria primaria es memoria principal; el siguiente nivel de almacenamiento es almacenamiento secundario o almacenamiento de respaldo.

Procesos y Memoria Cada proceso opera en una maquina virtual que es definida por la arquitectura del hardware donde se ejecuta.

Paginación La traducción de direcciones proporciona la implementación de la memoria virtual decoplando el espacio de direcciones virtual de un proceso desde los espacios de direcciones física de la CPU. Cada pagina de memoria virtual es marcado como residente o no residente en memoria principal.

Algoritmos de Reemplazo La política de reemplazo es el aspecto mas critico de cualquier sistema de paginación. Hay un amplio rango de algoritmos desde los cuales podemos seleccionar en el diseño de una estrategia de reemplazo para un sistema de paginación.

El Modelo de Conjunto-Trabajando El modelo conjunto-trabajando asume que los procesos exhiben una localidad cambiante lentamente de referencia. Por un periodo de tiempo, un proceso opera en un conjunto de subrutinas o lazos, causando que todas sus referencias de memoria se refieran a un subconjunto fijo de su espacio de dirección, denominado el conjunto de trabajo.

Intercambio Intercambio es el termino usado para describir una política de administración de memoria en la cual procesos enteros son movidos hacia y desde el almacenamiento secundario donde la memoria principal esta en suministro corto.

Ventajas de la Memoria Virtual Hay varias ventajas para el uso de memoria virtual en computadoras capaces de soportar esta prestación propiamente. La memoria virtual permite a grandes programas correr en maquinas con configuraciones de memoria principal que son mas pequeñas que el tamaño del programa.

Requerimiento de Hardware para Memoria Virtual Casi todas las versiones de UNIX han requerido alguna forma de hardware de administración de memoria para soportar multiprogramación transparente.

El Sistema de Memoria Virtual del BSD 4.4 El sistema de memoria virtual del BSD4.4 difiere completamente del sistema que fue usado en el BSD4.3 y predecesores. La implementación es basada en el sistema de memoria virtual del Mach 2.0, con actualizaciones tomadas del Mach 2.5 y el Mach 3.0. El sistema de memoria virtual implementa espacios de dirección protegidos dentro de los cuales puede ser mapeado fuentes de datos (objetos) tales como archivos o privados, piezas anónimas de espacio de intercambio. La memoria física es usada como una cache de paginas usadas recientemente de estos objetos, y es administrada por un algoritmo de reemplazamiento -de –pagina global parecido en mucho al del BSD 4.3 El espacio de direcciones virtual de la mayoría de las arquitecturas es dividido en dos partes. Típicamente, los mas altos de 30 a 100 Mbyte del espacio de direcciones es reservado para uso del kernel. El espacio de direcciones restante esta disponible para uso de procesos. En un mapa tradicional de UNIX, el kernel y sus estructuras de datos asociadas residen en la parte alta del espacio de direcciones. El texto inicial y las áreas de datos empiezan en o cerca del principio de la memoria. Típicamente, los primeros 4 o 8 Kbyte de memoria son conservados fuera de los limites del proceso. La razón de esta restricción es para una depuración de programa fácil; indirectamente a travez de un apuntador nulo causara un fallo de direccion invalida, en lugar de leer o escribir el texto de programa. La localización de memoria hecha por el proceso en ejecución usando la rutina de librería malloc( ) (o la llamada al sistema sbrk ) son hechas de la parte que empieza inmediatamente siguiente al área de datos y crece hasta las direcciones mas altas. El vector de argumento y los vectores de ambiente están en la parte mas alta de la porción de usuario del espacio de direcciones. La pila de usuario empieza justo debajo de estos vectores y crece hasta las direcciones mas bajas. En el BSD 4.4 y otros sistemas UNIX modernos que soportan la llamada al sistema mmap, el uso del espacio de direcciones es menos estructurado. Implementación de librerías compartidas pueden ubicar texto o datos arbitrariamente, representar la noción de regiones predefinidas obsoletas. Por compatibilidad, el BSD 4.4 todavía soporta la llamada sbrk que usa malloc ( ) para proveer una región contigua, y el kernel tiene una región de pila diseñada donde localizaciones adyacentes son automáticamente ejecutadas.

A cualquier tiempo, el proceso en ejecución es mapeado dentro del espacio de direcciones virtual. Cuando el sistema decide al contexto cambiar a otro proceso, debe almacenar la información acerca del mapa de direcciones del proceso actual, después cargar el mapeo de direcciones para el nuevo proceso. Los detalles de este mapa de direcciones cambiando son dependientes de arquitectura. Algunas arquitecturas necesitan cambiar solo unos pocos registros de mapeo de memoria que apuntan a la base, y para dar la longitud de las tablas de paginas de memoria residente. Otras arquitecturas almacenan los descriptores de la tablas de paginas en especial RAM estática de alta velocidad. Cambiar estos mapas puede requerir vaciad y recargado de cientos de entradas de mapas. Ambos los procesos de kernel y de usuario usan la misma base de estructuras de datos para la administración de su memoria virtual. Las estructuras de datos usadas para administrar memoria virtual son como sigue: vmspace Estructura que abarca ambas las estructuras dependientes de maquina y las independientes de maquina describiendo un espacio de direcciones de proceso. vm_map Estructura de datos de mas alto nivel que describe es espacio de direcciones virtual del dependiente- de- maquina vm_map_entry Estructura que describe un rango contiguo virtualmente de espacio de direcciones que comparte atributos de protección y herencia. object Estructura que describe una fuente de datos para un rango de direcciones shadow object objeto especial que representa copia modificada de datos originales. vm_page La estructura de datos de mas bajo nivel que representa la memoria física siendo usados por el sistema de memoria virtual.

8. La administración de los archivos

Soporte de sistemas de archivos múltiple Con la expansión de computación de red, se hace deseable soportar ambas sistemas de archivos local y remotos. Para simplificar el soporte de sistemas de archivos múltiple, los desarrolladores añadieron un nuevo nodo virtual o interface vnode para el kernel. El juego de operaciones exportadas desde la interface vnode se parecen mas a las operaciones de sistemas de archivos previamente soportadas por el sistemas de archivos local. Como sea, pueden ser soportadas por un amplio rango de tipos de sistemas de archivos:

• Sistema de archivos basado -en –disco local
• Archivos importados usando una variedad de protocolos de sistema de archivos remoto
• Sistema de archivos de CD-ROM de solo-lectura
• Sistema de archivos que proveen interfaces de propósito especial (Por. Ejemplo, el sistema de archivos /proc)

Algunas variantes del BSD 4.4, tal como FreeBSD, permite al sistema de archivos ser cargado dinámicamente cuando los sistemas de archivos son primero referenciados por la llamada al sistema mount.

Sistema de archivos Un archivo regular es un arreglo lineal de bytes, y pueden ser leídos y escritos empezando por cualquier byte en el archivo. El kernel no distingue limites de registros en archivos regulares, aunque muchos programas reconocen caracteres alimentación-de-línea como distinguir el fin de línea, y otros programas puede usar otra estructura. Ninguna información relacionada con el sistema es conservada acerca de un archivo en el archivo mismo, pero el sistema de archivo almacena una pequeña cantidad de información propietario, protección, y uso con cada archivo.

Un componente del nombre-de-archivo es una cadena de hasta 255 caracteres. Estos nombres de archivo son almacenados en un tipo de archivo llamado un directorio. La información en un directorio acerca de un archivo es llamada entrada-de-directorio e incluye, además del nombre-de-archivo, un apuntador al archivo mismo. Las entradas de directorio pueden referir a otros directorios, también como planear archivos. Por lo tanto una jerarquía de directorios y archivos es formada, y es llamada un sistema-de-archivos. Los Directorios pueden contener, y no hay limitaciones inherentes a la profundidad con lo cual anidamientos de directorios pueden ocurrir. Para proteger la consistencia del sistema-de-archivos, el kernel no permite a los procesos escribir directamente en los directorios. Un sistema-de-archivos puede incluir no solo archivos planos y directorios, sino también referencias a otros objetos, tales como dispositivos y sockets. El sistema-de-archivos forma un árbol, e principio del cual es el directorio raíz, algunas veces referidas por el nombre slash, representado por un carácter sólido (/). El directorio raíz contiene archivos; En el ejemplo, contiene a vmunix, una copia del archivo objeto de kernel-ejecutable. También contiene directorios; ien este ejemplo, contiene el directorio usr. Dentro del directorio usr esta el directorio bin, el cual principalmente contiene código objeto ejecutable de programas, tales como los archivos ls y vi.

Un proceso identifica un archivo especificando la ruta-de-acceso del archivo, la cual es una cadena compuesta de cero o mas nombres-de-archivo separados por el carácter diagonal (/). El kernel asocia dos directorios con cada proceso para uso en la interpretación de rutas-de-acceso. Un directorio-raíz de un proceso es el punto mas arriba en el sistema-de-archivos que el proceso puede acceder; este se activa ordinariamente para el directorio raiz del sistema-de-archivo entero. Una ruta-de-acceso que empieza con una diagonal es llamado una ruta-de-acceso absoluta, y es interpretada por el kernel empezando con el directorio raíz del proceso.

Sistema – de – archivos Local Las operaciones definidas para sistema-de-archivos local son divididas en dos partes. Comunes a todos los sistemas de archivos locales son nombrado jerárquico, buscando, cuotas, administración de atributos, y protección. Estas característica, las cuales son independientes de cómo los datos son almacenados, son provistos de código UFS. La otra parte de los sistemas de archivo local le concierne a la organización y administración de datos en el medio de almacenamiento. El almacenamiento es administrado por las operaciones de sistema-de-archivos del almacén-de-datos. Las operaciones de vnode definidas para hacer operaciones de sistema-de-archivos jerárquicos son mostrados en la siguiente tabla.

Tabla Operaciones de sistema-de-archivos jerárquico

Sistema – de – archivos de red

Cuando redes primero se convirtiendo ampliamente disponible en el BSD 4.2, los usuarios que quisieron compartir archivos lo que tenian que hacer era entrar a través de la red a una maquina central en la cual los archivos compartidos se localizaban. Esta maquina central rápidamente se cargo mas que la maquina del usuario local, por lo tanto la demanda por una forma conveniente de compartir archivos al mismo tiempo en varias maquinas creció rápidamente.

NFS (Network file system) fue diseñado como una aplicación cliente–servidor. Su implementación es dividida en una parte cliente que importa sistemas de archivos desde otras maquinas y una parte servidor que exporta sistemas de archivos locales a otras maquinas. El modelo general es mostrado en la figura enseguida. Muchos metas fueron incluidas en el diseño de NFS:

• El protocolo es diseñado para ser sin estado. Como no hay estado que mantener o recuperar, NFS puede continuar operar incluso durante periodos de fallas de cliente o servidor. Por lo tanto, es mucho mas robusto que un sistema que opera con estado.
• NFS es diseñado para soportar semánticas de sistema-de-archivos de UNIX. Como sea, su diseño también permite soportar la posibilidad de semánticas menos ricas de otros tipos de sistemas de archivos, tal como MS-DOS.
• Los controles de protección y acceso sigue a la semántica de UNIX de tener el presente proceso un UID y un conjunto de grupos que son checados contra el propietario de archivo, grupo, y otros modos de acceso. El chequeo de seguridad es hecha por código dependiente-de-sistema-de-archivos que puede hacer mas o algunos chequeos basado en las capacidades del sistema de archivos que esta soportando. Por ejemplo, el sistema-de-archivos de MS-DOS no puede implementar la validación de seguridad total de UNIX y hace decisiones de acceso solamente basado en la UID.
• El diseño del protocolo es independiente del transporte. Aunque fue originalmente construido usando el protocolo de datagramas UDP, fue fácilmente movido al protocolo de flujos TCP. Este también ha sido portado para correr sobre otros numerosos protocolos no-basados-en-IP.

Algunas de las decisiones de diseño limitan el conjunto de aplicaciones para el cual NFS es apropiado:

• El diseño visiona a los clientes y servidores estar conectados localmente a una red rápida. El protocolo NFS no trabaja bien sobre enlaces lentos o entre clientes y servidores con puertas de acceso. También trabaja pobremente para computación móvil que tiene periodos extendidos de operación desconectados.
• El modelo de obtención (caching) asume que la mayoría de archivos no serán compartidos. La funcionalidad sufre cuando los archivos son compartidos pesadamente.
• El protocolo sin estado requiere algunas perdidas de semánticas de UNIX tradicional. El cerrar sistemas de archivos (flocks) ha de ser implementado por un demonio de estado separado. Aplaza la liberación de espacio en un archivo diferenciado hasta que el proceso final ha cerrado el archivo es aproximado con una heurística que a veces falla.

A pesar de estas limitaciones, NFS ha proliferado porque este hace un razonable trato entre semántica y funcionalidad; su bajo costo de adopcion lo ha hecho ubicuo.

9. La seguridad y protección

NFS no es seguro porque el protocolo no fue diseñado con seguridad en mente. A pesar de esto se intenta fijar problemas de seguridad, la seguridad de NFS es todavía limitado. La encriptación es necesaria para construir un protocolo seguro, pero la encriptación robusta no puede ser exportada desde los Estados Unidos. Por lo tanto, incluso si construir un protocolo seguro fuera posible, hacer eso seria sin sentido, porque todos los archivos de datos son enviados a la red en texto limpio. Incluso si Alguien es incapaz obtener que su servidor para enviarles un archivo sensitivo, pueden solo esperar hasta que un legitimo usuario lo accede, y después pueda recogerlo cuando vaya por la red. El control de exportar de NFS esta en la granularidad del sistema-de-archivo local. Asociado con cada sistema-de-archivo local el punto de montar es una lista de hosts para los cuales ese sistema de archivos puede ser exportado. Un sistema de archivos local puede ser exportado a un especifico host, hacia todos los hosts que coincidan con la mascara de subred, o a todos los otros hosts(el mundo). Por cada host o grupo de host, el sistema de archivos puede ser exportado solo-lectura o solo-escritura. Además, un servidor puede especificar un conjunto de subdirectorios dentro del sistema de archivos que puede ser montado. Como sea, esta lista de puntos de montaje es forzada solo por el demonio mountd. Si un cliente malicioso hacer eso, puede acceder cualquier parte de un sistema de archivos que es exportado al.

La determinación final de exportabilidad es hecha por la lista mantenida en el kernel. Por lo tanto, incluso si un cliente pícaro maneja muy curioso la red y para robar un archivo maneja por un punto de montar de un cliente valido, el kernel rechazara aceptar el manejo de archivo a menos que el cliente presentando ese manejo este en la lista de exportar del kernel. Cuando el NFS este trabajando con TCP, el chequeo es llevado a cabo cuando la conexión es establecida. Cuando el NFS esta trabajando con UDP, el chequeo se lleva acabo por cada solicitud de RPC. El servidor NFS también permite limitado remapeado de credenciales de usuarios. Típicamente la credencial para el súper usuario no es confiado y es remapeado al usuario de bajo privilegio "nadie". Las credenciales de todos los demás usuarios pueden ser aceptadas como dadas o también mapeadas a un usuario por omisión (típicamente"nadie"). El usos de la lista de cliente UID y GID incambiable en el servidor implica que los espacios UID y GID son comunes entre el cliente y el servidor (p.e. el UID N en el cliente debe referir al mismo usuario en el servidor). El administrador de sistema puede soportar mapeos mas complejos de UID y GID usando el sistema de archivos umapfs.

El administrador de sistema puede incrementar seguridad usando credenciales Kerberos, en lugar de aceptar credenciales de usuarios arbitrarios enviados sin encriptación por clientes de confianza desconocida. Cuando un usuario nuevo en un cliente quiere empezar a acceder archivos en un sistema de archivos NFS que es exportado usando Kerberos, el cliente debe proveer un ticket de Kerberos para autenticar el usuario en el servidor. Si hay éxito, el sistema busca el Kerberos principal en las base de datos de grupo y clave de acceso del servidor para obtener un conjunto de credenciales, y pase al servidor nfsd una traducción local del UID del cliente a esas credenciales. Los demonios nfsd corren enteramente dentro del kernel excepto cuando un ticket Kerberos es recibido. Para evitar poner toda la autenticación de Kerberos en el kernel, el nfsd regresa del kernel temporalmente a verificar el ticket usando librerías de Kerberos, y después regresa al kernel con los resultados. La implementación de NFS con Kerberos estampas de tiempo encriptadas para advertir intentos de reenvío. Cada solicitud de RPC incluye una estampa de tiempo que es encriptada por el cliente y desencriptada por el servido usando una clave de sesión que ha sido cambiada como parte de la autenticación inicial de Kerberos. Cada estampa de tiempo puede ser usada solo una vez, y debe ser dentro de algunos minutos del tiempo actual grabado por el servidor. Esta implementación requiere que el reloj del cliente y del servidor se conserven dentro de algunos minutos de sincronización (este requerimiento es ya impuesto para correr Kerberos). También requiere que el servidor conserve copias de todas las estampas de tiempo que ha recibido que están dentro del rango de tiempo que aceptara, para que pueda verificar que una estampa de tiempo no esta siendo rehusada. Alternativamente, el servidor puede requerir que estampas de tiempo desde cada uno de sus clientes sean monótonamente incrementadas. Como sea este algoritmo causara que las solicitudes de RPC que salen de orden sean expulsadas. Este mecanismo de usar Kerberos para autenticación de solicitudes NFS no esta bien definido, y la implementación de BSD 4.4 no ha sido probada para interoperatividad con otros proveedores. Por lo tanto, Kerberos puede ser usado solo entre clientes y servidores de BSD 4.4.

10. Conclusión final del trabajo

El BSD 4.4 debe ser un sistema operativo de principal uso en redes y sistemas distribuidos por su idiosincrasia y funcionalidad en este campo. A lo largo de los años de uso del sistema UNIX, el BSD ha venido aportando conceptos nuevos de gran relevancia para los sistemas usuarios de redes, como lo es el concepto de Socket Se ha demostrado que cada día el BSD avanza en la mejora, prueba de ello es que en la actualidad soporta mas arquitecturas como lo son la de Motorola 68000 y las PCs de Intel. En la actualidad se trata de eliminar las dependencias de maquina, y vemos que el Kernel del BSD 4.4. va en ese sentido ya que solo el 19.6 % del mismo es dependiente de maquina en el ejemplo dado. Mostrando así su portabilidad. Los Dominios de Comunicación entre procesos es clasificada de manera sencilla aprovechando el concepto de Socket y los protocolos de comunicación. El BSD 4.4 es un sistema operativo muy bien administrado, administra la comunicación entre procesos locales y remotos, la administración de su memoria no es tan diferente de otros sistemas. Conserva la funcionalidad de los sistemas UNIX. Pero aun le falta completar el trabajo de la seguridad. La forma en que lleva a cabo la intercomunicación entre procesos remotos y locales es entendible y funcional. Como los demás sistemas derivados del UNIX, el BSD 4.4 también a tomado ideas de diferentes sistemas, y los ha mejorado desde el punto de vista de las diferentes organizaciones que soportan este sistema como BSD, y otros. Aunque evitar el bloqueo mutuo se debe llevar a cabo de manera cuidadosa, BSD 4.4 proporciona un mecanismo que usándolo correctamente el bloqueo mutuo se puede evitar. El sistema de memoria virtual del BSD 4.4. difiere completamente de sus predecesores, pero es basada en el sistema de memoria virtual del Mach 2.0. Con el uso del nodo virtual o interface vnode para el kernel, el sistema soporta sistemas de archivos múltiple. Es impresionante la forma en que UNIX ha marcado muchos de los sistemas con las iniciativas que se han tenido sobre él, por ejemplo, el MS-DOS se ha basado en él, el concepto de sockets que forma parte del sistema operativo BSD desde la versión 2 ahora se usan librerías para su implementación en diferentes arquitecturas. Por lo tanto esto nos puede decir que el software abierto es más probable que implemente mecanismos de; solución de problemas, de mejoramiento, de adaptabilidad, etc., que el software que no lo es.

11. Referencia Bibliográfica

McKusick, M. K., Bostic, K., Karels, M.J. & Quaterman, J. S. (1996). The design and implementation of the 4.4bsd operating system. [El diseño e implementacion del sistema operativo 4.4bsd]. USA: Addison Wesley.

    Trabajo enviado por: Armando Fausto Flores

Análisis del Sistema Operativo BSD 4.4 (Unix) Cd. Guzmán JaL; 16 de Enero de 2003