AOS - 32 - VIRTUAL FILE SYSTEM II

• Data: [2019-12-06 ven]

• Sito corso: link

• Slides: AOS - 8 VIRTUAL FILE SYSTEM

• Progresso unità: 2/4

La lezione passata avevamo introdotto le varie strutture dati e gli associati drivers necessari per gestire il VFS. Avevamo poi iniziato a descrivere il collegamento tra i thread e il vfs tramite il concetto di mount list, che implementa un meccanismo di namespacing.

Una file descriptor table è tipicamente strutturato un array di pointers. Questa struttura serve per associare un canale di I/O, identificato da un codice numerico, all'oggetto di I/O con cui stiamo lavorando in quel canale. Tramite la file descriptor table è possibile utilizzare le system call tramite i codici numerici per identificare particolari sessioni di I/O.

La sessione identificata dall'id e puntata dalla tabella è a sua volta una tabella che rappresenta la sessione e da cui possiamo poi risalire alla dentry e all'i-node dell'oggetto di I/O con cui stiamo interagendo.

La struttura dati che la file descriptor table è strutturata come segue

struct files_struct
{
  // Tutti i thread in un processo condividono la stessa file
  // descriptor table.
  //
  // Conta il numero di thread che la stanno utilizzando.
  atomic_t count;

  rwlock_t file_lock;

  int next_fd;

  // Puntatore all'array che contiene puntatori a oggetti esterni di
  // tipo struct file. Le struct file sono le strutture dati che
  // rappresentano le sessioni di I/O.
  //
  // Di default questo puntatore punta al campo fd_array. Ovvero di
  // default il numero di sessioni massimo è limitato dal valore di
  // NR_OPEN_DEFAULT.
  //
  // Se voglio avere più sessioni di I/O posso utilizzare fd per
  // puntare ad un altro array, di una taglia più grande.
  //
  // Tramite la facility ulimit() dalla shell possiamo aumentare il
  // numero di default di sessioni attive.
  struct file **fd;

  fd_set *close_on_exec;

  // Pointer ad una bitmap che ci dice quali sessioni sono occupate e
  // quali sono libere.
  fd_set *open_fds;

  // Array delle sessioni di I/O di default.
  struct file *fd_array[NR_OPEN_DEFAULT];
};

Per rappresentare una specifica sessione di I/O invece utilizziamo la struct file , che tipicamente ha la seguente forma

// 2.4 version
struct file
{
  // ...

  // metadati dell'oggetto di I/O che stiamo gestendo.
  struct dentry *f_dentry; 

  // Driver da utilizzare per operare sull'oggetto all'interno di
  // questa sessione.
  struct file_operations *f_op;

  // Numero di thread che hanno aperta la sessione.
  atomic_t f_count;

  // Modo in cui abbiamo aperto la sessione: read/write. 
  mode_t f_mode;

  // Indica in che posizione dell'oggetto di I/O attualmente stiamo
  // lavorando. In particolare ci dice in che punto dello stream di
  // bytes dovremmo leggere o scrivere all'oggetto di I/O.
  loff_t f_pos;

  // ...
};

All'interno dell'architettura del virtual file system (VFS) abbiamo varie entità in gioco. Per ogni entità necessitiamo dunque di particolari API. Possiamo dividere le API relative al VFS in tre classi, a seconda del parametro di input:

• System call layer (codici numerici): API che prendono come parametri gli identificativi della sessione di I/O con cui stiamo lavorando.

• Path-based VFS layer (stringhe): API che prendono come parametro una path passata come stringa.

• Data structure based VFS layer (indirizzi logici): API che utilizzano i puntatori alle strutture dati per la gestione del VFS.

Le relazioni tra i vari layer sono le seguenti

