Debe introducir al menos 3 caracteres en el buscador.
Inicio / Wikis / Tutoriales / Dentro del núcleo Linux 2.4 - Registro/Desregistro de sistemas de Ficheros

Dentro del núcleo Linux 2.4 - Registro/Desregistro de sistemas de Ficheros

 ***-- (2 opiniones)
GNU Free Documentation License Tutorial de Tigran Aivazian - 14 de Febrero de 2006
Temas Relacionados: Linux
23. Registro/Desregistro de sistemas de Ficheros
El núcleo Linux suministra un mecanismo para los nuevos sistemas de ficheros para ser escritos con el mínimo esfuerzo. Los motivos históricos para esto son:

  1. En el mundo donde la gente aún usa sistemas operativos no Linux para proteger sus inversiones en el software legado, Linux tiene que suministrar interoperabilidad para soportar una gran multitud de sistemas de ficheros diferentes - la mayoría no merecen existir pero sólo por compatibilidad con los existentes sistemas operativos no Linux.
  2. La interfaz para los escritores de sistemas de ficheros tiene que ser muy simple para que la gente pueda intentar hacer ingeniería inversa con los sistemas de ficheros existentes para escribir versiones de sólo lectura de ellos. Entonces el VFS de Linux hace muy fácil implementar sistemas de ficheros de sólo lectura: el 95% del trabajo está por finalizar añadiéndole un soporte total para escritura. Como un ejemplo concreto leí sistemas de ficheros BFS para Linux en modo sólo lectura en unas 10 horas, pero llevó varias semanas completarlo para tener un soporte total de escritura (e incluso hoy algunos puristas dicen que no está completo porque no tiene soporte de compactación).
  3. La interfaz VFS es exportada, y entonces todos los sistemas de ficheros Linux pueden ser implementados como módulos.

Déjanos considerar los pasos requeridos para implementar un sistema de ficheros bajo Linux. El código para implementar un sistema de ficheros puede ser un módulo dinámicamente cargado o estár estáticamente enlazado en el núcleo, el camino es realizado por Linux trasparentemente. Todo lo que se necesita es rellenar una estructura struct file_system_type y registrarla con el VFS usando la función register_filesystem() como en el siguiente ejemplo de fs/bfs/inode.c:



#include <linux/module.h>
#include <linux/init.h>

static struct super_block *bfs_read_super(struct super_block *, void *, int);

static DECLARE_FSTYPE_DEV(bfs_fs_type, "bfs", bfs_read_super);

static int init init_bfs_fs(void)
{
return register_filesystem(&bfs_fs_type);
}

static void
exit exit_bfs_fs(void)
{
unregister_filesystem(&bfs_fs_type);
}

module_init(init_bfs_fs)
module_exit(exit_bfs_fs)




Las macros module_init()/module_exit() aseguran que, cuando BFS es compilado como un módulo, las funciones init_bfs_fs() y exit_bfs_fs() se convierten en init_module() y cleanup_module() respectivamente; si BFS está estáticamente enlazado en el núcleo el código exit_bfs_fs() lo hace innecesario.

La struct file_system_type es declarada en include/linux/fs.h:



struct file_system_type {
const char *name;
int fs_flags;
struct super_block *(*read_super) (struct super_block *, void *, int);
struct module *owner;
struct vfsmount *kern_mnt; /* For kernel mount, if it's FS_SINGLE fs */
struct file_system_type * next;
};




