LKN: Guida di Riferimento delle Opzioni di Configurazione del Kernel

EXPERIMENTAL

Domanda per il codice/driver incompleti e/o in sviluppo.

Alcune delle molte cose che Linux supporta (come i driver di rete, filesystem, protocolli di rete, etc...) possono essere in stato di sviluppo dove la funzionalità, stabilità, o il livello di test non è abbastanza alto per l'uso generale. Questo è normalmente noto come fase "alpha-test" tra gli sviluppatori. Se una caratteristica è correntemente in alpha test, gli sviluppatori solitamente sconsigliano una diffusione disinformata dell'uso di questa funzionalità al pubblico generico per evitare email del tipo "Perché questo non funziona?". In ogni caso, il testing attivo e l'uso di questi sistemi sono ben accetti. Siate solo consapevoli che potrebbe non coincidere con il livello normale di affidabilità o potrebbe non funzionare correttamente in alcuni casi particolari. Segnalazioni di bug dettagliate da persone che hanno familiarità con il kernel solitamente benvenuti dagli sviluppatori. (Ma prima di inviare segnalazioni di bug, si prega di leggere i documenti README, MAINTAINERS, REPORTING-BUGS, Documentation/BUG-HUNTING, e Documentation/oops-tracing.txt nel sorgente del kernel). Questa opzione inoltre rende obsoleta la disponibilità dei driver. Questi sono driver che sono stati sostituiti da qualcos'altro e/o sono programmati per essere rimossi in una versione futura del kernel. A meno che non intendiate aiutare a provare e sviluppare una caratteristica o driver che ricade in questa categoria, o avete una situazione che richieda l'uso di queste caratteristiche, dovreste probabilmente dire no qui, ciò causerà una riduzione delle scelte presentate dal configuratore. Se rispondete sì qui, vi verrà offerta la scelta di usare caratteristiche o driver che sono correntemente considerate in fase alpha-test. Di per sé, questa opzione non fa altro eccetto che permettervi di selezionare altre opzioni.

LOCAL VERSION

Local version---si aggiunge alla release del kernel.

Vi permette di aggiungere una stringa aggiuntiva alla fine della vostra versione del kernel. Questa verrà mostrata quando si inserisce un comando uname, per esempio. La stringa che viene impostata qui si aggiungerà ai contenuti di qualsiasi file con un nome che comincia con localversion nei vostri oggetti e albero sorgenti, in quell'ordine. La stringa può essere al massimo di 64 caratteri.

AUDIT

Support auditing.

Attiva un'infrastruttura di controllo che può essere utilizzata con un altro sottosistema di kernel, come SELinux (che lo richiede per il log dei messaggi di output avc).

IKCONFIG

kernel .config support

Questa opzione abilita il contenuto completo del file .config per il salvataggio nel kernel. Documenta quali opzioni del kernel sono usate nel kernel corrente o in un on-disk kernel. Questa informazione può essere estratta dal file immagine del kernel con lo script scripts/extract-ikconfig e usato come input per ricompilare il kernel corrente o compilarne un altro. Può anche essere estratto da un kernel corrente leggendo il file /proc/config.gz.

EMBEDDED

Configura le caratteristiche standard del kernel (per sistemi integrati)

Questa opzione permette di disabilitare alcune opzioni e impostazioni di base del kernel o cambiarle leggermente. Questo serve per gli ambienti specializzati che possono tollerare un kernel "non standard". È consigliato solo a utenti esperti, dal momento che è molto semplice cambiare le opzioni per creare un kernel che neanche si avvia correttamente.

Di suo, questa opzione non fa altro che permettere di selezionare altre opzioni.

MODULES

Abilita il supporto ai moduli caricabili

I moduli del kernel sono piccoli pezzi di codice compilato che possono essere inseriti nel kernel in esecuzione, invece di essere permanentemente compilati nel kernel. Se selezionate questa opzione, molte parti del kernel possono essere compilate come moduli (rispondendo M invece di sì dove indicato): questo è molto utile per le opzioni usate non frequentemente che non sono richieste in fase di avvio. Per ulteriori informazioni, guardate il Capitolo 4 e le pagine man per modprobe, lsmod, modinfo, insmod, e rmmod. Se si dice sì qui, avrete bisogno di eseguire make modules_install per mettere i moduli sotto /lib/modules dove i tool dei moduli possono trovarli.

IOSCHED_NOOP

No-op I/O scheduler

Il No-op I/O scheduler è uno schedulatore minimale che esegue unioni e ordine basilari. I suoi principali usi includono dispositivi a blocchi non basati su dischi come i dispositivi di memoria e software specializzato o ambienti hardware che fanno la loro schedulazione e richiedono solo una minima assistenza del kernel.

IOSCHED_AS

Anticipatory I/O scheduler

L'anticipatory I/O scheduler è lo schedulatore predefinito del disco. È solitamente una buona scelta per la maggior parte degli ambienti, ma è abbastanza largo e complesso confrontato allo scheduler di deadline I/O. A volte, può essere anche più lento, specialmente in fase caricamento di alcuni database.

IOSCHED_DEADLINE

Deadline I/O scheduler

Lo scheduler di deadline I/O è semplice e compatto. È spesso buono come l'anticipatory I/O scheduler, e sotto alcuni carichi di database, anche meglio. Nel caso di un singolo processo che accede in I/O a un disco in qualsiasi momento, il suo comportamento è pressoché identico allo scheduler anticipatory I/O e dunque è una buona scelta.

IOSCHED_CFQ

CFQ I/O scheduler

Lo scheduler I/O CFQ prova a distribuire la larghezza di banda ugualmente tra tutti i processi del sistema. Dovrebbe provvedere a un ambiente di lavoro equo, ideale per i sistemi desktop.

SMP

Supporto al multiprocessing simmetrico

Questo abilita il supporto per i sistemi con più di una CPU. Se avete un sistema con una sola CPU, come la maggior parte dei personal computer, dite no. Se avete un sistema con più di una CPU, dite sì.

Se dite no qui, il kernel girerà su macchina con singolo o multiprocessore, ma userà una sola CPU della macchina multiprocessore. Se dite sì, il kernel girerà su molte, ma non tutte, macchine monoprocessore. Su una macchina mono-processore, il kernel girerà più velocemente se dite no.

Notate che se dite sì qui e scegliete architettura 586 o Pentium sotto Processor family, il kernel non funzionerà sulle architetture 486. Similarmente, kernel multiprocessore per le architetture PPro potrebbero non funzionare su tutte le schede basate su Pentium.

Si veda anche Documentation/smp.txt, Documentation/i386/IO-APIC.txt, Documenattion/nmi_watchdog.txt, e l'SMP-HOWTO disponibile presso http://www.tldp.org/docs.html#howto.

M386

386

Questo è il tipo della vostra CPU. Questa informazione è usata per l'ottimizzazione. Per compilare un kernel che giri su tutte le CPU di tipo x86 (sebbene non ottimalmente veloce), potete specificare 386 qui. Il kernel non girerà necessariamente su architetture precedenti di quella che avete scelto; per esempio, un kernel ottimizzato per Pentium girerà su PPro, ma non necessariamente su un i486. Qui ci sono le impostazioni raccomandate per le più alte velocità:

Se non sapete cosa fare, scegliete 386.

X86_GENERIC

Supporto x86 generico

Invece di includere solo ottimizzazioni per la variante x86 scelta (ad es., PII, Crusoe, or Athlon), include alcune altre ottimizzazioni. Questo renderà migliori le performance del kernel su CPU x86 oltre che a quella scelta. Questa è solamente intesa per i distributori che necessitano di ottimizzazioni generiche.

NR_CPUS

Massimo numero di CPU (2-255)

Questo parametro permette di specificare il numero massimo di CPU che questo kernel supporterà. Il valore massimo supportato è 255 e il valore minimo che ha senso è 2. Questa opzione serve esclusivamente a salvare memoria; ogni CPU supportata aggiunge approssimativamente 8KB all'immagine del kernel.

SCHED_SMT

Supporto scheduler SMT (HyperThreading)

L'SMT scheduler supporto migliora il "decisionmaking" scheduler sulle CPU Intel Pentium 4 chip con HyperThreading, al costo di un lieve incremento di overhead in alcuni posti.

PREEMPT_NONE

Preemption non forzata (server)

Questo è il modello di preemption tradizionale di Linux, orientato alla massimizzazione del throughput. Fornisce ancora per la maggior parte del tempo una buona latenza, occasionalmente sono possibili ritardi più lunghi. Scegliete questa opzione se state compilando un kernel per un server o sistemi di calcolo/scientifici, o se se volete massimizzare il "power raw processing" del kernel, noncurante delle latenze di scheduling.

PREEMPT_VOLUNTARY

Premption del kernel spontanea (desktop)

Questa opzione riduce la latenza del kernel aggiungendo più "explicit preemption points" al codice del kernel. Questi nuovi punti di preemption sono stati selezionati per ridurre la massima latenza di rischedulazione, che fornisce risposte più veloci alle applicazioni al costo di un throughput leggermente inferiore. Questa opzione accellera le reazioni agli eventi interattivi permettendo a un processo a bassa priorità la preemption volontaria di se stesso, anche se sta eseguendo una chiamata di sistema in kernel mode. Questo permette alle applicazioni di apparire in esecuzione più reattive anche quando il sistema è sotto carico. Selezionate questo se state compilando un kernel per un sistema desktop.

PREEMPT

Kernel preemtible (low-latency desktop)

