In che modo Linux distingue tra file reali e inesistenti (ad esempio:dispositivo)?

Quindi ci sono fondamentalmente due diversi tipi di cose qui:

1. Filesystem normali, che contengono file in directory con dati e metadati, nel modo familiare (inclusi soft link, hard link e così via). Questi sono spesso, ma non sempre, supportati da un dispositivo a blocchi per l'archiviazione persistente (un tmpfs risiede solo nella RAM, ma per il resto è identico a un normale filesystem). La semantica di questi è familiare; leggi, scrivi, rinomina e così via, tutto funziona come ti aspetti.
2. Filesystem virtuali, di vario genere. /proc e /sys sono esempi qui, così come i filesystem personalizzati FUSE come sshfs o ifuse . C'è molta più diversità in questi, perché in realtà si riferiscono solo a un filesystem con semantica che è in un certo senso "personalizzata". Pertanto, quando leggi da un file sotto /proc , in realtà non stai accedendo a un dato specifico che è stato memorizzato da qualcos'altro che lo ha scritto in precedenza, come in un normale filesystem. Stai essenzialmente facendo una chiamata al kernel, richiedendo alcune informazioni che vengono generate al volo. E questo codice può fare tutto ciò che vuole, dal momento che è solo una funzione da qualche parte che implementa read semantica. Quindi, hai lo strano comportamento dei file sotto /proc , come ad esempio fingere di essere collegamenti simbolici quando in realtà non lo sono.

La chiave è quel /dev è in realtà, di solito, uno del primo tipo. È normale nelle distribuzioni moderne avere /dev essere qualcosa di simile a un tmpfs, ma nei sistemi più vecchi era normale che fosse una semplice directory su disco, senza attributi speciali. La chiave è che i file in /dev sono nodi di dispositivo, un tipo di file speciale simile ai FIFO o ai socket Unix; un nodo di dispositivo ha un numero maggiore e minore e leggerli o scriverli sta effettuando una chiamata a un driver del kernel, proprio come leggere o scrivere un FIFO sta chiamando il kernel per bufferizzare l'output in una pipe. Questo driver può fare quello che vuole, ma di solito tocca l'hardware in qualche modo, ad es. per accedere a un disco rigido o riprodurre l'audio negli altoparlanti.

Per rispondere alle domande originali:

1. Ci sono due domande relative al fatto che il "file esista" o meno; questi sono se il file del nodo del dispositivo esiste letteralmente e se il codice del kernel che lo supporta è significativo. Il primo viene risolto proprio come qualsiasi cosa su un normale filesystem. I sistemi moderni usano udev o qualcosa di simile per controllare gli eventi hardware e creare e distruggere automaticamente i nodi del dispositivo in /dev di conseguenza. Ma i sistemi più vecchi, o build personalizzate leggere, possono semplicemente avere tutti i loro nodi di dispositivo letteralmente sul disco, creati in anticipo. Nel frattempo, quando leggi questi file, stai effettuando una chiamata al codice del kernel che è determinato dai numeri di dispositivo principale e secondario; se questi non sono ragionevoli (ad esempio, stai provando a leggere un dispositivo a blocchi che non esiste), otterrai solo una sorta di errore di I/O.

2. Il modo in cui funziona quale codice del kernel chiamare per quale file di dispositivo varia. Per filesystem virtuali come /proc , implementano il proprio read e write funzioni; il kernel chiama semplicemente quel codice a seconda del punto di montaggio in cui si trova e l'implementazione del filesystem si occupa del resto. Per i file di dispositivo, viene inviato in base ai numeri di dispositivo principale e secondario.

Ecco un elenco di file di /dev/sda1 sul mio server Arch Linux quasi aggiornato:

% ls -li /dev/sda1
1294 brw-rw---- 1 root disk 8, 1 Nov  9 13:26 /dev/sda1

Quindi la voce della directory in /dev/ per sda ha un numero di inode, 1294. È un vero file su disco.

Guarda dove appare di solito la dimensione del file. Al suo posto appare "8, 1". Questo è un numero di dispositivo maggiore e minore. Nota anche la 'b' nei permessi dei file.

Il file /usr/include/ext2fs/ext2_fs.h contiene questo (frammento) C struct:

/*
 * Structure of an inode on the disk
 */
struct ext2_inode {
    __u16   i_mode;     /* File mode */

Quella struttura ci mostra la struttura su disco dell'inode di un file. Molte cose interessanti sono in quella struttura; dai un'occhiata a lungo.

Il i_mode elemento di struct ext2_inode ha 16 bit e ne utilizza solo 9 per i permessi utente/gruppo/altro, lettura/scrittura/esecuzione e altri 3 per setuid, setgid e sticky. Ha 4 bit per differenziare tipi come "plain file", "link", "directory", "named pipe", "Unix family socket" e "block device".

Il kernel Linux può seguire il solito algoritmo di ricerca delle directory, quindi prendere una decisione in base alle autorizzazioni e ai flag nel i_mode elemento. Per 'b', file di dispositivo a blocchi, può trovare i numeri di dispositivo principale e secondario e, tradizionalmente, utilizzare il numero di dispositivo principale per cercare un puntatore a qualche funzione del kernel (un driver di dispositivo) che si occupa dei dischi. Il numero di dispositivo minore di solito viene utilizzato come, ad esempio, il numero di dispositivo del bus SCSI o il numero di dispositivo EIDE o qualcosa del genere.

Alcune altre decisioni su come gestire un file come /proc/cpuinfo sono realizzati in base al tipo di filesystem. Se fai un:

% mount | grep proc 
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)

puoi vedere che /proc ha il tipo di file system "proc". Lettura da un file in /proc fa sì che il kernel faccia qualcosa di diverso in base al tipo di file system, proprio come l'apertura di un file su un file system ReiserFS o DOS farebbe sì che il kernel utilizzi funzioni diverse per individuare i file e individuare i dati dei file.

Alla fine sono tutti file per Unix, questa è la bellezza dell'astrazione.

Il modo in cui i file vengono gestiti dal kernel, ora questa è una storia diversa.

/proc e oggigiorno /dev e /run (alias /var/run) sono filesystem virtuali nella RAM. /proc è un'interfaccia/finestra per le variabili e le strutture del kernel.

Consiglio di leggere The Linux Kernel http://tldp.org/LDP/tlk/tlk.html e Linux Device Drivers, Third Edition https://lwn.net/Kernel/LDD3/.

Mi è piaciuto anche The Design and Implementation of the FreeBSD Operating System http://www.amazon.com/Design-Implementation-FreeBSD-Operating-System/dp/0321968972/ref=sr_1_1

Dai un'occhiata alla pagina pertinente relativa alla tua domanda.

http://www.tldp.org/LDP/tlk/dd/drivers.html