Bueno, pues bienvenidos a todos a esta segunda parte del tema 5 en
asignatura de ampliación de sistemas operativos y como vimos en la
anterior clase, en la que vimos la primera parte que era la más extensa
del tema, ahora vamos a continuar con la segunda y llegaremos hasta la
quinta parte para finalmente ponernos a realizar un par de ejercicios de
los que vienen al final del libro y que así podamos practicar un poco con
la teoría que hemos visto en estas dos clases, ¿de acuerdo? Entonces,
pues bueno, tenéis aquí en la transparencia el título que tiene esta
segunda parte, le vamos a llamar capa nodo virtual sistema de archivos
virtual, ¿vale? Vamos a hablar un poco sobre esta capa que nos
proporcionan los sistemas operativos basados en UNIX y vamos a ver a qué
se refiere con estos dos términos. Entonces, como el fin de dar soporte a
diferentes tipos de sistemas de archivos, en el año 1985, Zoom
Microsystems, digamos que introdujo en el núcleo de SAM una capa de
software conocida como sistema de archivos virtual, ¿vale? En inglés,
pues es Virtual File System. Lo veréis también un minuto como VPS y
también se denomina, pues, capa nodo virtual nodo V, sistema de archivos
virtual SAV, ¿vale? Debido a su eficiencia, flexibilidad y elegancia, la
capa nodo V o la capa SAP ha sido adoptada por muchos soft UNIX, aunque
cada uno la implementa de distinta forma, ¿vale? Bueno, pues entonces,
¿para qué? Para que sepáis un poco los orígenes de estos términos,
estas capas, y que sepáis qué características tienen, ¿vale? Bueno,
pues una de ellas, la capa nodo V SAP, permite aislar los detalles de la
implementación de cada tipo de sistema de archivos del resto del núcleo.
Entonces, esto, digamos que simplifica su diseño, ¿vale? Cualquier
operación sobre un archivo o sobre un sistema de archivos, o sea, un
sistema de archivos completo invocada por el usuario a través de una
llamada al sistema, o también por algún subsistema del núcleo, es
redireccionada por la capa nodo V SAP hacia la rutina dependiente del
sistema de archivos al que pertenezca el archivo que da soporte a dicha
operación. El núcleo de cada sistema operativo, que se basa en UNIX, debe
disponer, por cada tipo de sistema de archivos, de las rutinas que
implementan las operaciones. En definitiva, que sepáis que la capa nodo V
SAP permite descomponer las operaciones sobre un archivo en dos partes, una
independiente del tipo de sistema de archivos y otra dependiente del tipo
de sistema de archivos. ¿Vale? Pues va a haber una que dependa y otra que
no dependa. La capa nodo V SAP también es la interfaz que permite el paso
entre ambas partes. ¿Vale? Y es también algo muy importante y que
conviene decir en este punto. Aquí tenéis, en esta figura, pues cómo es
esa capa nodo V SAP. ¿Vale? Veis que, por ejemplo, en la opción superior
estaría la interfaz de llamadas al sistema, luego por debajo estarían las
funciones independientes del tipo de sistema de archivos, read, write,
open, mount, y después vendría la capa nodo V SAP, y por debajo de ella,
pues estarían las funciones dependientes de un sistema UPS, las funciones
dependientes de un sistema FAT, funciones dependientes de un sistema ISO
9660, etc. ¿Vale? Y la capa nodo V SAP trabaja con dos tipos de
estructuras de datos básicas. Por un lado los nodos V y por otro lado los
sistemas de archivos virtuales. La implementación y gestión de estas
estructuras depende de cada sistema operativo que se va a asignar. ¿Vale?
Bueno, en cuanto a la primera de estas partes, vamos a ver ahora, por un
lado los nodos virtuales y por otro lado los sistemas de archivos
virtuales. Estamos en el libro, en la página 203, ¿vale? Para que lo
podáis seguir perfectamente. Entonces, en este apartado 5.3.1 vamos a ver
los nodos virtuales. 1. Nodo virtual o nodo V, que es como decíamos que se
abrevia, sería una estructura de datos que representa a un archivo activo.
Muy importante esto, ¿vale? Un archivo activo. El núcleo asigna un nodo V
cuando se crea o se abre un archivo durante el tratamiento de las llamadas
al sistema CREATE y OPEN. ¿Vale? El descriptor del archivo tiene un
puntero de objeto de archivo abierto, el cual tiene a su vez un puntero...
el puntero del nodo V asociado al archivo, ¿vale? Entonces, aquí os viene
un pequeño ejemplo para entender esta teoría. Si dos procesos A y B abren
el mismo archivo, o si el mismo proceso abre dos veces el mismo archivo,
existirán dos descriptores de archivos y dos estructuras de objeto
abiertos distintas, pero solamente habrá una estructura nodo V, que sería
la clave. El nodo V mantiene un concepto de archivo, y el contador de
referencias, como el número de estructuras de datos que lo referen. En
este caso, pues el contador de referencias contendrá el valor 2, ¿vale?
Si un proceso ejecuta una llamada al sistema CLOSE sobre dicho archivo, el
contador de referencias se decrementará en una unidad, ¿vale? Bueno, la
estructura que implementa un nodo V suele contener, entre otros, los
siguientes datos que veis aquí, ¿vale? Vamos a ir analizando cada uno de
ellos. ¿Vale? Un contador de referencias, que indica el número de
estructuras de datos del núcleo que referencian al nodo V. Un tipo de nodo
V, que coincide con el tipo de archivo al que está asociado el nodo V,
archivo regular, directorio, archivo de dispositivo modo bloque, etc.,
¿no? Un puntero o una estructura de datos dependiente del tipo de sistema
de archivos. Esa estructura se denomina normalmente nodo índice, también
lo veréis como nodo I, y la información que contiene... ...depende de
cada tipo de sistema de archivos. Por ejemplo, para un archivo que
pertenezca a un sistema de archivos S5FS o UFS, el nodo I contendría, en
este caso, los atributos del archivo y la localización en el disco de los
bloques de datos del archivo. En este caso también, el nodo I asociado al
archivo al que apunta un nodo V es una copia en memoria principal del nodo
I almacenado en el disco. El tamaño que ocuparía... ...la copia de un
nodo I en memoria principal sería mayor que el tamaño del nodo I en el
disco. Entonces, esto lo voy a subrayar porque es importante. El tamaño
que ocuparía la copia de ese nodo I en memoria principal decíamos que es
mayor que el tamaño del nodo I en el disco. Esto es así porque contiene
más información como, por ejemplo, un puntero nodo V y el número de nodo
I del archivo. ¿Vale? Bueno, también tendríamos un puntero al vector de
operaciones sobre un archivo. Aquí el vector de operaciones sobre un
archivo es un array de punteros o funciones que dependen del tipo de
sistema de archivos al que pertenezca el archivo y decir también que estas
funciones implementan todas las posibles operaciones sobre un determinado
archivo. También por otro lado estaría la lista de páginas del archivo
cargadas en la memoria principal. Esta lista se consultaría cuando el
contador de referencias, de nodo V, tomase el valor cero para localizar y
eliminar de memoria principal las páginas del archivo. Y esto es así
porque el archivo ya no está activo y puede ser eliminado de la memoria
principal. ¿Vale? Bueno, y luego os viene aquí en el libro, en la página
205, un ejemplo, el ejemplo 5.8, que sería un ejemplo de Solaris. ¿Vale?
En el que se implementa con una estructura VNode que contiene pues una
serie de campos, ¿no? El vtype, el vcount, ¿vale? Contador de
referencias, vop, puntero al vector de operadores, punteros a estructura de
datos que dependen del tipo de sistema de archivos, ¿no? El nodo ahí. El
puntero a estructura WPS, un puntero a escritura WPS, una lista de páginas
del archivo cargadas en memoria. Bueno, y tenéis ahí en la figura 5.6 la
imagen que representa un poco de manera gráfica lo que os viene en ese
ejemplo 5.8, ¿no? Entonces echarle un vistazo. Como es algo ya en concreto
pues no lo vamos a ver más detalladamente en clase pero como se basa en
Solaris pues para que tengáis un ejemplo práctico lo podéis mirar
vosotros tranquilamente. ¿Vale? Bueno, y ahora vamos a ver la otra parte.
Hemos visto los nodos. Ahora decíamos que íbamos a ver los sistemas de
archivos virtuales, ¿no? Que es lo que se abreviaba como SAP. Entonces un
sistema de archivos virtual o SAP sería una estructura de datos que
representa a un sistema de archivos activo. Aquí lo importante es saber
que es activo. El núcleo asigna un SAP cuando se monta un sistema de
archivos y lo desasigna cuando lo desmonta. La principal función del SAP
asociado a un sistema de archivos es la de redireccionar las operaciones
que se vayan a realizar sobre el sistema de archivo hacia las rutinas
dependientes del tipo de sistema de archivos que implementan dichas
operaciones. Esa es su principal función. La estructura que implementa un
SAP suele contener entre otros los siguientes datos que habéis visto. Por
un lado, un puntero al siguiente sistema de archivos virtual. El núcleo,
que sepáis que mantiene una lista con todos los SAP montados en un
determinado momento. Un puntero al vector de operaciones sobre el sistema
de archivos. El vector de operaciones sobre un sistema de archivos es un
array de punteros a funciones dependientes del tipo de sistema de archivos
que implementan todas las posibles operaciones sobre el sistema de
archivos. Un puntero a una estructura de datos dependiente del tipo de
sistema de archivos. Y un puntero al nodo V del punto de montaje. También
el tipo de sistema de archivos estaría dentro de esta estructura. Este
tipo de sistema de archivos coincide con el tipo al que está asociado el
SAP y que debe ser alguno de los soportados por el núcleo. Algunos de
estos que tenéis aquí o incluso algún otro. El S5PS, el UPS, el NPS, el
XT2, FAT, etc. También tened en cuenta que cada SAP Units establece los
tipos de sistema de archivos que soporta. Entonces depende de con cual
estéis trabajando en un determinado momento se utilizará un tipo u otro.
Igual que antes, deciros que en la página 207 del libro tenéis el ejemplo
5.9 en el cual también se ve el sistema Solaris y en concreto en este
ejemplo os dice que en Solaris un SAP se implementa con una estructura VCS.
Os pone aquí los campos que tiene esta estructura dentro de Solaris le
podéis echar un vistazo por vuestra cuenta y luego también os viene en la
figura 5.7 la imagen de este ejemplo 5.9. Este ejemplo os quedaría para
que miréis también por vuestra cuenta porque de nuevo voy a hablar sobre
Solaris entonces siempre que nos metamos con alguna tecnología en concreto
os lo dejo para vosotros. Entonces hasta aquí la segunda parte veis que
como os decía en la clase anterior esta parte ha sido mucho más corta que
la primera entonces ahora se va a repetir esta dinámica con las que nos
quedan de este tema 5. Vamos a meternos ahora con la tercera parte en la
cual vamos a analizar los nombres de rutas en un sistema operativo basado
en Unix. Decir que algunas llamadas al sistema como pueden ser open,
create, exec tienen entre sus argumentos de entrada el nombre de ruta
absoluta o relativa de un archivo. Entre esos parámetros que nosotros
introducíamos por ejemplo la llamada open que tenía un nombre determinado
de argumentos pues uno de ellos va a ser el nombre de ruta absoluta o
relativa de un archivo. El núcleo sería el que tiene que analizar dicha
ruta para poder localizar el nodo V del archivo y así poder invocar a la
función dependiente del tipo de sistema de archivos que implementa la
operación de la llamada al sistema. El análisis de cada componente de la
ruta requiere localizar el nodo V de su directorio padre y también buscar
en su lista de archivos y sus directorios la entrada asociada a la
componente. Aquí en el libro en la página 208 os viene un ejemplo muy
interesante sobre este análisis de nombres de ruta. En concreto os hablo
de una ruta absoluta vir1-archivo1 que contiene tres componentes el
directorio raíz lo voy a poner aquí para verlo un poco por encima con
vosotros luego lo podéis seguir mirando con más calma entonces tenemos
esta ruta absoluta vir1-archivo1 que contiene tres componentes el
directorio raíz lo voy a poner en otro color que sería este ya sabéis la
primera barra el directorio vir1 sería esta carpeta de aquí y el archivo
archivo1 vale entonces nos dice que supongamos que el análisis de este
nombre de ruta absoluta se realiza en Solaris de nuevo voy a hacer un
ejemplo que habla sobre Solaris entonces la función del núcleo lookup es
la encargada de analizar un nombre de ruta de un archivo directorio esta
función lee la variable rootdir para localizar el nodo V del directorio
raíz y luego invoca a una operación lookup sobre el nodo V lo que produce
la invocación de la función apropiada que depende del sistema de archivo
entonces bueno también nos dice que suponiendo que se trata de un sistema
de archivos UPS sino que haya la función UPS lookup y nos va pues
profundizando en ese proceso para analizar al completo esa ruta absoluta
podéis echar un vistazo vosotros y al final pues veis que la conclusión
es que se devuelve un puntero al nodo V de esta ruta que tenemos aquí a la
rutina del núcleo que la había invocado y podéis echar un vistazo
vosotros a los pasos intermedios que se producen ya digo dentro de este
sistema Solaris bueno y dicho esto pues en la página siguiente os sigue
hablando de este análisis reducir el número de lecturas el disco y el
tiempo de búsqueda de entradas en directorios los SOVI UNIX implementan
una cache de búsqueda de nombres en director vale se trata de una cache de
estructura de datos que se implementa en el espacio de direcciones del
núcleo cada estructura de datos de la cache contiene estos datos que
tenéis aquí vale sobre todo un puntero al nodo V del directorio y el
nombre y un puntero al nodo V en un archivo o subdirectorio contenido en en
dicho directorio vale cuando el núcleo tiene que buscar la entrada de un
archivo o subdirectorio determinado dentro de la lista de un directorio
primero busca la existencia de dicha entrada en la cache y en caso de
acierto se ahorra el tiempo de leer el disco o el bloque de datos que
contiene la lista del directorio y buscar dentro de la lista en general la
implementación y gestión de esta cache depende de cada subunit vale
también es importante que lo sepáis como siempre lo normal es que incluya
mucho el tipo de sistema operativo que estemos utilizando vale bueno y esa
es la la tercera parte veis también que que fue muy corta vamos ahora con
la cuarta parte de este tema en ella vamos a hablar del sistema de archivos
ucs en primer lugar analizaremos sus características principales ucs
significa unix file system sistema de archivos unix entonces es un sistema
de archivos soportado por diversos subunits como por ejemplo pues solaris
que es el que más hemos venido hasta aquí freebsd y ux el sistema ucs
deriva del sistema de archivos s5fs de bsd el cual en su momento supuso una
auténtica revolución dentro de los subunits porque utilizaban el sistema
de archivo s5fs que tenía limitaciones importantes vale como como
características principales tendríamos estas que os vienen aquí en la
página 209 veis que aparecen bastante vale en primer lugar es decir que
trabaja con un tamaño de bloque de datos de 4 kilobytes o 8 kilobytes
además para reducir la fragmentación interna cada bloque se divide en
fragmentos que pueden ser asignados individualmente de esta forma la
fragmentación interna promedio pasaría de ser de medio bloque a medio
fragmento y tanto el tamaño de bloque como el número de fragmentos 1 2 4
8 se fija al crear el sistema de archivo vale tiene en cuenta la geometría
del disco a la hora de alojar los nodos y los bloques de datos de los
archivos y con ello se consigue mejor el rendimiento del sistema ya que se
reduce el tiempo de búsqueda de las cabezas de lectura escritura del disco
y en consecuencia el tiempo de las operaciones de entrada a salida vale
bueno lo nuevo también por motivos de seguridad mantiene varias copias del
superbloque que es una estructura de de datos que contiene información
administrativa y estadística de todo el sistema de de archivo y si solo
existiese una copia del superbloque como pasaba en los sistemas de archivos
eh s5ps y esta eh se corrompiera debido a algún error en el disco todo el
sistema de archivos quedaría inutilizada vale bueno entonces eh la
estructura de un sistema de archivos ufs la tenéis aquí vale en esta
imagen que os viene en la página eh 211 de de vuestro libro vale eh un
sistema de archivos ufs digamos que presenta la siguiente estructura en la
partición del disco vale esta sería la partición vale y aquí pues es
donde estaría esa esa estructura eh el arranque el superbloque el grupo de
cilindro que que sea vale entonces en un determinado grupo de cilindro
tendríamos eh la copia del superbloque estructura grupo de cilindro mapa
de bits eh nodos i y bloques de datos vale eh tenéis que saber por ejemplo
lo que os viene en la página eh también en esa página 211 vale de la
implementación de directorios en ufs que eh en un sistema de archivos ufs
la lista de archivos y subdirectorios de eh un directorio se implementa con
entradas de tamaño variable vale el número de nodo i la longitud en bytes
de la entrada longitud en bytes del nombre el nombre del archivo un
carácter eh nulo para marcar el final del archivo y los caracteres nulos
de relleno necesarios hasta alcanzar una frontera de 4 bytes el nombre de
archivo en ufs puede tener un tamaño máximo de 255 caracteres vale cuando
se borra una entrada en un directorio excepto si se trata de la primera la
entrada anterior se expande hasta ocupar el espacio que tenía asignado la
entrada borrada esta forma de proceder ayudaría a reducir la
fragmentación vale bueno y ahora os he puesto aquí el ejemplo que os
viene en esa página 211 el ejemplo 5.11 para que veáis como es la
implementación de un directorio en ufs vale entonces eh el dibujo la
imagen la tenéis en la figura 5.9a de la página 212 vale también os la
he puesto aquí en las transparencias ahora iremos con ella pero el ejemplo
nos empieza a contar que tenemos un directorio de 4 entradas en la cual una
es asignada a la entrada punto la segunda es eh eh asignada a la entrada
dos puntos la tercera asignada archivo prueba y la cuarta asignada al
archivo foto vale las dos primeras entradas punto y los puntos tienen un
tamaño de 12 bytes mientras que las dos últimas tienen un tamaño de 16
bytes como el nombre de una entrada siempre termina con un carácter eh
nulo que es este que tenéis aquí la barra y el cero seguido de tantos
caracteres nulos como sean necesarios hasta completar una frontera de 4
bytes vale eh en la figura se muestra eh el estado del directorio en el
apartado b después de borrar el archivo foto se observa como la entrada
del archivo prueba ha sido expandida hasta ocupar el espacio que tenía
asignado la entrada borrada vale tenéis ahí la figura veis que en el
apartado a sería eh lo que viene siendo el estado inicial y en el apartado
b como quedaría eh ese directorio después de borrar el archivo fotos vale
fijaos que vamos a verlo en la imagen tenemos aquí la longitud de de
entrada eh de 2 bytes la longitud del nombre también de 2 bytes y luego
pues el nombre más los caracteres de relleno sería lo que tenéis aquí
no el punto los dos puntos prueba y foto vale entonces aquí después de
eliminar el archivo fotos pues veis como ha quedado no eh nos falta eh esa
línea en la que teníamos antes el archivo fotos y por lo tanto pues se
han puesto todas las las entradas con el carácter blue vale eso es eh y
ocuparía pues todo el espacio que antes ocupaba esa esa entrada vale aquí
tenemos cuatro entradas es lo que significa el enunciado del del ejemplo
vale y cada una de ellas pues tiene esa estructura de acuerdo en la que la
primera columna acordaos que es el número del nodo i que ocupa 4 bytes
vale bueno y cómo se gestiona un sistema de estas características no un
sistema uefs pues en cuanto a los nodos i el núcleo para poder trabajar
con un archivo aparte de asignarle necesita tener cargado en la memoria
principal el nodo i asociado al archivo ya que contiene los atributos y la
localización de sus bloques de datos el núcleo copia el contenido de un
nodo i en una estructura de datos que crea en su espacio de direcciones y
el nombre que recibe dicha estructura depende como decimos antes de cada
subunit el cual lo asigna en función del tipo de sistema de archivo en
cuanto a la asignación de espacio pues en un sistema de archivos uefs el
tamaño de un bloque de datos puede ser de 4 kilobytes o de 8 kilobytes
además los bloques se pueden dividir en un número precisado de fragmentos
1 2 4 u 8 el tamaño mínimo que puede tener un fragmento quedaría
limitado por el tamaño de un sector del disco tanto el tamaño del bloque
como el número de fragmentos se configuran al crear un sistema de archivos
uefs vale y en la página 213 del libro tenéis un ejemplo también sobre
el sistema solaris para explicaros cómo la estructura de datos que
implementa un nodo dm de un archivo de un sistema uefs os pone ahí los
campos que contiene esa estructura en solaris vale y me podéis echar un
vistazo para que veáis un poco cómo se trabaja en ese en ese sistema
bueno y llegamos ya a la quinta parte también ha sido una cuarta parte muy
corta y vamos a ver la última antes de pasar a la realización de algunos
de los ejercicios que vienen al final del capítulo vale en cuanto a la
gestión de la entrada salida en soft unix hay una perspectiva general en
general los sistemas operativos basados en unix digamos que sus
dispositivos de entrada salida se clasifican en dos grandes grupos dos
categorías por un lado los dispositivos modo bloque y por otro lado los
dispositivos modo carácter esto es un poco en cómo se trabaja con los
dispositivos de entrada salida en un sistema operativo que se base en unix
los dispositivos modo bloque son aquellos que almacenan la información en
bloques de tamaño fijo normalmente 512 bytes o una potencia de 2
múltiplos del anterior estos bloques pueden ser accedidos de forma
secuencial o aleatoria ejemplos de dispositivos modo bloque serían los
discos y las cintas magnéticas en este caso importante reseñar que los
discos pueden ser discos magnéticos u ópticos vale en cuanto a los
dispositivos modo carácter son aquellos que envían o reciben información
con una secuencia o flujo lineal de bytes en estos pues la información no
se organiza con una estructura concreta entonces no es direccionable y por
lo tanto no permite la realización de operaciones de búsqueda ejemplos de
dispositivos modo carácter pues serían las impresoras el ratón el
teclado y el móvil vale pues si en el examen nos preguntan ejemplos de
estos dispositivos que puede ser una pregunta interesante asociar los
discos modo bloque y a los dispositivos modo carácter o las impresoras el
ratón o el teclado y el móvil vale y nos quedamos con estos detalles que
son incontables vale bueno luego también vamos a hablar de archivos de
dispositivo en cuanto al número de dispositivo mayor en un dispositivo
menor en estos sistemas operativos cada dispositivo entrada salida con un
archivo dispositivo modo carácter hay que recordar que la máscara de modo
del archivo que se almacena en el nodo I del archivo contiene el tipo de
dicho archivo y todos los archivos de dispositivos generalmente suelen
encontrarse alojados dentro del directorio D es importante quedarse con la
localización el contenido del nodo I de un archivo de dispositivo a
diferencia del nodo I de un archivo regular o un directorio no contiene las
direcciones de los bloques de datos del archivo sino dos números enteros
positivos que se denominan por un lado número de dispositivo mayor que
también se denomina así mayor device number y número dispositivo menor
minor device number vale el número de dispositivo mayor es el que permite
identificar una cierta clase de dispositivo y el número de dispositivo
menor a una instancia de dicho dispositivo por otra parte también hay que
saber que cada tipo de dispositivo ya sea de bloque o de carácter dispone
de un conjunto independiente de números de dispositivos mayores luego un
mismo número de dispositivo mayor puede hacer referencia a dispositivos
distintos en función de si es un dispositivo modo bloque o modo carácter
vale bueno tenéis también otro ejemplo aquí en la página doscientos
diecisiete vale el ejemplo cinco punto trece un número de dispositivo que
sea mayor eh o igual a tres eh no perdona un número de dispositivo mayor
que sea igual a tres dentro del conjunto de dispositivos modo bloque puede
referirse por ejemplo a un cierto tipo de disco duro conectado al
computador vale y dentro del conjunto de dispositivos modo carácter uno en
dispositivo mayor igual a tres puede referirse a una impresora vale si
existen dos discos duros iguales eh conectados al computador tendrán
asignado el mismo número de dispositivo mayor en este ejemplo tres ¿no?
pero diferentes dispositivos menos por ejemplo uno y dos vale bueno
también os viene aquí otro ejemplo que es el que tenéis a continuación
el ejemplo cinco catorce que ese os lo dejo para que le echéis un vistazo
vosotros vale eh realmente habla sobre puerto serie vale y eh os da el
archivo de dispositivo correspondiente y eh os habla de escribir en la
intérprete de comandos la orden ls-l y ese archivo de de dispositivo vale
entonces pues os pone ahí la salida que se muestra por pantalla y esto
pues lo podéis practicar operativo que que manejéis vosotros de acuerdo
por eso os lo he dejado un poco para que le echéis un vistazo bueno vale
es este dato bueno pues en cuanto a las llamadas al sistema la integración
de los dispositivos entrada-salida dentro del sistema de archivos mediante
el uso de archivos de dispositivos permite operar con los dispositivos de
entrada-salida usando las mismas llamadas al sistema que se utilizan para
operar con los otros tipos de archivos open read write etcétera esta
característica de los soft units resulta de gran utilidad para los
usuarios y los programadores ya que pueden trabajar con los dispositivos
como si fuesen un archivo más de esta forma pues sólo necesitan conocer
el nombre de ruta del archivo de dispositivo y se evitan trabajar con la
tripleta descriptiva del dispositivo que maneja el núcleo en cuanto a los
nodos v y nodos i de archivos de dispositivos la implementación de estos
nodos asociados a los archivos depende de cada soft unit vale también
sería dependiente en este apartado 553 hablaremos del subsistema ya
propiamente dicho de entrada-salida es el componente del núcleo que se
encarga de efectuar todas las tareas necesarias para la realización de las
operaciones de entrada-salida que son comunes a todos los dispositivos e
independientes de los mismos el subsistema de entrada-salida gestiona la
parte independiente del dispositivo de todas las operaciones de
entrada-salida entre las tareas que realiza se encontrarían la asignación
y protección de dispositivos el bloqueo de procesos en operaciones de
entrada-salida la gestión de los errores producidos en la entrada-salida y
la gestión de los drivers de los dispositivos y el almacenamiento temporal
de datos vale bueno en cuanto a los drivers de los dispositivos de
entrada-salida tenéis que saber que un driver de un dispositivo es el que
contiene el código que permite al núcleo controlar un determinado tipo de
dispositivo de entrada-salida así es necesario un driver uno para el
teclado otro para el disco duro etcétera para todos los periféricos que
utilizamos es necesario un driver de dispositivo los drivers se diseñan
por los fabricantes teniendo en cuenta las especificaciones de la interfaz
de drivers del subsistema de entrada-salida del núcleo y las
características del dispositivo vale estos drivers en soft units son parte
del código del núcleo y se ejecutan en dicho modo vale el modo núcleo el
núcleo podría invocar a un driver por diferentes motivos los tienen aquí
en la página 220 del libro una causa puede ser la configuración o
referente a la configuración cuando se arranca el sistema operativo el
núcleo invoca a los drivers de los dispositivos para inicializar los
dispositivos referente a la entrada-salida pues decir que el subsistema de
entrada-salida del núcleo invoca a un driver para leer o escribir datos en
un cierto dispositivo en cuanto al control que puede ser otra causa pues un
usuario puede solicitar realizar operaciones de control sobre un
determinado dispositivo como por ejemplo rebobinar una cinta magnética o
abrir o cerrar cierto dispositivo en cuanto a las interrupciones otra
posible causa los controladores de entrada-salida generan interrupciones
cuando se ha completado una operación de entrada-salida sobre el
dispositivo que supervisan o también si se han producido algún tipo de
cambio en su estado ¿vale? las interrupciones son tratadas por los
manipuladores de las interrupciones un manipulador entre otras tareas debe
despertar al driver del dispositivo si este se había bloqueado en espera
de que el controlador de entrada-salida estuviera preparado para procesar
otra petición de entrada-salida para tratar las interrupciones la mayoría
de sistemas operativos basados en UNIX asignan a cada tipo de interrupción
un número entero positivo que se denomina nivel de prioridad de la
interrupción NPI esto es muy importante este nombre lo veréis no a menudo
nivel de prioridad de interrupción NPI este número entero positivo puede
tomar valores comprendidos entre este rango que veis aquí NPI MIN NPI MAX
generalmente el mínimo es 0 ¿vale? y corresponde con se corresponde con
la prioridad más baja los procesos de los usuarios y la mayor parte del
código del núcleo se ejecutan con este nivel de prioridad ¿vale? el sin
embargo el valor de NPI MAX ya depende de cada sistema operativo el sistema
operativo a salud y mis que utilicen la configuración de npi a un
determinado valor bloquea o enmascara todas las interrupciones con npi
igual o inferior de esta forma conseguimos priorizar la atención de las
interrupciones vale muy importante que la seco y ya aparte que no está
incluido dentro de esa quinta parte de este tema 5 nos habla el libro de
los conectores los conectores o también sockets es como se denomina en
inglés son los principales mecanismos que utilizan los sistemas operativos
a dos en juniors para implementar las conexiones en red un conector permite
establecer un canal de comunicación a través de una red entre un proceso
emisor y un proceso receptor en la página 223 tenéis esta figura que
describe la comunicación en red mediante el uso de estos conectores
tenéis aquí la red y aquí pues el camino con los enlaces de dicha red y
luego pues tenéis el proceso emisor y el proceso receptor vale espacio de
usuario espacio del núcleo vale la parte inferior es el núcleo espacio
del usuario y tenéis aquí ese conector no que pues hace esa especie de
conexión entre el espacio de usuario espacio del núcleo que permite pues
esa comunicación entre el proceso emisor y el proceso receptor al final es
lo importante los conectores se implementan mediante archivos que
dinámicamente eso es importantísimo varios archivos se crean y eliminan
dinámicamente un conector se cree invocando esta llamada al sistema que
tenéis la sopa vale se llama socket y tiene tres parámetros de entrada
por un lado vamos a analizar el primero de los familia este argumento este
parámetro de entrada especifica la familia de direcciones o protocolos que
se desea emplear dichas familias suelen estar definidas generalmente en el
archivo de cabecera si sockets punto h dos de las más usadas son estas que
tenéis aquí la f y unix y la a efe y net vale también se denominan pf y
unis o pf y net la f y unix digamos que los protocolos internos de unix son
éstos y se utilizan para el uso de los protocolos internos para comunicar
procesos que se ejecutan en la misma máquina en consecuencia no requiere
de la existencia de una tarjeta de red en computador no porque no se
utiliza en cuanto al feiner pues son los protocolos de internet como puede
ser tcp o urdp otro parámetro de entrada es tipo este parámetro establece
la semántica de conexión para el conector puede tomar los siguientes
valores so que stream pues ese conector con protocolo orientado a conexión
consistiría en realizar una búsqueda de enlaces libres que unan los dos
computadores que se quieren conectar y una vez establecida la conexión se
pueden enviar los datos en orden secuencial como si fuese una tubería ya
que la conexión es permisible permanente y fiable bueno el otro valor de
ferran es conector con un protocolo orientado a conexión o datagrama que
se trata de conexiones no permanentes o fiables y la transmisión por la
trama se realiza a nivel de paquetes cada paquete puede seguir una ruta
distinta además la recepción de los paquetes puede no ser secuestrada por
último el tercer parámetro de entrada protocolo que es el que permite
especificar el protocolo particular que se va a utilizar dentro de una
determinada familia lo normal es que cada tipo de conector tenga asociado
un determinado protocolo pero en el caso de que existiera más o menos un
protocolo de conexión o datagrama de conexión o de conexión más de uno
se especifica el adecuado con este parámetro si este parámetro se
configura con el valor cero entonces la elección del protocolo se delega
en el núcleo si durante la ejecución de esta llamada al sistema se
produce algún error entonces en la variable r se almacena el valor menos
uno sin embargo si la llamada se ejecuta con éxito entonces en r se
almacena el escritor de archivo asociado al conector bueno y aquí pues
tenéis un ejemplo vale la página 224 que es la última del tema pues os
viene un ejemplo de lo que sería esa llamada al sistema para crear un
conector entonces en este ejemplo pues tenemos la llamada con estas
herramientas tres entradas estos tres parámetros de entrada af unix shock
stream y cero entonces lo que hace esta llamada es crear un conector
orientado a conexión porque tenemos el valor shock stream que utilizará
los protocolos internos de unix porque hemos puesto el parámetro af unit
el protocolo utilizado será escogido por el núcleo porque hemos
introducido un protocolo y por último pues mencionar que si la llamada se
ejecuta con éxito entonces almacena en el cd en el escritor del archivo el
descriptor del archivo asociado al conector en caso de error almacenará el
valor menos uno bueno y hasta aquí pues este este tema 5 vale luego pues
tenéis un resumen en la página 224 i 225 que pues os va a reseñar lo
más importante de este tema nosotros para terminar la clase lo que vamos a
hacer es un par de ejercicios de los que os vienen al final no de la
autoevaluación sino de los ejercicios que os viene en el apartado 5.10 de
la página 229 y os los he colgado también es o cómo funciona la llamada
al sistema open ¿vale? y pues un ejemplo en el cual se ven diferentes
llamadas al sistema entre las que están esas dos que nos pide este
ejercicio y así también os queda alguna más para que tengáis de cara a
poderlo entender bien y prepararlo bien para el examen. Entonces recordamos
que la llamada al sistema open es la que crea un fichero antes de abrirlo
si existe es la que crea un fichero antes de abrirlo si este no existe
previamente ¿vale? si existe pues nada en dicho caso su sintaxis es la que
veis aquí ¿vale? open y tiene tres parámetros de entrada. Flags, el
primero de ellos debe incluir alguna de estas constantes solo lectura, solo
escritura o lectura y escritura ¿vale? y también esta otra de aquí o
crear ¿vale? aparece un tercer argumento que es el argumento modo y es la
máscara de modo octal que especifica los permisos de acceso que serán
asociados al fichero cuando se cree ¿vale? importante esto bueno entonces
a continuación pues vienen esos ejemplos ¿no? por ejemplo aquí tenemos
la llamada al sistema open el texto... el archivo texto .txt y esta
máscara de modo ¿no? entonces lo que hace esta llamada al sistema que de
momento no es ninguna de las que vienen ahí en el enunciado esta lo que
hace es abrir el fichero texto .txt con permisos de lectura y escritura
para todos los usuarios ¿vale? es lo que viene ahí. le haría ver esta
máscara de modo par en la segunda llamada al sistema open es la que
tenéis aquí ahora en este caso estamos introduciendo una constante o el
de on y vale entonces abre el fichero texto punto x t y lo hace en modo
solo lectura bueno vamos a ver la prima del sistema que ésta ya es la que
nos aparece en el apartado a en el open y bueno aquí los pone texto punto
txt pero es lo mismo y nos pone datos punto txt o rd wr una barra y o ap
esto lo que significa es que se abre el fichero texto punto txt con datos
puntos de triste como tienen el libro para leer además sitúa el puntero
de lectura-escritura al final del fichero bueno y la otra llamada al
sistema del apartado de lo que haría es abrir el fichero texto punto txt o
prueba en el caso del libro en modo solo lectura aquí, recordad lo de los
primeros temas SISUID, SISCID y SISVTX están desactivados. ¿Vale?
Entonces bueno como resumen de este ejemplo ver obviarse en que los tres
primeros ejemplos para los que la llamada al sistema open se ejecuta con
éxito el fichero texto.txt ya debe estar creado en el director de trabajo
actual. En caso contrario se almacenaría el al o menos uno en F. ¿Vale?
Bueno, pues eso entonces como respuesta al ejercicio 5.1 de la página 229
de vuestro tema 5. ¿Veis que es muy sencillo? ¿Vale? Y bueno, vamos a
resolver ya por último para finalizar la sesión el ejercicio 5.4 ¿Vale?
Entonces este ejercicio también lo tenéis ahí en esa página 229 y os lo
he puesto en estas diapositivas resuelto ¿Vale? Nos dice que en el
director de trabajo actual residen dos ficheros ¿Vale? Vamos a verlo un
poco por encima os dejo aquí la solución para que la analicéis vosotros
después con más detalle son dos archivos dos ficheros web.txt y j10
¿Vale? Las primeras cuatro líneas de ese fichero web.txt las tenéis
aquí ¿Vale? Porque en el libro os viene en la página 230 en esas dos
figuras tendríais lo que yo os he puesto aquí ¿Vale? El código C del
programa j10 y las primeras líneas de ese archivo web.txt ¿Vale? Bueno
entonces en el apartado A nos pide que expliquemos el significado de del
funcionamiento del programa si se invoca desde un intérprete de comandos
mediante la orden j10 25 web.txt ¿Vale? Bueno entonces voy a pasar a la
página siguiente ¿Vale? Bueno aquí yo os he puesto en el apartado A
tenéis las descripciones de esos puntos en concreto del programa por si os
interesa pues lo he recopilado para que también lo tengáis ¿Vale? Pero
el apartado A del libro es el apartado B de esta transparencia ¿Vale? Que
es la solución porque el apartado B del libro realmente os pide que
comprobéis este ejercicio compilándolo y ejecutándolo en vuestro sistema
operativo. ¿Vale? Entonces eso no lo vamos a hacer vamos a poner por
encima esta respuesta y la os dejo para vosotros que la profundicéis y que
la compiléis y la ejecutéis en vuestro sistema. ¿Vale? Bueno entonces al
ejecutar esta orden que nos dice renunciado se ejecuta el programa j10
¿Vale? A esa ejecución se le asocia el proceso ORD imaginemos ¿No? En
primer lugar se comprobaría que el número de parámetros introducidos por
la línea de comandos a invocar a j10 es igual a 3 ¿Vale? Vemos que si 1 2
y 3 ¿Vale? Entonces en segundo lugar se invoca la función ATOI ¿Vale?
Estoy siguiendo el el código de ese programa j10 para convertir al número
entero el segundo parámetro, el 25. ¿Vale? Introducido por la línea de
comandos que es una cadena de caracteres así ¿Vale? Como aquí esto lo
reconoce como cadena de caracteres hay que transformarlo al número entero
dicho número se almacena en la posición de memoria asociada a la variable
entera x. ¿Vale? Pues si nos fijamos en el programa pues aquí la función
ATOI pues el resultado se almacena en la variable x. ¿Vale? Bueno después
se invoca a la función malloc para reservar n bytes de memoria de forma
dinámica ¿Vale? Para ese número de elementos de tipo carácter. Entonces
ese número exactamente es el resultado de realizar la operación AND a
nivel de bit entre x y x-1 ¿Vale? Luego se ejecuta un bucle FOR mientras
la variable h sea menor o igual a ese número ¿Vale? Es decir menor o
igual a 22 ¿No? Luego se invoca a la llamada al sistema open para abrir un
archivo de asistente para leer y escribir ¿De acuerdo? Fijaos aquí que os
viene la constante ORDWF ¿Vale? El nombre del fichero es el tercer
parámetro ¿Vale? Entonces digamos que es word.txt Como la llamada se
ejecuta con éxito en la variable a se almacena el descriptor del fichero
Después se llama la función try según el código que primero invoca a la
llamada al sistema read para leer los quince primeros bytes del 0 al 14 de
ese fichero word.txt y almacenarlos en nuestra memoria cuya primera
dirección está apuntada por el puntero L. Después muestra por pantalla
los quince caracteres leídos y de acuerdo con el contenido del fichero
word, que es el que tenemos aquí en el enunciado pues se va a mostrar por
pantalla estas letras que tenemos aquí el sistema open se pararía justo
ahí ¿Vale? Cuando la función try finaliza se invoca la llamada al
sistema lsig para desplazar veinticinco bytes a partir de un determinado
origen el puntero de lectura de escritura asociado al fichero con
descriptor a ¿Vale? Luego se vuelve a llamar try que invoca a abrir para
leer los quince bytes del fichero word ¿Vale? Entonces lo que pasa es que
se acaba mostrando después por pantalla multusuario y ¿Vale? Porque se va
moviendo el puntero a través de ese texto del archivo vert.txt y va
mostrando por pantalla lo que corresponde Finalmente para terminar pues
invoca además al sistema exit y se finaliza la ejecución del proceso a
devolviendo como un código de retorno para su proceso padre el valor tres
¿Vale? Bueno pues entonces esto sería todo referente al tema cinco y
hemos hecho un par de ejercicios para que veáis un poco la aplicación de
esa teoría con ejemplos prácticos con programas hechos en C y que se
desarrolla dentro del sistema operativo asado UI Veis que en el libro
aparecen seis ejercicios yo recomiendo que hagáis los otros cuatro
vosotros mismos para que podáis practicar todo lo posible de cara al
examen ¿Vale? Entonces en cuanto al tema cinco pues ya estaría todo
visto, cerramos la sesión y por mi parte nada más ¿De acuerdo? Muchas
gracias por vuestra asistencia y un saludo