Questo parametro riduce la latenza del kernel rendendo tutto il codice del kernel (eccetto l'esecuzione di codice in sezioni critiche) preemptible. Questo consente la risposta agli eventi interrattivi permettendo a un processo a bassa priorità la preemption non volontaria anche se sta eseguendo una chiamata di sistema in kernel mode e non sarebbe altrimenti vicino al raggiungimento di un punto naturale di preemption. Questo permette alle applicazioni di apparire in esecuzione più reattive anche quando il sistema è sotto carico, al costo di un throughput leggermente inferiore e un leggero overhead di runtime del codice del kernel. Selezionate questo se state compilando un kernel per un desktop o un sistema embedded con requisiti di latenza di alcuni millesecondi.

PREEMPT_BKL

Preempt il Big Kernel Lock

Questa opzione riduce la latenza di un kernel creando il "Big Kernel Lock" preemptible. Dite sì qui se state compilando un kernel per sistemi desktop.

NOHIGHMEM

Configurazione della memoria alta

Linux può usare fino a 64 GB di memoria fisica su sistemi x86. In ogni caso, lo spazio di indirizzamento dei processori x86 a 32-bit è di soli 4 GB. Ciò significa che, se avete un largo ammontare di memoria fisica, non tutta può essere mappata permanentemente dal kernel. La memoria fisica che non è permanentemente mappata viene chiamata memoria alta (high memory). Se state compilando un kernel che non verrà mai eseguito su macchine con più di 1GB totale di RAM, rispondete off qui (la scelta predefinita, idonea per la maggior parte degli utenti). Ciò risulterà in una divisione 3GB/1GB: 3GB sono mappati in modo che ogni processo vedrà uno spazio di 3GB di memoria virtuale e la parte restante dello spazio dei 4GB di memoria virtuale è usato dal kernel per mappare permanentemente il più possibile di memoria fisica. Se la macchina ha tra 1 e 4GB di memoria fisica RAM, rispondete 4GB qui. Se più di 4GB viene usata, rispondete 64GB qui. La selezione attiva la modalità Intel PAE (Physical Address Extension). PAE implementa tre livelli di paging su processori IA32. PAE è pienamente supportato da Linux, e PAE mode è implementato su tutti i processori Intel recenti (Pentium Pro e superiori).

L'ammonatre totale della memoria fisica verrà automaticamente riconosciuta o può essere forzata usando un'opzione dalla riga di comando del kernel come mem=256M. (Guardate il Capitolo 9 per i dettagli su come passare le opzioni al kernel al momento dell'avvio, e quali opzioni sono disponibili.) Se non sicuri, dite off.

HIGHMEM4G

4GB Selezionate questo se avete un processore a 32-bit e tra 1 e 4GB di memoria fisica RAM.

HIGHMEM64G

64GB Selezionate questo se avete un processore a 32-bit e più di 4GB di memoria fisica RAM.

FLATMEM_MANUAL

Memoria flat

Questa opzione vi permette di cambiare alcuni modi con cui Linux gestisce la sua memoria internamente. La maggior parte degli utenti vedranno che hanno solo una opzione qui: FLATMEM. Questo è normale e corretto. Alcuni utenti con più opzioni avanzate, come NUMA e la memoria hotplug, possono avere opzioni differenti qui. DISCONTIGMEM è più matura, un sistema provato meglio, ma è incompatibile con le memorie hotplug e può soffrire di prestazioni peggiori di SPARSEMEM. Se non siete sicuri tra memoria sparse e memoria discontiguous, scegliete discontiguous memory. Se non sicuri, scegliete questa opzione, flat memory.

DISCONTIGMEM_MANUAL

Memoria discontiguous

Questa opzione provvede a un supporto migliore della memoria flat per i sistemi con memoria discontiguous. Questi sistemi hanno dei buchi nei loro spazi fisici di indirizzamento, e questa opzione gestisce i buchi più efficientemente. Comunque, la maggior parte dell'hardware ha abbastanza spazi di indirizzamento flat e può sperimentare prestazioni degradate a causa dell'overhead aggiuntivo che questa opzione impone. Molte configurazioni NUMA hanno questo come sola opzione. Se non sicuri, scegliete flat memory su questa opzione.

SPARSEMEM_MANUAL

Memoria sparse

Questa sarà la sola opzione per alcuni sistemi, incluso i sistemi con memoria hotplug. Per molti altri sistemi, questa è un'alternativa alla memoria discontiguous. Questa opzione provvede ad alcuni benefici in termini di prestazioni, con una complessità di codice inferiore, ma è nuova e molto sperimentale. Se non siete sicuri, scegliete "discontiguous memory" o "flat memory".

SECCOMP

Abilita seccomp per il calcolo sicuro di bytecode insicuri

Questa caratteristica del kernel è utile per appicazioni "number-crunching" che hanno bisogno di calcolare bytecode poco sicuri durante la loro esecuzione. Usando le pipe o altri tipi di trasporto resi disponibili al processo come descrittori di file che supportano le chiamate di sistema read/write, è possibile isolare quelle applicazioni nel loro proprio spazio di indirizzamento usando seccomp. Una volta che seccomp è abilitato via /proc/pid/seccomp, non può essere disabilitato e all'operazione è permesso di eseguire poche chiamate di sistema sicure definite da ogni seccomp mode. Se non siete sicuri, dite di sì. Solo i sistemi embedded dovrebbero essere compilati rispondendo no.

KEXEC

kexec system call (sperimentale)

kexec è una chiamata di sistema che implementa l'abilità di spegnere il vostro kernel corrente e farne partire un altro. È come un riavvio, ma è indipendente dal firmware del sistema. E come un riavvio, potete far partire qualsiasi kernel con esso, non semplicemente Linux. Il nome deriva dalla somiglianza alla chiamata di sistema exec. Non siate sorpresi se all'inizio non funziona. Potrebbe aiutare nell'attivare il supporto ai dispositivi hotplugging. Mentre si sta scrivendo, l'interfaccia hardware è fase di riscrittura, motivo per cui non può essere consigliata.

HOTPLUG_CPU

Supporto per le CPU hot-pluggable (sperimentale) Dite sì qui per sperimentare con l'accensione e lo spegnimento delle CPU, e per abilitare la sospensione sui sistemi SMP. Le CPU possono essere controllate attraverso l'interfaccia /sys/devices/system/cpu.

PM

Supporto alla gestione dell'alimentazione

Il "Power management" permette a parti del vostro computer di spegnersi o di utilizzare modalità di risparmio energetico se non vengono utilizzate. Ci sono due standard preposti a far ciò: APM e ACPI. Se li volete usare entrambi dite sì qui e abilitate anche uno di questi due standard. "Power management" è più importante per i computer laptop alimentati a batteria; se avete un laptop, controllate la pagina principale di linux laptop presso http://www.linux-on-laptops.com, Tuxmobil-Linux on Mobile Computers a http://www.tuxmobil.org, e il "Battery powered Linux" mini-HOWTO a http://www.tldp.org/docs.html#howto.

SOFTWARE_SUSPEND

Sospensione software

Abilita la sospensione della macchina.

Quando la macchina viene sospesa, un'immagine viene salvata nella vostra swap attiva. Al prossimo riavvio, passate l'argomento resume=/dev/swappartition al kernel per fargli rilevare l'immagine salvata, recuperare lo stato di memoria da esso, e continuare l'esecuzione come prima. Se non volete che lo stato precedente venga ricaricato, usate l'argomento del kernel noresume. In ogni caso, notate che le vostre partizioni verranno controllare con fsck e che dovete lanciare mkswap sulla vostra partizione di swap un'altra volta. La procedura non funziona con i file di swap. In questo momento potete fare il boot senza fare il resuming e poi fare il resume più tardi, ma nel frattempo non potete usare quelle partizioni/file di swap che erano coinvolte nella sospensione. In questo caso, inoltre, c'è il rischio che i buffer su disco non corrisponderanno a quelli salvati. Per ulteriori informazioni, vedere Documentation/power/swsusp.txt.

ACPI

Supporto ACPI

Il supporto per l'"Advanced Configuration and Power Interface (ACPI)" di Linux richiede hardware e firmware compatibile, e presume la presenza di software "OS-directed configuration and power management (OSPM)". Questa opzione allargherà il vostro kernel di circa 70KB. Linux ACPI provvede a una robusta sostituzione funzionale per alcune interfacce "legacy configuration and power management", incluso la specifica Plug and Play BIOS (PnP BIOS), la specifica "MultiProcessor" (MPS), e la specifica di Advanced Power Management (APM). Se entrambi i supporti ACPI e APM sono configurati, qualunque venga caricato prima verrà usato. Il progetto ACPI SourceForge a http://sourceforge.net/projects/acpi contiene il più recente codice sorgente, documentazione, strumenti, sottoscrizione alla mailing list, e altre informazioni. Il supporto Linux per ACPI è basato su "Intel Corporation's ACPI Component Architecture (ACPI CA)." Per ulteriori informazioni vedere http://developer.intel.com/technology/iapc/acpi. ACPI è una specifica "open industry" sviluppata in collaborazione da Compaq, Intel, Microsoft, Phoenix, and Toshiba. La specifica è disponibile presso http://www.acpi.info.

CPU_FREQ

CPU frequency scaling

"CPU frequency scaling" vi permette di cambiare la velocità di clock delle CPU al volo. Questo può far risparmiare energia, perché più è bassa la velocità della CPU, minore è la potenza che la CPU consuma. Notare che questo driver non cambia automaticamente la velocità di clock della CPU; avete bisogno di attivare anche un governor di policy di CPUFreq dinamico (descritto avanti) dopo la fase di boot o uno strumento in userspace. Per i dettagli, vedere in Documentation/cpu-freq.

CPU_FREQ_DEFAULT_

GOV_PERFORMANCE

Performance

Usa "CPUFreq performance governor". Questo imposta la frequenza staticamente alla più alta supportata dalla CPU.

CPU_FREQ_DEFAULT_

GOV_USERSPACE

Userspace

Usa "CPUFreq performance governor". Questo vi permette di impostare la frequenza della CPU manualmente e permette a un programma in userspace di impostare la CPU dinamicamente senza richiedervi di abilitare prima lo "userspace governor" manualmente.

CPU_FREQ_

GOV_PERFORMANCE

"Performance" CPUFreq policy governor

Questo "CPUFreq policy governor" imposta la frequenza staticamente a quella più alta disponibile tra le frequenze della CPU.

CPU_FREQ_GOV_

POWERSAVE

Regolatore delle policy CPUFreq "Powersave"

Questo imposta la frequenza staticamente alla più bassa delle frequenze della CPU disponibili.

CPU_FREQ_GOV_

USERSPACE

Regolatore delle policy CPUFreq "Userspace"

Abilitate questo CPUFreq policy governor sia quando volete impostare la frequenza della CPU manualmente o quando un programma in userspace deve essere in grado di impostare la CPU dinamicamente, come in LART (http://www.lartmaker.nl). Per dettagli, date uno sguardo a Documentation/cpu-freq.

CPU_FREQ_GOV_

ONDEMAND

Regolatore delle policy CPUFreq "On Demand"

Questo driver aggiunge un regolatore dinamico delle politiche CPUFreq. Il regolatore interroga la CPU e cambia la sua frequenza in base all'utilizzo della CPU. Il supporto a questo regolatore dipende dalla capacità della CPU di cambiare velocemente la frequenza (p.e., latency molto basse di transizioni). Per dettagli, date uno sguardo a Documentation/cpu-freq.

CPU_FREQ_GOV_

CONSERVATIVE

Regolatore delle policy CPUFreq "Conservative"

Questo driver è simile al regolatore Ondemand sia nel suo codice sorgente che scopo. La differenza è che il regolatore Conservative è ottimizzato per un sistema alimentato a batterie. La frequenza viene dolcemente incrementata o decrementata invece di saltare al 100% quando la velocità è richiesta. Se state usando un laptop, a PDA, o un computer basato su AMD64 (a causa degli inaccettabili passo-passo problemi di latency tra la minima e la massima frequenza di transizione nella CPU), voi vorrete probabilmente usare questo regolatore. Se avete una macchina desktop, considerate il regolatore ondemand invece. Per dettagli, date uno sguardo a Documentation/cpu-freq.

PCI

Supporto PCI

PCI è un sistema bus usato dai processori per parlare ai dispositivi interni e add-on schede. E' estremamente comune e si trova in quasi tutti i computer moderni. Dite sì a questa opzione a meno che non abbiate una speciale motivo per non farlo.

PCCARD

Supporto PCCard (PCMCIA/CardBus)

Dite sì qui se volete attaccare PCMCIA o PC schede al vostro Linux computer. Questi sono dispositivi di dimensione come carte di credito quali schede network, modems, o hard drives spesso usati con i computer laptop. Ci sono attualmente due varietà di queste schede: 16-bit PCMCIA e 32-bit CardBus schede.

PCMCIA

Supporto 16-bit PCMCIA

Questa opzione abilita il supporto per le schede 16-bit PCMCIA. Le più vecchie schede PC sono quelle 16-bit PCMCIA, così a meno che voi non sappiate che state usando solo schede 32-bit CardBus, dite sì qui. Per usare schede 16-bit PCMCIA, avrete bisogno del supporto del software nella maggior parte dei casi. Guardate il file Documentation/Changes per la posizione e i dettagli.

CARDBUS

Supporto 32-bit CardBus

Cardbus è una architettura mastering bus per schede PC, che permette le schede PC a 32-bit (lo standard PCMCIA originale specifica solo un bus a larghezza 16-bit). Molte schede PC nuove sono a dire il vero schede Cardbus. Per usare le schede PC a 32-bit, avete bisogno anche di un host bridge Cardbus-compatibile. Virtualmente tutti i moderni bridge fanno questo, e la maggior parte di essi è "yenta-compatible", così abilitate questa opzione anche.

HOTPLUG_PCI

Supporto per PCI hotplug (sperimentale)

Dite sì qui se avete una motherboard con un controller PCI hotplug. Questo vi permette di aggiungere e rimuovere schede PCI mentre la macchina è accesa e funzionante.

NET

Supporto Networking

Dite sì qui a meno che non siate un esperto con una buona ragione per non farlo. La ragione è che alcuni programmi hanno il bisogno del supporto del kernel networking anche quando girano su una macchina standalone anche non è connessa a un altro computer. Se state aggiornando da un kernel più vecchio, dovreste considerare di aggiornare i vostri network tools anche, perché i cambiamenti nel kernel e i tools spesso vanno mano nella mano. I tools sono contenuti nel package net-tools, la locazione e il numero di versione dei quali sono dati in Documentation/Changes. Per una introduzione generale al Linux networking, è altamente raccomandato che leggiate la NET-HOWTO, disponibile da http://www.tldp.org/docs.html#howto.

UNIX

Unix domain sockets

Se dite sì qui, includerete il supporto per le socket Unix domain; Le socket sono il meccanismo standard Unix per stabilire e accedere alle connessioni network. Molti programmi comuni usati come l'X Window System, syslog, e udev usano queste socket anche se la vostra macchina non è connessa a qualsiasi rete. A meno che non stiate lavorando in un sistema embedded o qualcosa simile, certamente volete dire sì qui.

INET

TCP/IP networking

Questi sono i protocolli usati in internet e nella maggior parte delle Ethernet locali. E' altamente raccomandato che voi diciate sì qui, dal momento che lacuni programmi (p.e., l'X Window System) usa TCP/IP anche se la vosra macchina non è connessa con altri computer. Loro usano il cosidetto loopback device, che questa opzione imposta. Allargherà il vostro kernel di default di 144KB. Per una eccellente introduzione a Linux networking, leggete il "Linux Networking" HOWTO, disponibile da http://www.tldp.org/docs.html#howto.

IP_ADVANCED_ROUTER

IP: router avanzato

Se avete intenzione di usare la vostra Linux box maggiormente come router, p.e., come un computer che rigira e ridistribuisce i pacchetti di rete, dite sì qui. Vi verranno presentate alcune opzioni che permettono un più preciso controllo sul processo di routing. La risposta a questa domanda non intaccherà direttamente il kernel: rispondendo di no causerà semplicemente di far saltare al configuratore tutte le domande sul routing avanzato. Notate che il vostro box può attuare come un router solo se abilitate l'IP forwarding nel vostro kernel; potete far questo dicendo sì alle opzioni di supporto /proc filesystem e Sysctl e eseguendo la linea:

echo "1" > /proc/sys/net/ipv4/ip_forward

al boot time dopo che il /proc filesystem è stato montato. Se attivate IP forwarding, otterete anche rp_filter, che automaticamente regettano i pacchetti incoming se la tabella entry di routing per i loro source address non corrisponde all'interfaccia di rete da cui stanno arrivando. Questo ha dei vantaggi di sicurezza perché previene l'IP spoofing; in ogni caso può porre dei problemi se usate routing asimmetrico (pacchetti da voi verso un host che prendono un percorso differente da quelli che vanno da quell'host verso di voi) o se operate un host "nonrouting" che ha alcuni indirizzi IP su interfacce differenti. Per disattivare rp_filter, inserire:

echo 0 > /proc/sys/net/ipv4/conf/device/rp_filter

o:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

NETFILTER

Network packet filtering

Netfilter è un framework per filtrare e "sezionare" (in the original context, magling is used) i pacchetti di rete che passano attraverso la vostra Linux box. L'uso più comune del packet filtering è di seguire la Linux box come un firewall che protegge una rete locale da Internet. Il tipo di firewall, dato da questo supporto del kernel, è detto packet filter, che significa che può rigettare pacchetti di rete individuali basati sul tipo, sorgente, destinazione, etc. L'atro tipo di firewall, una basato su proxy, è più sicuro ma più intrusivo, è più seccante da configurare; ispeziona il traffico di rete molto più da vicino, lo modifica, ed è a conoscenza dei protocolli di più alto livello, che mancano a un packet filter. Inoltre, i firewall "proxy-based" spesso richiedono cambi sui programmi in esecuzione sui client locali. "Proxy-based" firewall non hanno bisogno del supporto del kernel, ma sono spesso combinati con un packet filter, che funziona solo se dite sì qui.

Dovreste dire sì qui se avete intenzione di usare la vosra Linux box come gateway per Internet per una rete locale di macchine senza un indirizzo IP globale valido. Questo si chiama "masquerading". Se uno dei computer sulla rete locale vuole mandare qualcosa al di fuori, la vostra box si può "masquerade" come quel computer, p.e., rigira il traffico verso la destinazione esterna voluta, ma modifica i pacchetti come se venissero dalla firewall box stessa. Masquerading lavora in entrambi i modi: se l'host esterno risponde, la Linux box rigirerà silenziosamente il traffico correttamente al computer locale. In questo modo, i computer sulla rete locale sono completamente invisibili al mondo esterno, anche se loro possono raggiungere l'esterno e ricevere le risposte. E' anche possibile eseguire server globalmente visibili da una rete locale mascherata usando un meccanismo chiamato port forwarding. Masquerading è anche spesso chiamato NAT (Network Address Translation). Altri sistemi operativi spesso chiamano questo con il termine PAT (Port Address Translation).

Un altro uso di Netfilter è nel proxing trasparente: se una macchina nella rete locale prova a connettersi a un host esterno, la vostra Linux box può trasperentemente girare il traffico a un server locale, tipicamente un caching proxy server. Un altro uso di Netfilter è quello di costruire un bridging firewall. Usando un bridge con Network packet filtering attivo fa che iptables "veda" il traffico "bridged". Per filtrare tra i più bassi protocolli di rete e ethernet oltre il bridge, usate ebtables (located under bridge Netfilter configuration). Vari moduli esistono per Netfilter che sostituiscono la precedente masquerading (ipmasqadm), packet-filtering (ipchains), transparent proxying, e port-forwarding mechanisms. Guardate in Documentation/Changes sotto iptables per il posto di questi pacchetti. Le possibilità sono che voi diciate di sì qui se compilate un kernel che girerà come router e non per host regolari.

NET_SCHED

QoS and/or fair queueing

Quando il kernel ha diversi pacchetti da mandare su un dispositivo di rete, deve decidere quali mandare prima, quali ritardare, e quali scartare. Questo è il compito delle discipline delle code. ALcuni diversi algoritmi per come fare questo "correttamente" sono stati proposti. Se dite no qui, prenderete il packet scheduler standard, che è uno scheduler FIFO (primo che arriva, primo servito). Se dite sì qui, sarete in grado tra alcune diversi algoritmi alternativi che possono essere attaccati a network device differenti. Questo è utile, per esempio, se alcuni dei vostri dispositivi di rete sono dispositivi real-time che necessitano di un rate certo minimo di flusso per il traffico che corrispondono a criteri specificati. Per amministrare questi scheduler, avete bisogno delle user-level utility dal pacchetto iproute2+tc a http://linux-net.osdl.org/index.php/Iproute2. Questo supporto Quality of Service (QoS) vi abiliterà a usare Differentiated Services (diffserv) e Resource Reservation Protocol (RSVP) sul vostro router Linux se dite sì alle opzioni corrispondenti. La documentazione e il software è a http://diffserv.sourceforge.net.

IRDA

IrDA (infrared) subsystem support

Dite sì qui se volete costruire un supporto per i protocolli IrDA. L' Infrared Data Association specifica gli standards per la comunicazione wireless infrared che è supportata dai maggiori laptop e PDA. Per usare il supporto Linux per i protocolli IrDA, avrete bisogno anche di alcune userspace utility come irattach. Per maggiori informazioni, guardate il file Documentation/networking/irda.txt. Voi vorrete anche leggere l'IR-HOWTO, disponibile a http://www.tldp.org/docs.html#howto. Se volete scambiare bits di dati (p.e., vCal, vCard) con un PDA, avrete bisogno di installare un applicazione OBEX, come OpenObex da http://sourceforge.net/projects/openobex.

IRLAN

Protocollo IrLAN

Dite sì qui se volete compilare il supporto per il protocollo IrLAN. IrLAN emeula un Ethernet e rende possibile mettere su una LAN wireless usando infrared beams. Il protocollo IrLAN può essere usato per parlare con gli access point a infrarossi come l' HP NetbeamIR o l'ESI JetEye NET. Potete anche connettervi a un'altra macchina Linux che esegue il protocollo IrLAN per un networking ad hoc.

IRNET

Protocollo IrNET

Dite sì qui se volete compilare il supporto per il protocollo IrNET. IrNET è un driver PPP, così avrete bisogno anche di un sottosistema PPP funzionante (driver, daemon, e configuration). IrNET è un modo alternativo per trasferire il traffico TCP/IP over IrDA. Usa synchronous PPP sopra un set di point to point IrDA sockets. Lo potete usare tra macchine Linux o con Windows.

IRCOMM

Protocollo IrCOMM

Dite sì qui se volete compilare il supporto per il protocollo IrCOMM. IrCOMM implementa l'emulazione della porta seriale, e rende possibile usare tutte le possibili applicazioni che capiscono le tty con i collegamenti infrared. Così, dovreste essere in grado di usare applicazioni come PPP e minicom.

IRDA_ULTRA

Protocollo Ultra (connectionless)

Dite sì qui per il supporto al protocollo connectionless Ultra IRDA. Ultra vi permette di scambiare data over IrDA con dispositivi molto semplici (watch, beacon) senza l'overhead del protocollo IrDA (no handshaking, no frame di management, simple fixed header). Ultra è disponibile come socket speciale: socket(AF_IRDA, SOCK_DGRAM, 1).

BT

Bluetooth subsystem support

Bluetooth è un low-cost, low-power, e a raggio-corto tecnologia wireless. E' stato disegnato come una sostituzione per i cavi e altre tecnologie "shortrange" come IrDA. Bluetooth opera in una area range personale che tipicamente si estende fino a 10 metri. Ulteriori informazioni su Bluetooth possono essere trovate a http://www.bluetooth.com. Il "Linux Bluetooth subsystem" consiste di diversi layers:

Bluetooth core

HCI device and connection manager, scheduler

HCI device drivers

Interface to the hardware

SCO module

SCO audio links

L2CAP module

Logical Link Control and Adaptation Protocol

RFCOMM module

RFCOMM Protocol

BNEP

Modulo Bluetooth Network Encapsulation Protocol

CMTP

Modulo CAPI Message Transport Protocol

HIDP

Modulo Human Interface Device Protocol

Per usare il Linux Bluetooth subsystem, avete bisogno di alcune userspace utility, come hciconfig e hcid. Queste utility e update ai moduli Bluetooth kernel sono forniti nei pacchetti BlueZ a http://www.bluez.org.

IEEE80211

Generic IEEE 802.11 networking stack

Questa opzione abilita il networking stack hardware-independent IEEE 802.11

MTD

Supporto Memory Technology Device (MTD)

"Memory Technology Devices" sono flash, RAM, e chip simili, spesso usati per i filesystem a stato solido su dispositivi embedded. Questa opzione fornisce il supporto generico per i driver MTD per registrare se stessi con il kernel e per utenti potenziali di dispositivi MTD per enumerare i dispositivi presenti e ottenere un handle per loro. Vi permette anche di selezionare driver individuali per hardware particolari e utilizzatori di dispositivi MTD.

PARPORT

Supporto porta parallela

Se volete usare dispositivi connessi alla vostra porta parallela (il connettore al computer con 25 buchi), p.e., una stampante, ZIP drive, o Parallel Line Internet Protocol (PLIP) link, dovete dire sì qui. Leggete Documentation/parport.txt e drivers/parport/BUGSparport per maggiori informazioni. Per informazioni estensive sui driver per i molti dispositivi attaccati alla porta parallela, guardate http://www.torque.net/linux-pp.html. E' possibile condividere una singola porta parallela tra diversi dispositivi, ed è sicuro compilare tutti i driver corrispondenti nel kernel. Se avete più di una porta parallela e volete specificare quale porta e IRQ usare per questo driver al "module load time" (in fase di caricamento del modulo), guardate in Documentation/parport.txt.

PNP

Supporto Plug and Play

Plug and Play (PnP) è uno standard per le periferiche che lo permettono di venir configurate dal software-- per esempio, assegnare gli IRQ o altri parametri. Nessun jumper sulle schede sono necessari; infatti, i valori provvisti alle schede dal BIOS, dal sistema operativo, o usando una userspace utility. Dite sì qui se desiderate che Linux configuri i vostri dispositivi PnP. Voi dovreste dire anche sì a tutti i protocolli richiesti. Alternativamente, potete dire di no qui e configurare i vostri dispositivi PnP usando userspace utility come il pacchetto isapnptools.

ISAPNP

Supporto ISA Plug and Play

Dite sì qui se desiderate il supporto per i dispositivi ISA PnP. Alcune informazioni sono disponibili in Documentation/isapnp.txt. Se usate dispositivi ISA Plug and Play, usate i tools ISA PnP che trovate a http://www.roestock.demon.co.uk/isapnptools per configuarli appropriatamente.

PNPBIOS

Supporto Plug and Play BIOS (sperimentale)

Linux usa il PNPBIOS definito in "Plug and Play BIOS Specification Version 1.0A May 5, 1994" per autoriconoscere le risorse built-in mainboard (p.e., risorse della porta parallela). Se desiderate che il kernel riconosca e allochi le risorse dei vostri mainboard dispositivi (su alcuni sistemi sono disabilitati dal BIOS) dite sì qui. Il PNPBIOS può anche aiutare a prevenire conflitti di risorse tra i mainboard dispositivi e altri bus dispositivi. ACPI nel prossimo futuro sostituirà (in originale nel testo: ACPI is expected to supersede) PNPBIOS un giorno. Attualmente, coesistono insieme. Se avete un sistema non-ISA che supporta ACPI, probabilmente non avete bisogno del supporto PNPBIOS.

IDE

Supporto ATA/ATAPI/MFM/RLL

Se dite sì qui, il kernel sarà in grado di maneggiare le unità low-cost mass storage come ATA/(E)IDE e ATAPI. I maggiori comuni esempi di tali dispositivi sono gli IDE hard drives e ATAPI CD-ROM drives.

Se il vostro sistema è puramente SCSI e non usa queste interfacce, potete dire no qui.

- Integrated Disk Electronics (IDE, conosciuto anche come ATA-1) è una connessione standard per le unità di mass storage come hard disks. E' stato progettato dalla Western Digital e Compaq Computer nel 1984. E' stato poi rinominato in ST506. Diversi dischi usano l'interfaccia IDE.

- AT Attachment (ATA) è il superset delle specifiche IDE. ST506 è anche chiamato ATA-1.

- Fast-IDE è ATA-2 (anche chiamato Fast ATA).

- Enhanced IDE (EIDE) è ATA-3. Fornisce il supporto per i dischi più larghi (fino a 8.4GB attraverso lo standard LBA), più dischi (quattro invece di due), e per altre unità mass storage, come tapes e CD-ROM.

- UDMA/33 (conosciuto anche come UltraDMA/33) è ATA-4. Usa fast DMA controller, fornisce modi di trasferimento più veloci (con meno carico per la CPU) dei precedenti PIO (Programmed processor Input/Output) dai precedenti standard ATA/IDE.

- ATA Packet Interface (ATAPI) è un protocollo usato da EIDE tape e drive CD-ROM, simile in molti aspetti al protocollo SCSI.

- SMART IDE (self-monitoring, -analysis, and -reporting technology) è stato progettato al fine per prevenire data corruption e disk crashes rilevando pre-hardware "failure conditions" (calore, access time e simili). I dischi costruiti dopo Giugno 1995 possono seguire questo standard. Il kernel stesso non gestisce questo; comunque ci sono abbastanza user programs, come smart, che possono interrogare lo status dei parametri SMART dai disk drive. Per ulteriori informazioni, leggete Documentation/ide.txt.

BLK_DEV_IDE

Supporto Enhanced IDE/MFM/RLL disk/CD-ROM/tape/floppy

Se dite sì qui, userete il driver IDE full-featured per controllare fino a 10 ATA/IDE interfacce, ognuna capace di servire un dispositivo "master" e "slave",per un totale di fino a 20 ATA/IDE disk/CD-ROM/tape/floppy drive. Informazioni utili sui dischi IDE larghi (540 MB), interfacce multiple, cosa fare se i device ATA/IDE device non sono automaticamente riconosciuti, porte sound card ATA/IDE, supporto al modulo, e altri argomenti sono contenuti in Documentation/ide.txt. Per informazioni dettagliate sui hard drives, consultate il Disk-HOWTO e il Multi-Disk-HOWTO, disponibile a http://www.tldp.org/docs.html#howto. Per il fine-tune ATA/IDE drive/interface parametri per performance avanzate, guardate per il pacchetto hdparm a ftp://ibiblio.org/pub/Linux/system/hardware. Non compilate questo driver come modulo se il vostro root filesystem (quello che contiene la directory /) è situato su un dispositivo IDE. Se avete uno o più drive IDE, abilitate questa opzione. Se il vostro sistema non ha drive IDE o se la memoria richiesta sono veramente piccoli, potete dire di no qui, e selezionare l'opzione per il vecchio driver di hard disk invece per salvare circa 13 KB di memoria nel kernel.

BLK_DEV_IDEDISK

Supporto Include IDE/ATA-2 disk

Questo include il supporto avanzato per hard disk MFM/RLL/IDE. Se avete un disco MFM/RLL/IDE non c'è una ragione speciale di usare il vecchio driver di hard disk invece, dite sì. Se avete un sistema SCSIonly, potete dire no qui. Non compilate questo driver come modulo se il vostro root filesystem (quello che contiene la directory /) è situato su un disco IDE.

BLK_DEV_IDECD

Includi supporto IDE/ATAPI CD-ROM

Se avete un CD-ROM drive che usa un protocollo ATAPI, dite sì qui. ATAPI e un nuovo protocollo usato da IDE CD-ROM e tape drive, simile al protocollo SCSI. Molti nuovi drive CD-ROM usano ATAPI, includono il NEC-260, Mitsumi FX400, Sony 55E, e tutti i non-SCSI drive double o più veloci. Se dite sì qui, il CD-ROM drive verrà identificato a boot-time tra gli altri dispositivi IDE, qualcosa come hdb o hdc (controllate il boot message usando il comando dmesg). Se qusto è il solo vostro CD-ROM drive, potete dire di no a tutte le altre opzioni CD-ROM, ma siate sicuri di abilitare anche l'opzione di supporto per il ISO 9660 CD-ROM filesystem. Notate che le più vecchie versioni di LILO (LInux LOader) non possono trattare appropriatamente con IDE/ATAPI CD-ROM, così installate LILO 16 superiore, disponibile da http://lilo.go.dyndns.org.

BLK_DEV_IDEFLOPPY

Includi supporto floppy IDE/ATAPI

Se avete un floppy drive IDE che usa il protocollo ATAPI, rispondete sì. ATAPI è il più recente protocollo usato dai drive IDE CD-ROM/tape/floppy, simile al protocollo SCSI. L'LS-120 e il drive IDE/ATAPI Iomega ZIP sono anche supportati da questo driver. Per informazioni sulle impostazioni dei jumper, e domande su quando un drive ZIP usa una tabella di partizione, guardate http://www.win.tue.nl/~aeb/linux/zip/zip-1.html. (I drive ATAPI PD-CD/CDR non sono supportati da questo driver; il supporto per i drive PD-CD/CDR è disponibile se rispondete di sì a "SCSI emulation support"). Se dite sì qui, il drive floppy verrà identificato tra gli altri dispositivi IDE, con un nome quale hdb o hdc (controllate il messaggio di boot usando il comando dmesg).

SCSI

Supporto ai dispositivi SCSI

Se volete usare un hard disk SCSI, tape drive SCSI, SCSI CDROM, o qualsiasi altro dispositivo SCSI sotto Linux, dite sì e siate sicuri di conoscere il nome del vostro SCSI host adapter (la scheda dentro il vostro computer che "parla" il protocollo SCSI, anche chiamato controller SCSI), dato che vi verrà chiesto. Dovrete dire di sì anche se avete un dispositivo che parla con protocollo SCSI. Esempi di questo includono la versione di porta parallela del drive IOMEGA ZIP, dispositivi storage USB, Fibre Channel, storage FireWire, e il driver per l'emulazione IDE-SCSI. Non compilate come modulo se il vostro root filesystem (quello che contiene la directory /) è posizionato su un dispositivo SCSI.

BLK_DEV_SD

SCSI disk support Se volete usare hard disk SCSI, dischi Fibre Channel, USB storage, o la SCSI o porta parallela del drive IOMEGA ZIP, dite sì e leggete il SCSI-HOWTO, il Disk-HOWTO, e il Multi-Disk-HOWTO, disponibile da http://www.tldp.org/docs.html#howto. Questo non è per i CD-ROM SCSI. Non compilate questo driver come modulo se il vostro root filesystem (quello che contiene la directory /) si trova su un disco SCSI. In questo caso, non compilate anche il driver per il vostro SCSI host adapter come modulo.

CHR_DEV_ST

Supporto SCSI tape

Se volete usare un tape drive SCSI sotto Linux, dite sì e leggete il SCSI-HOWTO, disponibile da http://www.tldp.org/docs.html#howto, e Documentation/scsi/st.txt nel kernel source. Questo non è per i CD-ROM SCSI.

CHR_DEV_ST

Supporto CD-ROM

Se volete usare un SCSI o FireWire CD-ROM sotto Linux, dite sì e leggete il SCSI-HOWTO e CDROM-HOWTO a http://www.tldp.org/docs.html#howto per più indicazioni. Siate anche sicuri di abilitare l'opzione al supporto a ISO 9660 CD-ROM filesystem.

CHR_DEV_SG

Supporto SCSI generico

Se volete usare scanners SCSI, sintetizzzatori, o CD writer, o qualsiasi cosa che abbia "SCSI" nel suo nome oltre che gli hard disk, CD-ROM, o tape, dite di sì qui. Questi non verranno supportati dal kernel direttamente, così avrete bisogno di alcuni software addizionali che sanno come parlare a questi dispositivi usando il protocollo SCSI. Per gli scanner, guardate a SANE http://www.sane-project.org. Per il software dei CD writer guardate Cdrtools, http://cdrecord.berlios.de/old/ private/cdrecord.html, e per masterizzare un "disk at once" guardate CDRDAO, http://cdrdao.sourceforge.net. Cdparanoia è un lettore digitale di audio CD di alta qualita' (http://www.xiph.org/paranoia). Per gli altri dispositivi, è possibile che dobbiate scrivere il driver software voi stessi. Perfavore leggete il file Documentation/scsi/scsigeneric.txt per ulteriori informazioni.

CHR_DEV_SCH

Supporto SCSI media changer

Questo è un driver per i media changer SCSI. I più comuni di tali dispositivi sono i tape libraries e MOD/CD-ROM jukeboxe. Questa opzione è per i veri jukeboxes; non ne avete bisogno per tiny six-slot CDROM changers. Media changer sono listati come "Type Medium Changer" in /proc/scsi/scsi. Controllate Documentation/scsi/scsi-changer.txt per i dettagli.

SCSI_MULTI_LUN

Sonda tutti i LUNs su ogni SCSI device

Se avete un dispositivo SCSI, come un CD jukebox, che supporta più di un LUN (Logical Unit Number), e solo un LUN viene riconosciuto, voi potete dire di sì qui per forzare il driver SCSI per sondare LUN multipli. Un dispositivo SCSI con LUN multipli si comporta locigamente come un dispositivo SCSI multiplo. La maggior parte dei dispositivi SCSI hanno un solo LUN, e così molte persone possono dire no qui. Il parametro max_lunsboot/module vi permette di sovrascrivere questa impostazione.

SCSI_SATA

Supporto Serial ATA (SATA)

Questa famiglia di driver supportano il serial ATA host controller e i dispositivi.

MD

Supporto driver ai dispositivi multipli

Questa opzione supporta multipli fisici "spindles" attraverso un singolo dispositivo logico che è richiesto per il RAID e il logical volume management.

BLK_DEV_MD

Supporto RAID

Questo driver vi permette di combinare alcune partizioni hard disk in un unico dispositivo a blocco logico. Questo può venir usato per semplificare l'aggiunta di una partizione a un altra o per combinare alcuni hard disk ridondanti in un dispositivo RAID 1, RAID 4, o RAID 5 per fornire protezione contro i failure degli hard disk. Questo viene chiamato RAID software per l'unione delle partizioni che viene fatto dal kernel. Il RAID hardware significa che l'unione è fatta da un controller dedicato. Se avete tale controller, non avete bisogno di dire sì qui. Ulteriori informazioni su software RAID su Linux sono in "Software RAID" mini-HOWTO, disponibile da http://www.tldp.org/docs.html#howto. Li' imparerete dove recuperare il supporto userspace raidtools utilities.

BLK_DEV_DM

Supporto Device mapper

Device mapper è un low-level volume manager. Funziona permettendo alle persone di specificare mappings per intervalli di settori logici. Vari tipi di mapping sono disponibili, in aggiunta a quelle persone che possono scrivere il proprio modulo contenente mapping personalizzate. Il più alto livello di volume manager come LVM2 usa questo driver.

IEEE1394

Supporto IEEE 1394 (FireWire)

IEEE 1394 descrive un serial bus ad alte performance, che è anche conosciuto come FireWire o i.Link e è usato per connettere ogni tipo di dispositivo (i più notabili, le camere video digitali) ai vostri computer. Se avete dell'hardware firewire e volete usarlo, dite di sì qui. Questo serve solo per il supporto core. Avrete anche bisogno di selezionare un driver per il vostro adattatore IEEE 1394.

I20

Supporto I20

L'intelligente architettura Input/Output (I2O) permette ai driver hardware di venir divisi in due parti: un modulo specifico per il sistema operativo chiamato l'OSM e un modulo specifico per l'hardware chiamato HDM. L'OSM può parlare a un intero range di HDM, e idealmente gli HDMs non sono dipendenti dall'OS. Questo permette per lo stesso driver HDM di venir usato in SO differenti se esiste il relativo OSM. Affiché questo funzioni, avete bisogno di avere un adattatore di interfaccia I20 nel vostro computer. Questa scheda contiene un processore speciale (IOP), che permette alte velocità dato che la CPU non deve avere a che fare con gli I/O. Se dite sì qui, otterete una lista di driver per interfacce di adattatori e OSM e dovrete abilitare quelle corrette.

NETDEVICES

Supporto ai dispositivi di rete

Potete dire di no qui se non intendete la vostra Linux box a qualsiasi altro computer. Dovete dire di sì se il vostro computer contiene una scheda di rete che volete usare in Linux. Se dovrete usare SLIP o PPP su una linea telefonica o un cavo null modem dovrete allora dire di sì. Connettere due macchine con le porte parallele usando PLIP necessita questo, lo stesso come per AX.25/KISS, per mandare il traffico Internet sui link degli amateur radio. Guardate anche "the Linux Network Administrator's Guide" di Tony Bautts et al. (O'Reilly), disponibile a http://www.tldp.org/guides.html.

NET_ETHERNET

Ethernet (10 or 100 Mbit)

Ethernet (anche chiamata IEEE 802.3 or ISO 8802-2) è il tipo più comune di Local Area Network (LAN) nelle università e industrie. Le comuni varietà di Ethernet sono 10-base2 o Thinnet (10 Mbps su cavo coassiale, che uniscono i computer in una catena), 10-baseT o coppia incrociata (10 Mbps su cavo a coppia incrociata, che unisce i computer ad un hub centrale), 10-baseF (10 Mbps su collegamenti a fibra ottica, usando hubs), 100-baseT4 (100 Mbps sopra quattro standard cavi a coppia incrociata "voice-grade", usando hubs), e gigabit Ethernet (1 Gbps sopra fibra ottica o collegamenti di rame corti). Le varietà 100-base sono anche conosciute come Fast Ethernet. Se la vostra macchina Linux verrà connessa a un Ethernet e avete una Ethernet network interface card (NIC) installata nel vostro computer, dite sì qui e leggete l'Ethernet-HOWTO, disponibile da http://www.tldp.org/docs.html#howto. Avrete bisogno anche di dire sì al driver della vostra particolare NIC. Notate che la risposta a questa domanda non interesserà direttamente il kernel: dire no causerà solo che il configuartore salterà tutte le domande sulle Ethernet network cards.

NET_RADIO

Wireless LAN drivers (non-hamradio) e Wireless Extensions

Supporto per le LAN wireless e a ognicosa che ha a che fare con il packet radio, ma non con amateur radio o FM broadcasting. Dire sì qui abilita anche il Wireless Extensions, creando /proc/net/wireless e abilitando iwconfig access. Le Wireless Extensions sono delle API generiche che permettono a un driver di esporre la configurazione e le statistiche per le wireless LAN comuni nello userspace. Le Wireless Extension provvedono un singolo set di tools che possono supportare tutte le variazioni delle LAN wireless, senza pensare al loro tipo (dal momento che il driver supporta le Wireless Extension). Un altro vantaggio è che questi parametri possono venir cambiati al volo senza far ripartire il driver o il sistema operativo. Se desiderate usare le Wireless Extension con le schede wireless PCMCIA (PC cards), dovete dire di sì qui. Potete recuperare i tool da http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html.

PPP

Supporto PPP (Point-to-Point Protocol)

PPP manda traffico internet su linee telefoniche (e altre seriali). Chiedete al vostro provider di accesso se lo supportano, perché altrimenti, non potete usarlo. Un protocollo più vecchio con lo stesso scopo è chiamato SLIP. Molti internet access provider di questi giorni supportano PPP invece di SLIP. Per usare PPP, avete bisogno di un programma addizionale chiamato pppd come descritto nel PPP-HOWTO, disponibile a http://www.tldp.org/docs.html#howto. Siate sicuri di avere la versione raccomandata in Documentation/Changes. L'opzione PPP allarga il vostro kernel di circa 16KB. Ci sono attualmente due versioni di PPP: il PPP tradizionale per le linee asincrone, come le le lineee analogiche tradizionali, e il PPP sincrono, che può venir usato sulle linee digitali ISDN, per esempio. Se volete usare PPP sulle linee telefoniche o altre linee seriali asincrone, avete bisogno di abilitare l'opzione al supporto PPP per le porte seriali asincrone.

PPPOE

PPP over Ethernet (sperimentale)

Supporto per il PPP su Ethernet. Questo driver richiede l'ultima versione di pppd dal repository CVS a cvs.samba.org. Alternativamente, guardate il RoaringPenguin package http://www.roaringpenguin.com/pppoe, che contiene le istruzioni su come usare il driver sotto l' "heading" "Kernel mode PPPoE".

ISDN

Supporto ISDN

ISDN (Integrated Services Digital Networks, chiamato RNIS in Francia) è un tipo speciale di telefono con servizio completamente digitale; viene maggiormente utilizzato per connetervi al vostro Internet service provider (con SLIP or PPP). Il vantaggio principale dell'ISDN è che la velocità è più alta di quella ordinaria di connessione del modem/telefono e che potete avere la conversazione vocale mentre scaricate dati. Funziona solo se il vostro PC è dotato di una scheda ISDN e sia voi che il vostro fornitore compriate una linea ISDN dalla compagnia telefonica. Per dettagli, leggete http://www.alumni.caltech.edu/~dank/isdn. Scegliete questa opzione se volete che il kernel supporti ISDN.

PHONE

Supporto Linux telefonico

Dite sì qui se avete una scheda telefonica, che, per esempio, vi permette di usare un normale telefono per applicazione voice over IP.

INPUT

Layer di input generico (necessario per keyboard, mouse, ...)

Dite sì qui se avete qualsiasi dispositivo di input (mouse, keyboard, tablet, joystick, steering wheel, ecc...) connesso al vostro sistema e volete che sia disponibile alle applicazioni. Questo include una standard keyboard PS/2 e mouse. Dite no qui se avete un sistema headless (no monitor o keyboard). Maggiori informazioni sono disponibili in Documentation/input/input.txt.

VT

Virtual terminal

Dite sì qui per avere il supporto ai dispositivi terminali con dispositivi display e keyboard. Questi sono chiamati virtuali perché potete eseguire diversi terminali virtuali (anche chiamati console virtuali) su un terminale fisico. Avete bisogno almeno di un dispositivo terminale virtuale affinché possiate usare la vostra keyboard e monitor. Quindi, solo le persone che che configurano un sistema embedded vorranno dire di no qui per salvare della memoria. Il solo modo per "loggarsi" in tale sistema è quindi via seriale o connessione network. I terminali virtuali sono utili dato che, per esempio, un terminale virtuale può mostrare i messaggi di sistema e i warnings, un altro può venir usato per una sessione di utente testuale, e un terzo potrebbe eseguire una sessione X, tutto in parallelo. Cambiare tra le sessioni di terminali virtuali viene fatto con una combinazione di tasti, solitamente Alt-function key. Se siete insicuri, dite sì, o altrimenti non sarete di fare molto con il vostro sistema Linux.

VT_CONSOLE

Supporto per la console su terminale virtuale

La console di sistema è il dispositivo che riceve tutti i messaggi del kernel e warning e permette i login in single user mode. Se rispondete sì qui, un terminale virtuale (il dispositivo usato per interfacciarsi con un terminale fisico) può venir usato come console di sistema. Questo è il modo più comune di operare, così dovrete dire di sì a meno che vogliate che i messaggi del kernel vengano stampati solo si una porta seriale (nel qual caso dovreste abilitare anche la console su 8250/16550 e l'opzione "compatible serial port"). Se dite sì qui, il terminale corrente visibile (/dev/tty0) sarà usato come console di sistema come default. Potete cambiarlo con una opzione kernel da linea di comando come console=tty3, che specifica il terzo terminale virtuale come system console. (Guardate il capitolo 9 per i dettagli su come passare le opzioni al kernel a boot time, e quali opzioni sono disponibili).

SERIAL_8250

8250/16550 e supporto seriale compatibile

Questo seleziona se volete includere il driver per la porta seriale standard. La risposta standard è sì. Le persone che potrebbero dir di no sono quelle che stanno preparando dei server Ethernet WWW/FTP, o un utente che ha una dei vari bus mice invece di un mouse seriale per qualsiasi cosa. In aggiunta, il Cyclades and Stallion multiserial port driver non hanno bisogno di questo driver.

Molte persone diranno sì qui, così che potranno usare i mouse seriali, modem, e dispositivi simili connessi alle porte seriali satndard.

AGP

/dev/agpgart (Supporto AGP)

AGP (Accelerated Graphics Port) è un bus system usato principalmente per connettere le schede grafiche al resto del sistema. Se avete un sistema AGP e dite sì qui, sarà possibile usare le caratteristiche AGP 3D rendering della vostra scheda video. Questo codice si comporta come una sorta di "AGP driver" per il motherboard's chipset. Se avete bisogno di più texture memory di quella che potete avere con l'AGP GART (teoricamente fino a 256 MB, ma in pratica di solito 64 o 128 MB dovuti ai problemi di allocazione del kernel), potete usare un accesso PCI e avere fino a un paio di gigabytes di texture space. Notate che questo è il solo modo per avere l'uso di X e GLX in scrittura combinata con il supporto MTRR su bus AGP. Senza questa opzione, OpenGL direct rendering sarà un sacco più lento, ma sempre più veloce che PIO. Dovreste dire sì qui se volte usare GLX o DRI.

DRM

Direct Rendering Manager (XFree86 4.1.0 e supporto DRI maggiore)

Il supporto Kernel-level per il Direct Rendering Infrastructure (DRI) è stato introdotto in XFree86 4.0. Se dite sì qui, dovrete selezionare il modulo corretto per la vostra scheda grafica dalla lista. Questi moduli forniscono il supporto per la sincronizzazione, sicurezza, e trasferimenti DMA. Guardate http://dri.sourceforge.net per i dettagli. Dovrete anche selezionare e configurare il supporto AGP.

I2C

Supporto I2C

I2C pronunciato "I-square-C" è un protocollo di bus seriale lento sviluppato da Philips e usato in molte applicazioni micro controller. SMBus, o System Management Bus, è un subset del protocollo I2C. Maggiori informazioni sono contenute nella directory Documentation/i2c, specialmente nel file chiamato summary. Sia I2C che SMBus sono supportati da questa opzione. Ne avrete bisogno per il supporto di sensori hardware e per il supporto Video For Linux. Se volete il supporto I2C, oltre a dire sì, dovete anche selzionare il driver specifico per i vostri adattatori bus.

SPI

Supporto SPI

Il Serial Peripheral Interface (SPI) è un protocollo sincrono di basso livello. I chip che supportano SPI possono avere un rate di trasferimento fino ad alcuni decine di Mbps. I chip sono indirizzati con un controller e chipselect. Molti SPI slave non supportano il "dynamic device discovery"; alcuni sono persino o write-only o read-only. SPI è largamento utilizzato dai microcontroller per parlare con i sensori, EEPROM e flash memory, codec e vari altri chip controller, convertitori "analog-to-digital" e "digital-to-analog", e inoltre, schede MMC e SD che possono essere accedute usando il protocollo SPI, e per le schede DataFlash usate nei socket MMC, SPI deve sempre venir utilizzato. SPI è uno dei protocolli di una famiglia o simili che usano una interfaccia four-wire (select, clock, data in, e data out), incluso Microwire (half duplex), SSP, SSI, e PSP. Questo driver framework dovrebbe funzionare con la maggior parte di tali dispositivi e controller.

HWMON

Supporto Hardware-monitoring

I dispositivi Hardware-monitoring vi permettono di monitorare lo stato di salute di un sistema. Molte delle moderne motherboard includono questo dispositivo. Può includere i sensori della temperatura, i sensori di tensione, i sensori di velocità delle ventole, e varie altre caratteristiche come la possibilità di controllare la velocità delle ventole. Se volete questo supporto dovrete dire sì qui e anche al driver specifico per il chip dei vostri sensori.

VIDEO_DEV

Video for Linux

Questa opzione abilita il supporto per la registrazione audio/video, per i dispositivi di overlay e per le schede radio FM. L'esatta capacità di ogni dispositivo e' variabile. Il kernel include il supporto per le nuove API Video for Linux Two, (V4L2) a enche per il sistema originale. I driver e le applicazioni devono venir riscritte per poter usare V4L2, ma i driver per le schede più popolari e applicazioni per molte funzioni di video capture esistono di già. Ulteriori informazioni e doc sono disponibili a http://linuxtv.org. Documentazione per V4L2 è anche disponibile a http://bytesex.org/v4l.

DVB

DVB per Linux

Questa opzione abilita il supporto per l'hardware Digital Video Broadcasting. Abilitate questo se possedete un DVB adapter e volete usarlo o se se state compilando un Linux per un digital set-top box. API spec e user tools sono diponibili da http://www.linuxtv.org.

FB

Supporto per i dispositivi frame buffer

Il dispositivo frame buffer provvede una astrazione per l'hardware grafico. Rappresenta il frame buffer di qualche hardware video e permette al software applicativo di accedere all'hardware grafico attraverso una ben definita interfaccia, così che il software non ha bisogno di sapere nulla su tutto il low level (i registri hardware) della scheda. I dispositivi di frame buffer lavorano identicamente lungo le differenti architetture supportate da Linux e rendono l'implementazione di programmi applicativi più facili e più portabili. A questo punto, un server X che usa il dispositivo di frame buffer esclusivamente esiste. Su alcune architetture non-X86, il dispositivo di frame buffer è l'unico modo di usare l'hardware grafico. Avrete bisogno di un programma chiamato fbset per avre un pieno uso dei dispositivi framebuffer. Leggete la documentazione Documentation/fb/framebuffer.txt e il Framebuffer-HOWTO, disponibile a http://www.tldp.org/HOWTO/Framebuffer-HOWTO.html per maggiori informazioni. Dite sì qui e al driver della vostra scheda grafica se state compilando un kernel per una architettura non-x86. Se state compilando per una architettura x86, potete dire sì qui se volete usare il frame buffer ma non è essenziale. Notate che eseguire applicazioni grafiche che toccano direttamente l'hardware (p.e., X server accelerato) e che non sono accordati al dispositivo frame buffer possono causare risultati inaspettati.

VGA_CONSOLE

VGA text console

Dicendo sì qui vi permetterà di usare Linux in modalità testuale attraverso un display che si conforma allo standard generic VGA. Virtualmente ognuno vuole questo. Il programma SVGATextMode può venir usato per utilizzare le schede video SVGA al loro pieno potenziale in modalità testuale. Scaricatelo da ftp://ibiblio.org/pub/Linux/utils/console.

LOGO

Bootup logo

Questa opzione abilita il logo del simpatico pinguino a boot time. Verrà mostrato sul frame buffer mentre il kernel è in booting. Il numero dei pinguini mostra il numero dei processori che il kernel ha trovato.

SOUND

Supporto per la scheda sonora

Se avete una scheda sonora nel vostro computer--"i.e.e.", se può creare più di un isolato beep--dite sì. Siate certi di avere tutte le informazioni della vostra scheda sonora e la sua configurazione (porta I/O, interrupt e canale DMA), dato che vi verrà chiesto. Leggeete il Sound-HOWTO, disponibile da http://www.tldp.org/docs.html#howto. Della informazione generale su il modular sound system è contenuta nel file Documentation/sound/oss/Introduction. Il file Documentation/sound/oss/README.OSS alcune informazioni leggermente datate ma ancora utili certamente. Nuova documentazione sui sound driver può esser trovata nella directory Documentation/sound/alsa. Se avete una scheda sonora PnP e volete configurarla a boot time usando i tool ISA PnP (leggete http://www.roestock.demon.co.uk/isapnptools), avete bisogno di caricare il driver della scheda sonora come modulo e caricarlo dopo che la configurazione PnP è terminata. Per fare ciò correttamente, leggete Documentation/sound/oss/README.modules. Mi è stato detto che anche senza una scheda sonora, potete creare più di un occasionale beep programmando il PC speaker. Le patch del kernel e le utility di supporto per fare ciò sono nel package pcsp, disponibile a ftp://ftp.infradead.org/pub/pcsp.

SND

Advanced Linux Sound Architecture

Dite sì per abilitare ALSA (Advanced Linux Sound Architecture), il sistema standard per il suono in Linux. Per maggiori informazioni, guardate http://www.alsa-project.org.

SND_USB_AUDIO

USB Audio/MIDI driver

Dite sì qui per includere il supporto ai dispositivi USB audio e USB MIDI

USB

Supporto per USB host-side

Universal Serial Bus (USB) è una specifica per il serial bus subsystem che offre velocità maggiori e ulteriori caratteristiche rispetto alla porta seriale del PC tradizionale. Il bus provvede l'alimentazione alle periferiche e consente l'hot swapping. Fino a 127 periferiche possono essere attaccate a un singolo host USB in una struttura ad albero.

L'host USB è la radice dell'albero, le periferiche sono le foglie, e i nodi più interni sono speciali dispositivi USB chiamati hubs. Molti PC hanno ora le porte host USB, usate per connettere periferiche quali scanner, tastiere, mice, modem, macchine fotografiche, dischi, flash memory, network link, e stampanti al PC.

Dite sì qui se il vostro computer ha una porta host-side USB e volete usare dispositivi USB. Avrete poi bisogno di dire sì almeno a uno delle seguenti opzioni Host Controller Driver (HCD), come il supporto UHCI HCD o OHCI HCD, e al supporto EHCI HCD (USB 2.0) fatta eccezione per i sistemi vecchi che non hanno il supporto USB 2.0. Non c'è nessun pericolo se li selezionate tutti in caso siate incerti.

Sel vostro sistema ha una porta "device-side USB", usato dal lato periferico del protocollo USB, guardate invece l'opzione USB Gadget.

Dopo aver scelto il vostro HCD, selezionate il driver della periferica USB che userete. Forse vorrete controllare le informazioni fornite in Documentation/usb e specialmente il link dato in Documentation/usb/usb-help.txt.

USB_EHCI_HCD

Supporto EHCI HCD (USB 2.0)

L'Enhanced Host Controller Interface (EHCI) è uno standard per l'host controller hardware di USB 2.0 "high-speed" (480 Mbit/sec, 60 Mbyte/sec). Se il vostro USB host controller supporta USB 2.0, vorrete certamente configurare questo HCD. Nel momento in cui scrivo, la principale implementazione di EHCI è un chip NEC, largamente disponibile in aggiunta sulle schede PCI, ma implementazioni sono in fase di sviluppo da parte di altri vendor, incluso Intel e Philips. Il supporto alla Motherboard sta emergendo. I controller EHCI sono impacchettati con gli host controller "companion" (OHCI o UHCI) per gestire i dispositivi USB 1.1 connessi alle porte root hub. Le porte saranno connesse all'EHCI se il dispositivo è high-speed; altrimenti, si connettono a un controller companion. Se configurate EHCI, vorrete probabilmente configurare l'OHCI (per NEC e altri vendors) USB HCD o UHCI (per le motherboard VIA) e anche HCD. Se volete leggete Documentation/usb/ehci.txt per maggiori informazioni su questo driver.

USB_OHCI_HCD

Supporto OHCI HCD

L'Open Host Controller Interface (OHCI) è uno standard per accedere agli host controller hardware USB 1.1. Lavora più in hardware rispetto alle specifiche Intel UHCI. Se il vostro host controller USB segue le specifiche OHCI, dite sì. Su molti sistemi non-x86, e su hardware x86 che non usa USB controller da Intel e VIA, questo è appropriato. Se il vostro host controller non usa PCI, questo è probabilmente appropriato. Su un sistema PCI-based dove non siete sicuri, il comando lspci -v elencherà il corretto prog-if per il/i vostro/i USB controller: EHCI, OHCI, or UHCI.

USB_UHCI_HCD

Supporto UHCI HCD (maggiormente Intel and VIA)

L'Universal Host Controller Interface è uno standard creato da intel per accedere all'USB hardware nel PC (che è anche chiamato USB host controller). Se il vostro USB host controller è conforme a questo standard, potreste voler dire sì qui. Tutte le schede recenti con Intel PCI chipsets (come Intel 430TX, 440FX, 440LX, 440BX, i810, i820) si conformano a questo standard. Tutti i VIA PCI chipsets (come VIA VP2, VP3, MVP3, Apollo Pro, Apollo Pro II, o Apollo Pro 133) usano anch'essi questo standard.

USB_STORAGE

Supporto USB mass storage

Dite sì qui se volete connettere un dispositivo USB mass storage alla vostra porta USB del computer. Questo è il driver di cui avete bisogno per i floppy drive USB, USB hard disk, USB tape drive, USB CD-ROM, USB flash device, e memory stick, e tutti gli altri dispositivi simili. Questo driver può anche essere usato per alcune camera e card reader. Questa opzione abilita l'opzione SCSI, ma voi probabilmente avrete bisogno anche del supporto ai dispositivi SCSI: Supporto SCSI disk per la maggior parte dei dispositivi USB storage per farli funzionare correttamente.

USB_SERIAL

Supporto USB serial converter

Dite sì qui se avete un dispositivo USB che fornisce porte seriali normali, o si comporta come un dispositivo seriale, e volete conneterlo al vostro bus USB. Leggete Documentation/usb/usb-serial.txt per maggiori informazioni sulle specifiche dei differenti device che vengono supportati e come usarli.

USB_GADGET

Supporto per i gadget USB

USB è un protocollo master/slave, organizzato con un master host (come un PC) che controlla fino a 127 dispositivi periferici. L'hardware USB è asimmetrico, che significa più facile da impostare: non potete connettere un connettore "to-the-host" a una periferica.

Linux può girare nell'host o nella periferica. In entrambi i casi avete bisogno di un di un driver per il controller a basso livello e alcuni software che parlano con esso. I controller periferici possono essere sia discrete silicon o integrati con la CPU in un microcontroller. Il controller hostside più familiare hanno nomi come EHCI, OHCI, o UHCI, e sono solitamente integrati nei southbridge delle motherboards dei PC.

Abilitate questa opzione di configurazione se volete far giarre Linux dentro un dispositivo USB periferico. Configurate un driver hardware per il vostro controller peripheral/device side bus, e un "gadget driver" per il vostro prtocollo periferico. (Se usate gadget driver modulari, potete configurarne più di uno).

Nel dubbio, dite no e non abilitate questi driver; la maggior parte delle persone non hanno questo tipo di hardware (fatta eccezione forse dentro i PDA Linux). Per maggiori informazioni, guardate http://www.linux-usb.org/gadget e il kernel DocBook documentation for this API.

MMC

Supporto MMC

MMC è il protocollo MultiMediaCard bus. Se volete il supporto MMC, dovreste dire sì qui e anche al driver specifico per la vostra interfaccia MMC.

EDAC

EDAC core system error reporting (sperimentale)

EDAC è progettato per riportare errori nel core system. Sono errori low-level che vengono riportati dalla CPU o dai chipset supportati: errori di memoria, errori cache, errori PCI, thermal throttling, ecc... . Se questo codice riporta dei problemi sul vostro sistema, guardate la pagina web del progetto EDAC, per maggiori informazioni: http://bluesmoke.sourceforge.net e http://buttersideup.com/edacwiki.

EXT2_FS

Supporto a Second extended filesystem

ext2 è un filesystem standard di Linux per hard disk. Molti sistemi invece usano l'upgrade, ext3.

EXT3_FS

Supporto a Third extended filesystem

Questa è la versione journaling (chiamata ext3) del second extended filesystem, lo standard de facto per i filesystem Linux su hard disk. Il codice journaling è incluso in questo driver, significa che voi non dovete eseguire fsck (filesystem checker) sui vostri filesystem dopo un crash. Il journal tiene traccia di ogni cambiamento che èstato fatto al momento del crash del sistema, e può assicurare che il vostro filesystem è consistente senza il bisogno di un lungo check. Oltre all'aggiunta del journal al filesystem, il formato on-disk di ext3 è identico a ext2. E' possibile scambiare liberamente tra il driver ext3 e il driver ext2, fin tanto che il filesystem è stato "smontato" pulitamente, o fsck viene eseguito sul filesystem prima dello switch. Per aggiungere un journal a un filesystem ext2 esistente o cambiare il comportamento del filesystem ext3, potete usare l'utility tune2fs. Per modificare gli attributi dei file e directory sui filesystem ext3, usate chattr. Avrete bisogno della versione 1.20 o superiore di e2fsprogs per creare un journal ext3 (disponibili a http://sourceforge.net/projects/e2fsprogs).

REISER_FS

Supporto a ReiserFS

Questo è un filesystem "journaled" che salva non solo i nomi dei file ma i file stessi in un albero bilanciato. Gli alberi bilanciati possono essere più efficienti delle "foundation" architetture di filesystem tradizionali. In generale, ReiserFS è veloce quanto ext2, ma è piu' efficiente con larghe directory e file piccoli.

JFS_FS

Supporto a JFS filesystem

Questo è un port del Journaled Filesystem (JFS) di IBM. Maggiori informazioni sono disponibili nel file Documentation/filesystems/jfs.txt.

XFS_FS

Supporto a XFS filesystem

XFS è un journaling filesystem ad alte performance che ha origini da una piattaforma SGI IRIX. E' completamente multithreaded; supporta larghi file e larghi filesystem, attributi estesi, e misure di blocchi variabili; è extent-based; fa un uso estensivo di B-tree; e usa directory, extent, e spazio libero per aiutare le performance e la scalability. Fate riferimento alla documentazione a http://oss.sgi.com/projects/xfs per dettagli completi. L'implementazione è compatibile on-disk con la versione IRIX di XFS.

OCFS2_FS

Supporto a OCFS2 filesystem

OCFS2 è un filesystem con scopo generico, extent-based, cluster a dischi condivisi con molte similarità a ext3. Supporta gli inode a 64-bit e ha automaticamente gruppi "extending metadata", che lo possono anche rendere attraente per usi non cluster. Vorrete installare il pacchetto ocfs2-tools almeno per avere il programma mount.ocfs2. La pagina web del progetto è http://oss.oracle.com/projects/ocfs2 e la pagina web dei tool è http://oss.oracle.com/projects/ocfs2-tools. La mailing list di OCFS2 può essere trovata a http://oss.oracle.com/projects/ocfs2/mailman.

INOTIFY

Supporto a inotify file change notification

Dite sì qui per abilitare il supporto a inotify e al sistema di chiamate associato. inotify è un sistema di notifica di file change e un sostituto di dnotify. inotify risolve numerosi mancanze di dnotify e introduce nuove caratteristiche. Permette il monitoring sia di file che di directory via un singolo oggetto fd aperto. Altre caratteristiche includono il multiple file events, il supporto one-shot, e la notifica di unmount. Per maggiori informazioni, guardate Documentation/filesystems/inotify.txt.

QUOTA

Supporto quota

Se dite sì qui, sarete in grado di impostare i limiti di uso del disco per-user (anche detto "disk quota"). Attualmente, funziona per ext2, ext3, e ReiserFS filesystem. ext3 suporta anche il "journaled quota", per il quale non avete bisogno di eseguire quotacheck dopo uno shutdown sporco. Per maggiori dettagli, leggete il "Quota" mini-HOWTO, disponibile da http://www.tldp.org/docs.html#howto o la documentazione fornita con i quota tool. Il supporto quota è probabilmente utile solo per i sistemi multiuser.

AUTOFS_FS

Supporto a Kernel automounter

L'automounter è un tool che monta automaticamente i filesystem remoti on demand. Questa implementazione è parzialmente kernel-based per ridurre l'overhead quando un sistema è già montato. Questo è differente dell'automounter BSD (amd), che è un demone completamente in userspace. Per usare l'automounter, avete bisogno dei userspace tool dal pacchetto autofs; potete trovare la locazione in Documentation/Changes. Vorrete anche rispondere di sì all'opzione per il supporto di NFS filesystem. Se volete usare la più recente versione di automounter con maggiori caratteristiche, dite no qui e dite sì all'opzione di supporto del Kernel automounter. Se non fate parte di un "fairly large", network distribuito, probabilmente non avete bisogno di un automounter, e potete dire di no qui.

FUSE_FS

Supporto a Filesystem in userspace

Con FUSE è possibile implementare un filesystem pienamente funzionante in un programma userspace. C'è anche una "companion" library chiamata libfuse. Questa libreria, insieme alle utility, è dipsonibile dalla homepage di FUSE: http://fuse.sourceforge.net. Guradate Documentation/filesystems/fuse.txt per maggiori informazioni. Guardate Documentation/Changes per la versione di library/utility di cui avete bisogno. Se volete sviluppare un filesystem in userspace, o se volete usare un filesystem basato su FUSE, rispondete sì qui.

SMB_FS

Supporto a SMB filesystem (per montare Windows share ecc.)

SMB (Server Message Block) è il protocollo Windows per Workgroups (WfW), Windows 95/98, Windows NT e varianti successive, e OS/2 LAN Manager usano condividere file e stampanti nella rete locale. Dicendo di sì qui vi permette di montare i loro filesystem (spesso chiamate "shares" in questo contesto) e accedeci come ogni altro Unix directory. Attualmente, questo funziona solo se la macchina Windows usa TCP/IP come il protocollo underlying di trasporto, no NetBEUI. Per dettagli, leggete Documentation/filesystems/smbfs.txt e il SMB-HOWTO, disponibile da http://www.tldp.org/docs.html#howto.Se volete che la vostra box si comporti come un SMB server e siano disponibili i servizi file e printing ai client Window (che hanno biosgno di avere uno satck TCP/IP), non avete bisogno di dire si' qui; poetet usare il Samba set di daemon e programmi (disponibili da ftp://ftp.samba.org/pub/samba).

CIFS

Supporto a CIFS (advanced network filesystem per Samba, Window, e altri CIFS server compatibili)

Questo è il clent VFS module per il protocollo Common Internet File System (CIFS), che è il successore al protocollo Server Message Block (SMB), il meccanismo nativo di file-sharing per la maggior parte dei sistemi operativi dei PC. Il protocollo CIFS è pienamente suppotato da file server come Windows 2000 (incluso Windows 2003, NT 4, e Windows XP) come da Samba (che provvede un eccellente supporto a CIFS per Linux e molti altri sistemi operativi). Supporto limitato per Windows ME e server similari è anche fornito. Dovete usare il smbfs client filesystem per accedere ai più vecchi SMB server come OS/2 e DOS. L'intento del modulo cifs è di fornire un advanced network filesystem client per montare filesystem locali a server CIFS-compliant, includendo il supporto per DFS (hierarchical namespace), secure per-user session establishment, safe distributed caching (oplock), optional packet signing, Unicode e altri improvement internazionali, e integrazione opzionale Winbind (nsswitch). Non avete bisogno di abilitare cifs se state eseguendo solo un server (Samba). E' possibile abiliater sia smbfs che cifs (p.e., se state usando CIFS per acceder a Windows 2003 e Samba 3 server, e smbfs per accedere ai vecchi server). Se avete bisogno di monatre Samba o Window da queste macchine, dite sì a questa opzione.

PROFILING

Supporto al Profiling (sperimentale)

Dite sì qui per abilitare il meccanismo di supporto a extended profiling usato dai profilers come OProfile.

OPROFILE

OProfilesystem profiling (sperimentale)

OProfile è un profiling system capace di profiling il sistema intero, incluso il kernel, i moduli del kernel librerie, e applicazioni. Per maggiori informazioni e link ai tool in userspace necessari per usare OProfile propriamente, guardate la pagina del progetto principale a http://oprofile.sourceforge.net/news.

KPROBES

Kprobes (sperimentale)

Kprobes vi permette di "trappare" la CPU a quasi ogni indirizzo kernel e eseguire una funzione di callback. register_kprobe( ) stabilisce un probepoint e specificare il callback. Kprobes è utile per il kernel debugging, strumento non intrusivo, e testing.

PRINTK_TIME

Mostra le informazioni del timing con printk

La selezione di questa opzione causa le informazioni di timing di venir incluse in printk (kernel message) output. Questo permette di misurare l'intervallo tra le operazioni del kernel, incluso le operazioni di bootup. Questo è utile per identificare lunghi ritardi nel kernel startup.

MAGIC_SYSRQ

Magic SysRq key Se dite sì qui, avrete qualche controllo sul sistema anche se il sistema va in "crash" per esempio durante kernel debugging (p.e., sarete in grado di svuotare il buffer cache nel disco, fare il reboot del sistema immediatamente, o fare il dump di alcune informazioni di stato). Questo viene compiuto dalla pressione di vari tasti mentre si tiene premuto il tasto SysRq (Alt+PrintScreen). Funzioona anche su una console seriale (su un PC hardware almeno), se inviate un BREAK e poi entro 5 secondi un command keypress. I tasti sono documentati in Documentation/sysrq.txt. Non dite sì a meno che veramnet sapete ciò che questo "hack" fa.

DEBUG_KERNEL

Kernel debugging

Dite sì qui se state sviluppando driver o per fare debug e identificare problemi nel kernel. Di suo, questa opzione non fa niente eccetto che di darvi una possibilità di selezionare altre opzioni.

DEBUG_FS

Debug filesystem

debugfs è un filesystem virtuale dove gli sviluppatori del kernel mettono dei file di debugging. Abilitare questa opzione per essere in grado di leggere e scrivere in questi file.

SECURITY

Abilita differenti modelli di sicurezza

Questo vi permette di configurare differenti modelli di sicurezza nel vostro kernel. Se questa opzione non è selezionata, il "Linux security model" di default sarà usato.

SECURITY_ SELINUX

Supporto a NSA SELinux

Questa seleziona l'NSA Security-Enhanced Linux (SELinux). Avrete bisogno anche di un policy configuration e di un labeled filesystem. Potete trovare il policy compiler (checkpolicy), le utility per il labeling filesystem (setfiles), ed esempi di policy configuration da http://www.nsa.gov/selinux.