Montato solitamente in /dev/shm, simile ad un ramdisk, ma oltre ad usare la RAM come spazio di memorizzazione, può usare anche lo swap; in pratica è un filesystem in memoria virtuale. Sarà il sottositema VM di Linux a preoccuparsi di utilizzare la RAM oppure il disco, eventualmente effettuando lo swap da l'uno all'altro.

Il tmpfs non ha un block device sottostante che deve essere formattato prima di usarlo, lo si monta ed è subito un filesystem disponibile. E' sufficiente compilare nel kernel il supporto al virtual memory file system (CONFIG_TMPFS), chiamato in precedenza shm fs.

La dimensione di un tmpfs è dinamica, però si può specificare una dimensione massima per evitare che un processo impazzito occupi tutta la VM. L'opzione viene specificata al momento del montaggio (o in /etc/default/tmpfs per Debian). Per default il kernel alloca la metà della memoria disponibile, ma in pratica si dovrebbe allocare un po' meno di quanta memoria virtuale (RAM + swap) rimane libera durante l'utilizzo più intenso della macchina.

Le applicazioni che fanno uso della shared memory secondo lo standard POSIX, per girare richiedono che il kernel supporti tmpfs, ma non è necessario che un filesystem di questo tipo sia montato. Le applicazioni POSIX shm attualmente non sono molte. Ci sono circostanze in cui può essere vantaggioso montare il classico /tmp su un tmpfs, ma la cosa va valutata con attenzione. In generale si può dire che per il momento si può vivere benissimo senza un tmpfs montato.

Volendo attivare il tmpfs automaticamente all'avvio si può aggiungere a /etc/fstab una riga del genere:

tmpfs /dev/shm  tmpfs size=32m  0 0

Montato solitamente in /proc

Montato solitamente in /proc/bus/usb

Montato solitamente in /dev/pts

Attenzione devfs è considerato ormai obsoleto, vedere la sezione udev e sysfs.

Montato solitamente in /dev

Dalla Linux Devfs (Device File System) FAQ:

Devfs is an alternative to “real” character and block special devices on your root filesystem. Kernel device drivers can register devices by name rather than major and minor numbers. These devices will appear in devfs automatically, with whatever default ownership and protection the driver specified. A daemon (devfsd) can be used to override these defaults. Devfs has been in the kernel since 2.3.46.

NOTE that devfs is entirely optional. If you prefer the old disc-based device nodes, then simply leave CONFIG_DEVFS_FS=n (the default). In this case, nothing will change. ALSO NOTE that if you do enable devfs, the defaults are such that full compatibility is maintained with the old devices names.

Quindi devfs sarebbe una cosa buona. Per attivarlo bisogna:

• Compilare un kernel con il supporto CONFIG_DEVFS_FS=n
• Installare il demone devfsd, con il suo file di configurazione /etc/devfsd.conf e il suo script di start.
• Controllare che non venga usato devpts, perché devfs gestisce in proprio anche i /dev/pts. Con Debian dovrebbe pensarci automaticamente lo script /etc/init.d/mountvirtfs.

Una caratteristica di devfs è quella di caricare automaticamente il modulo kernel giusto quando un programma in user space tenta di aprire il device relativo. L'approccio più moderno di udev è quello di caricare il modulo kernel opportuno quando viene rilevata la periferica in hardware.

Ci sono comunque delle controindicazioni ad utilizzare devfs. Ad esempio essendo un filesystem virtuale le modifiche sulle permission dei device non sopravviverebbero ad un reboot. Inoltre ci possono essere delle differenze di denominazione tra i classici device su disco e i corrispondenti in devfs (/dev/hda1 diventa /dev/discs/disc0/part0); esistono tecniche per abilitare il compatibility entry management. Per tutti i dettagli vedere la FAQ.

Vedere anche l'articolo udev e Debian.

Il filesystem virtuale sysfs adotta una nuova e unificata interfaccia verso i driver e risulta migliore di tutte le implementazioni passate, è accessibile a partire dalla directory /sys.

