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

Indice
1.
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