All'interno di molte delle strutture dati viste per gestire il VFS abbiamo trovato più e più volte dei puntatori a delle tabelle di funzioni, ovvero a dei drivers. A seconda della tipologia dell'oggetto in questione abbiamo poi detto che possiamo avere drivers diversi. Come facciamo quindi ad associare ad una determinata tipologia di oggetto di I/O un particolare driver?

Per risolvere questo problema si utilizza una device-drivers table, ovvero una tabella che registra tutti i driver offerti dal sistema.

È possibile avere più device-drivers tables in un sistema. Tipicamente ne abbiamo almeno due: una che registra tutti i char-device drivers, e una che registra tutti i block-device drivers.

Per quanto riguarda i drivers relativi a strutture dati interne del kernel, come ad esempio i drivers delle dentry, o degli i-nodes, o dei superblocchi, non abbiamo delle tabelle separate in quanto abbiamo per ogni struttura dati un solo possibile driver, in quanto le operazioni contenute nel driver sono FS indpendent.

I drivers possono essere ereditati nel caso in cui creiamo un nuovo oggetto di I/O che si trova nello stesso file system del parent che è omogeneo al parent.

Il VFS di LINUX ci permette di gestire le seguenti tipologie di oggetti di I/O:

• Directory

• File

• Char Device

• Block Device

• (named) Pipe

A seconda della tipologia di oggetto può essere facile capire il driver da utilizzare per gestire l'oggetto. In particolare per le directories, i files, e le (named) pipes, è molto semplice capire qual è la tipologia di driver da utilizzare.

Per quanto riguarda i char devices e i block devices invece, non è sempre facile capire quali sono i drivers da utilizzare per interagire con il particolare device. Notiamo infatti che un char device è semplicemente visto come uno stream di bytes da cui possiamo leggere o scrivere, mentre un block device è visto come un dispositivo da cui possiamo leggere e scrivere con la granularità del blocco.

In questo running example vediamo la definizione di un semplice driver a singola istanza, che non fa altro che stampare dei messaggi nella console dmesg . Iniziamo quindi definendo le variabili globali di interesse

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Francesco Quaglia");

#define MODNAME "CHAR DEV"

static int dev_open(struct inode *, struct file *);
static int dev_release(struct inode *, struct file *);
static ssize_t dev_write(struct file *, const char *, size_t, loff_t *);
static ssize_t dev_read(struct file *, const char *, size_t, loff_t *);

#define DEVICE_NAME "my-new-dev"  /* Device file name in /dev/ - not mandatory  */

static int Major;            /* Major number assigned to broadcast device driver */

static DEFINE_MUTEX(device_state);

Segue quindi l'implementazione delle varie funzioni offerte dal driver

• dev_open: Questa funziona viene eseguita per aprire la sessione con il driver. Non fa altro che controllare se il mutex è libero, e se il mutex non è libero ritorna l'errore EBUSY .

  static int dev_open(struct inode *, struct file *);
  
  static int dev_open(struct inode *inode, struct file *file) {
  
    // this device file is single instance
    if (!mutex_trylock(&device_state)) {
      return -EBUSY;
    }
  
    printk("%s: device file successfully opened\n",MODNAME);
    //device opened by a default nop
    return 0;
  }
  

• dev_release: Questa funzione viene eseguita per chiudere la sessione con il driver, e non fa altro che liberare il mutex precedentemente occupato.

  static int dev_release(struct inode *inode, struct file *file) {
  
    mutex_unlock(&device_state);
  
    printk("%s: device file closed\n",MODNAME);
    //device closed by default nop
    return 0;
  }
  

• dev_write: Questa funzione viene chiamata ogni volta che si prova a scrivere utilizzando il driver. La funzione non fa altro che stampare la coppia (Major, Minor) relativi all'oggeto con cui stiamo lavorando.

  static ssize_t dev_write(struct file *filp, const char *buff, size_t len, loff_t *off) {
  
  #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 0, 0)
    printk("%s: somebody called a write on dev with [major,minor] number [%d,%d]\n",
           MODNAME,MAJOR(filp->f_inode->i_rdev),
           MINOR(filp->f_inode->i_rdev));
  #else
    printk("%s: somebody called a write on dev with [major,minor] number [%d,%d]\n",
           MODNAME,MAJOR(filp->f_dentry->d_inode->i_rdev),
           MINOR(filp->f_dentry->d_inode->i_rdev));
  #endif
    //  return len;
    return 1;
  }
  