In user space il programma udev è in grado ricevere le notifiche del sistema hotplug dei kernel 2.6 (NOTA BENE: il sistema hotplug del kernel 2.6, non il programma hotplug). A partire dalla versione 0.070 udev è in grado di fare tutto quello che faceva il programma hotplug per i kernel 2.4, ma è molto più veloce e leggero (è scritto in C). In più udev è in grado di creare dinamicamente i device file (quelli in /dev) per ogni periferica che viene rilevata nel sistema.

Quindi il kernel gestisce gli eventi hotplug grazie all'omonimo sottosistema ed esporta le informazioni necessarie grazie al filesystem /sys. Sempre in kernel space viene gestito il filesystem virtuale /dev. In userspace il programma udev riceve notifica degli eventi hotplug, determina le politiche dei permessi e dei nomi dei device.

udev provvede a caricare il modulo kernel giusto appena viene identificata una periferica hardware. Questo differisce dall'approccio di devfs, che tenta di caricare il modulo kernel opportuno quando un programma in user space apre il device relativo ad una periferica.

A partire da Debian Etch, udev ha sostituito il programma hotplug.

Opzioni kernel obbligatorie: CONFIG_HOTPLUG e CONFIG_TMPFS; opzioni altamente consigliate CONFIG_PNP, CONFIG_ISAPNP, CONFIG_PNPBIOS e CONFIG_PNPACPI.

Il demone udev riceve gli eventi hotplug dal kernel relativi ai device, legge gli attributi del device stesso in sysfs e quindi cerca le regole corrispondenti a questi attributi nei file contenuti in /etc/udev/. In base a queste regole si possono determinare ulteriori informazioni sul device (ad esempio il nome da assegnare ad una scheda Ethernet in base al MAC address), si può determinare la creazione di device nella directory /dev/ oppure link simbolici, l'assegnamento di opportuni permessi e ownership oppure l'esecuzione di script.

If you want manually tweak the /dev directory at boot time, you can use the /etc/udev/links.conf configuration file. This is a Debian hack: you can create symbolic links, directories or special files (with mknod(1)). In this example a link for the GPS device is created, pointing to the third serial port:

L gps /dev/ttyS2

To avoid aoutmatic loading of kernel modules, you can add blacklist lines to the file /etc/modprobe.d/blacklist, for example:

blacklist parport_pc
blacklist parport
blacklist joydev

Note that some modules (e.g. joydev) are explicitally loaded by the Debian script /etc/init.d/udev. If those modules are unwanted, you can prevent the modprobe command to work by adding to the blacklist file someting like this:

install joydev /bin/true

This tell modprobe to run an alternate program (/bin/true) to load the module, in this case doing nothing. If you need the module later, you can issue from the command line:

modprbe --ignore-install joydev

this will ignore any install directive into the configuration files.

Il nome di un disco SCSI viene assegnato dal kernel al bootstrap in modo dinamico, quindi non è semplice determinare a quale controller è collegato ad esempio il disco /dev/sdd. Il sysfs viene in aiuto come mostrato:

cd /sys/block
ls -l sd?/device | cut -b 44-
sda/device -> ../../devices/pci0000:00/0000:00:09.0/0000:05:0a.0/host0/target0:0:0/0:0:0:0
sdb/device -> ../../devices/pci0000:00/0000:00:09.0/0000:05:0a.0/host1/target1:0:0/1:0:0:0
sdc/device -> ../../devices/pci0000:00/0000:00:09.0/0000:05:0a.0/host2/target2:0:0/2:0:0:0
sdd/device -> ../../devices/pci0000:00/0000:00:09.0/0000:05:0a.0/host3/target3:0:0/3:0:0:0
sde/device -> ../../devices/pci0000:00/0000:00:07.0/host4/target4:0:0/4:0:0:0
sdf/device -> ../../devices/pci0000:00/0000:00:07.0/host5/target5:0:0/5:0:0:0
sdg/device -> ../../devices/pci0000:00/0000:00:08.0/host6/target6:0:0/6:0:0:0
sdh/device -> ../../devices/pci0000:00/0000:00:08.0/host7/target7:0:0/7:0:0:0