Los campos anteriores son explicados de esta forma:

  • name: nombre humano leíble, aparece en el fichero /proc/filesystems y es usado como clave para encontrar un sistema de ficheros por su nombre; este mismo nombre es usado por el tipo de sistema de ficheros en mount(2), y debería de ser único; (obviamente) sólo puede haber un sistema de ficheros con un nombre dado. Para los módulos, los nombres de los punteros al espacio de direcciones del módulo no son copiados: esto significa que cat /proc/filesystems puede fallar si el módulo fue descargado pero el sistema de ficheros aún está registrado.
  • fs_flags: una o mas (ORed) de las banderas: FS_REQUIRES_DEV para sistemas de ficheros que sólo pueden ser montados como dispositivos de bloque, FS_SINGLE para sistemas de ficheros que pueden tener sólo un superbloque, FS_NOMOUNT para los sistemas de ficheros que no pueden ser montados desde el espacio de usuario por medio de la llamada al sistema mount(2): ellos pueden de todas formas ser montados internamente usando la interfaz kern_mount(), ej, pipefs.
  • read_super: un puntero a la función que lee el superbloque durante la operación de montaje. Esta función es requerida; si no es suministrada, la operación de montaje (desde el espacio de usuario o desde el núcleo) fallará siempre excepto en el caso FS_SINGLE donde fallará en get_sb_single(), intentando desreferenciar un puntero a NULL en fs_type->kern_mnt->mnt_sb con (fs_type->kern_mnt = NULL).
  • owner: puntero al módulo que implementa este sistema de ficheros. Si el sistema de ficheros está enlazado estáticamente en el núcleo entonces esto es NULL. No necesitas establecer esto manualmente puesto que la macro THIS_MODULE lo hace automáticamente.
  • kern_mnt: sólo para sistemas de ficheros FS_SINGLE. Esto es establecido por kern_mount() (POR HACER: kern_mount() debería de rechazar montar sistemas de ficheros si FS_SINGLE no está establecido).
  • next: enlaza a la cabecera de la lista simplemente enlazada file_systems (ver fs/super.c). La lista está protegida por el spinlock read-write file_systems_lock y las funciones register/unregister_filesystem() modificada por el enlace y desenlace de la entrada de la lista.

El trabajo de la función read_super() es la de rellenar los campos del superbloque, asignando el inodo raiz e inicializando cualquier información privada del sistema de ficheros asociadas por esta instancia montada del sistema de ficheros. Por lo tanto, tipicamente el read_super() hará:

  1. Lee el superbloque desde el dispositivo especificado a través del argumento sb->s_dev, usando la función de la antememoria intermedia bread(). Si se anticipa a leer unos pocos más bloques de metadatos inmediatamente subsecuentes, entonces tiene sentido usar breada() para planificar el leer bloque extra de forma asíncrona.
  2. Verifica que el superbloque contiene el número mágico válido y todo "parece" correcto.
  3. Inicializa sb->s_op para apuntar a la estructura struct super_block_operations. Esta estructura contiene las funciones específicas del sistema de ficheros implementando las operaciones como "leer inodo", "borrar inodo", etc.
  4. Asigna el inodo y dentry raiz usando d_alloc_root().
  5. Si el sistema de ficheros no está montado como sólo lectura entonces establece sb->s_dirt a 1 y marca la antememoria conteniendo el superbloque como sucio (POR HACER: ¿porqué hacemos esto? Yo lo hice en BFS porque MINIX lo hizo ...)
Autor y licencia de 'Dentro del núcleo Linux 2.4 - Registro/Desregistro de sistemas de Ficheros'
Tigran Aivazian Extraído de: http://es.tldp.org/Manuales-LuCAS/DENTRO-NUCLEO-LINUX/dentro-nucleo-linux-html/ GNU Free Documentation License
Licencia GNU Free Documentation License: http://www.es.gnu.org/licencias/fdles.html
Este contenido ha sido recopilado por el equipo de Wikilearning. Todo el contenido recopilado se ha obtenido respetando y comunicando en nuestro site la licencia de cada fuente.
Wikilearning tiene permiso expreso por escrito de los autores para publicar los contenidos que ha extraído de otras webs, incluyendo su uso comercial.

Wikis relacionados con 'Dentro del núcleo Linux 2.4 - Registro/Desregistro de sistemas de Ficheros'

Este documento describe cómo hacer el enmascarado (masqueradinq), proxy transparente, reenvío de puertos (port forwarding),... Más »
Manual Compacto para nuevos usuarios.
El propósito de este articulo es de mostrarnos una amplia y precisa descripción de lo... Más »
La fijación de precios está convirtiéndose en un modo de vida para muchos minoristas y... Más »
En este modulo algunas de las clasificaciones básicas de sistemas serán temporalmente introducidas mientras que... Más »
¿Estás seguro de que deseas eliminar este capítulo?