• dev_read: Questa funzione è uguale alla dev_write.

  static ssize_t dev_read(struct file *filp, char *buff, size_t len, loff_t *off) {
  
  #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 0, 0)
    printk("%s: somebody called a read on dev with [major,minor] number [%d,%d]\n",
           MODNAME,MAJOR(filp->f_inode->i_rdev),
           MINOR(filp->f_inode->i_rdev));
  #else
    printk("%s: somebody called a read on dev with [major,minor] number [%d,%d]\n",
           MODNAME,MAJOR(filp->f_dentry->d_inode->i_rdev),
           MINOR(filp->f_dentry->d_inode->i_rdev));
  #endif
    return 0;
  
  }
  

Per poter effettivamente registrare il driver dobbiamo incapsulare le nostre funzioni nella struttura struct file_operations e registrare il driver al montaggio del modulo tramite la funzione __register_chrdev , che una volta eseguita ci ritornerà il Major number assegnato dal kernel al nostro driver.

static struct file_operations fops = {
  .owner = THIS_MODULE,
  .write = dev_write,
  .read = dev_read,
  .open =  dev_open,
  .release = dev_release
};

int init_module(void) {
  Major = __register_chrdev(0, 0, 256, DEVICE_NAME, &fops);

  if (Major < 0) {
    printk("%s: registering device failed\n", MODNAME);
    return Major;
  }

  printk(KERN_INFO "%s: new device registered, it is assigned major number %d\n",MODNAME, Major);

  return 0;
}

Infine, quando togliamo il modulo dal kernel dobbiamo togliere il driver dalla tabella dei driver. A tale fine eseguiamo la funzione unregister_chrdev .

void cleanup_module(void) {
  unregister_chrdev(Major, DEVICE_NAME);
  printk(KERN_INFO "%s: new device unregistered, it was assigned major number %d\n",MODNAME, Major);
  return;
}

Per utilizzare questo modulo possiamo procedere come segue

make                                      # build kernel object (.ko)
sudo insmod insmod baseline-char-dev.ko   # insert module

una volta che inseriamo il modulo utilizzando dmesg dovremmo leggere un messaggio come il seguente

[25258.329217] CHAR DEV: new device registered, it is assigned major number 235

Utilizzando il major number assegnato possiamo quindi creare un nuovo oggetto di I/O con quel particolare major number, in modo da utilizzare il driver creato da noi.

cd /dev/
mknod my-dev c 235 7

Infine, una volta creato l'oggetto di I/O possiamo scrivere e leggere, e il kernel utilizzerà il nostro driver per gestire questi eventi.

echo "Hello" > /dev/my-dev

In dmesg troviamo quindi

[25988.410447] CHAR DEV: device file successfully opened
[25988.410467] CHAR DEV: somebody called a write on dev with [major,minor] number [235,7]
[25988.410470] CHAR DEV: somebody called a write on dev with [major,minor] number [235,7]
[25988.410473] CHAR DEV: somebody called a write on dev with [major,minor] number [235,7]
[25988.410476] CHAR DEV: somebody called a write on dev with [major,minor] number [235,7]
[25988.410478] CHAR DEV: somebody called a write on dev with [major,minor] number [235,7]
[25988.410483] CHAR DEV: device file closed

NOTA BENE: Il fatto che abbiamo una scrittura per ogni carattere della nostra stringa "Hello" deriva dal fatto che nella funzione dev_write() del driver ritorniamo sempre 1 .