La estructura de archivos

, definida en < linux /fs.h >, es la segunda estructura de datos más importante del controlador de dispositivo. Tenga en cuenta que el archivo no tiene nada que ver con el puntero de ARCHIVO del programa de espacio de usuario. Un ARCHIVO se define en la biblioteca de C y nunca aparece en el código del kernel. Un archivo de estructura, por otro lado, es una estructura de kernel que nunca aparece en el programa del usuario.

La estructura del archivo representa un archivo abierto.
(No es específico de los controladores de dispositivo; cada archivo abierto en el sistema tiene un archivo de estructura asociado en el espacio del kernel). Es creado por el kernel en abierto y se pasa a cualquier función que opere en el archivo hasta el último cierre. Una vez que todas las instancias del archivo se cierran, el kernel libera la estructura de datos.

En el código fuente del kernel, los punteros a los archivos de estructura a menudo se conocen como archivo o filp (" puntero de archivo "). Siempre llamaremos a este puntero filp para evitar confusiones con la estructura en sí. Por lo tanto, archivo se refiere a la estructura, y filp es el puntero a la estructura.

Los miembros más importantes del archivo de estructura se muestran aquí.

1.mode_t f_mode;

El modo de archivo determina si el archivo se puede leer o escribir (o ambos), a través de los bits FMODE_READ y FMODE_WRITE. Es posible que desee estar abierto o La función ioctl verifica los permisos de lectura y escritura de este miembro, pero no necesita verificar los permisos de lectura y escritura, ya que el kernel comprueba antes de llamar a su método. El intento de leer o escribir se rechaza cuando el archivo no se ha abierto para ese tipo de acceso y el controlador ni siquiera lo sabe.

2.loff_t f_pos;

Posición actual de lectura y escritura. Loff_t es de 64 bits en todas las plataformas (larga y larga en terminología gcc). El conductor puede leer este valor si necesita conocer la posición actual en el archivo, pero normalmente no debería cambiarlo, la lectura y la escritura deben usar el puntero que recibieron como último parámetro para actualizar una posición en lugar de actuar directamente en filp- > f_pos. Una excepción a esta regla está en el método llseek, que está diseñado para cambiar la ubicación del archivo.

3.signed int f_flags;

Estos son indicadores de archivo, como O_RDONLY, O_NONBLOCK y O_SYNC. El controlador debe verificar el indicador O_NONBLOCK para ver si solicita una operación de no bloqueo; rara vez se utilizan otros indicadores . En particular, los permisos de lectura /escritura deben ser verificados, usando f_mode en lugar de f_flags. Todas las banderas están definidas en el archivo de encabezado < linux /fcntl.h >.

4.struct file_operations * f_op;

Operaciones asociadas con archivos. El kernel organiza el puntero como parte de su implementación abierta, y luego lo lee cuando necesita enviar cualquier operación. El valor de filp- > f_op nunca se guarda como una referencia inversa del kernel; esto significa que puede cambiar las operaciones de archivo asociadas con su archivo, y el nuevo método funcionará después de que regrese a la persona que llama. Por ejemplo, el código abierto asociado con el número mayor 1 (/dev /null, /dev /zero, etc.) reemplaza la operación en filp- > f_op en función del número menor abierto. Este enfoque permite implementar varios comportamientos bajo el mismo número mayor sin tener que introducir gastos generales en cada llamada al sistema. La capacidad de reemplazar las operaciones de archivos es un par del kernel para la programación de objetos

" sobrecarga de métodos ".

5.void * private_data;

La llamada al sistema abierto establece este puntero en NULL antes de llamar al método abierto para el controlador. Usted es libre de usar este miembro o ignorarlo, puede usar este miembro para apuntar a los datos asignados, pero debe recordar liberar esa memoria en el método de liberación antes de que el kernel destruya la estructura del archivo. Private_data es un recurso útil que conserva la información de estado entre las llamadas del sistema, que utilizamos en la mayoría de nuestros módulos de ejemplo.

6.struct dentry * f_dentry;

La estructura de entrada de directorio (dentry) asociada con el archivo. Los escritores de controladores de dispositivos normalmente no tienen que preocuparse por la estructura dentry, excepto que acceden a la estructura inode como filp- > f_dentry- > d_inode.

Hay varios miembros de la estructura real, pero no son útiles para los controladores de dispositivos. Podemos ignorar a estos miembros de forma segura porque los controladores nunca crean estructuras de archivos, sino que realmente acceden a estructuras creadas en otros lugares.