Il kernel Linux ha bisogno di un file system per funzionare?

19

La mia opinione è sì, perché ogni esposizione utile al mondo esterno (modalità processore non privilegiata) richiederebbe prima un processo in esecuzione nel mondo esterno. Ciò richiederebbe un file system, anche temporaneo, in-RAM, file system.

Un altro ingegnere non è d'accordo con me, ma non riesco a dimostrarlo al di là di tutti i casi (a me sconosciuti).

La risposta a questa domanda dipende dalla definizione di "corsa"?

filesystems linux-kernel

— Peter L.
fonte

4

penso che un kernel in esecuzione non "richieda"useful exposure to the outside world

— jsotola il

19

Mi viene in mente il vecchio firewall Linux bloccato (circa 2002)

— Jeff Schaller

1

Se aggiungi nuovo codice al kernel, puoi fare qualsiasi cosa. Se non ci riesci, verrà inizializzato fino al punto in cui tenta di essere eseguito init(il primo processo dello spazio utente) e ciò non riuscirà.

— user253751

1

Definisci "corri" ...

— Thorbjørn Ravn Andersen il

Leggi il sistema operativo: tre semplici pezzi

— Basile Starynkevitch il

27

Questa è piuttosto una domanda strana perché non esegui il kernel come se avessi eseguito un programma. Il kernel è una piattaforma su cui eseguire i programmi. Naturalmente c'è il codice di installazione e spegnimento, ma non è possibile eseguire il kernel da solo. Ci deve essere sempre un processo "init" principale. E il kernel andrà in panico se non è lì. Se init tenta di uscire dal kernel anche il panico.

In questi giorni il processo di init è qualcosa di simile a systemd. Se non diversamente specificato, il kernel tenterà di eseguire un programma da un elenco di posizioni che iniziano con /sbin/init. Vedi il parametro init qui http://man7.org/linux/man-pages/man7/bootparam.7.html in un'emergenza con cui puoi avviare Linux init=/bin/bash. Ma nota come specifichi sempre un file sul file system da eseguire.

Quindi il kernel andrà in panico se si avvia e non ha un file system perché senza uno non c'è modo di caricare init.

Potrebbe sorgere un po 'di confusione a causa di una situazione di pollo e uova in cui il kernel deve caricare i driver per accedere al suo file system. Per ovviare a questo, un ramdisk iniziale viene caricato da un'immagine su disco contenente driver vitali e script di installazione. Questi vengono eseguiti prima del caricamento del file system. Ma non fraintendete, il ramdisk iniziale è esso stesso un file system. Con un ramdisk iniziale /initviene chiamato (che è memorizzato nel ramdisk iniziale). In molte distribuzioni è in definitiva questo che chiama /sbin/init. Ancora una volta senza un file system, questo è impossibile.

— Philip Couling
fonte

Non esiste una condizione in cui il kernel smette di tentare di inizializzare l'hardware e caricare un file system noto (non initrd passato nel kernel tramite init params), per poi cadere in una shell molto limitata (senza init = / bin / bash)? Inoltre, dal momento che visualizzi / bin / bash, il kernel avrebbe sempre disponibile quel file system minimo, anche se fosse stato creato con altre opzioni .config che potrebbero potenzialmente eliminarlo?

— Peter L.

1

@PeterL. quella shell limite è una shell da initrd / initramfs / qualunque cosa il kernel abbia avviato, IIRC.

— muru

3

Nota che puoi creare initramfs (un archivio CPIO che viene estratto in un filesystem ramfs o tmpfs) nel kernel. Se conta o meno che il kernel "necessiti di un filesystem" dipende da te, dal momento che significa che puoi avviare il kernel e nient'altro che il kernel e avere un sistema funzionale (se un po 'limitato). Si noti inoltre che, anche se si patch il kernel per non richiedere più un init, creerà comunque filesystem virtuali interni che non vengono mai esposti.

— foresta il

@forest Il sistema non deve essere "limitato": puoi inserire systemd e gnome nel tuo initrd (insieme a cose che sono effettivamente utili ;-)). Una limitazione di initramfs era (ancora è?) Che non appoggiava attributi estesi - ho fatto lavoro intorno ad esso su android includendo un'immagine ext4 nell'archivio cpio initrd che è stato poi montato come un dispositivo di loop dal init.$DEV.rcscript.

— Zio Billy,

1

@IsmaelMiguel, no, un initramfs in quanto tale è un archivio cpio. Squashfs è una buona scelta per i filesystem incorporati, e si potrebbe creare un initrd (vs un initramfs) che lo usa (i termini sono spesso usati in modo intercambiabile ma non sono esattamente la stessa cosa), ma non è il formato che Linux scompone nella sua initramfs. (In effetti, non è necessario decomprimere un'immagine di squashfs prima di poter essere utilizzata; è correttamente indicizzata).

— Charles Duffy,

16

La risposta dipenderà dal fatto che intendi letteralmente senza un file system o se la domanda deve essere interpretata in modo leggermente diverso da come viene effettivamente dichiarata. Le risposte a lievi variazioni nel modo in cui viene interpretata la domanda sono:

L'esecuzione di Linux senza dispositivi a blocchi è del tutto fattibile e utile per alcuni casi d'uso specializzati.
L'esecuzione di Linux senza alcun file system richiederà la riscrittura di alcune parti del codice del kernel ed è improbabile che sia uno sforzo utile.
L'esecuzione di Linux senza l'utilizzo di descrittori di file richiederà molto impegno. Sono abbastanza sicuro che non varrà la pena.

I motivi per cui dovresti riscrivere parti del codice del kernel per creare un sistema funzionante senza un file system sono:

Ogni thread ha una directory root e una directory di lavoro corrente che deve puntare a un file system.
I programmi vengono avviati dalla execvechiamata di sistema che necessita di un eseguibile da un file system.
Il kernel crea un file system basato sulla memoria durante il processo di avvio.

Dopo che un programma è stato avviato execve, è possibile annullare la mappatura dell'eseguibile da cui è stato avviato, anche se per farlo, senza arrestarsi immediatamente, è innanzitutto necessario creare un mapping di memoria eseguibile che non è supportato da un file, e deve inizializzarlo con un po 'di codice utile prima di saltare ad esso e decomprimere l'eseguibile.

Pertanto, un programma in modalità utente in esecuzione può esistere in uno stato in cui non ha mappature di memoria supportate da file e può chiudere tutti i descrittori di file supportati da file. Non può smettere di avere una directory radice e una directory di lavoro corrente, ma può astenersi da quelle.

Quindi anche se in questo stato è possibile implementare il codice del kernel per strappare il file system da sotto il programma e farlo funzionare, non sembra utile. E entrare in quello stato finale senza passare attraverso uno stato intermedio di utilizzo di un file system sarà ancora più lavoro senza alcun vantaggio utile.

Una configurazione utile per alcuni casi d'uso specializzati

Evitare l'uso di dispositivi a blocchi può essere utile. Durante l'avvio il kernel crea un file system di memoria e può anche popolare quel file system con i contenuti di un cpioarchivio prima di eseguirlo init. In questo modo è possibile eseguire un sistema interamente da un file system basato su memoria senza alcun dispositivo a blocchi per eseguirne il backup.

Ciò può essere utile per i sistemi in cui non si desidera conservare alcuno stato e come il sistema deve iniziare da una lavagna pulita al riavvio.

Naturalmente il kernel e l'archivio cpio devono in qualche modo esistere in memoria prima che al kernel venga dato il controllo. Come sono arrivati c'è un lavoro per il boot loader. Il boot loader avrebbe potuto caricarli da un dispositivo a blocchi anche se il sistema in esecuzione finale non utilizza i dispositivi a blocchi. Ma è anche possibile che il boot loader acquisisca il kernel e l'archivio cpio senza utilizzare un dispositivo a blocchi, ad esempio avviando in rete.

— kasperd
fonte

1

La domanda è se un kernel Linux in qualsiasi configurazione costruita (senza riscrivere nulla) possa "funzionare" senza alcun file system. Non deve fare nulla di utile o preservare uno stato. Da tutte le risposte, sto capendo che una sorta di file system è fornita e assunta all'interno del kernel stesso, almeno fino allo spegnimento. Anche '/' è un file system. Quindi, penso che per semplificare la risposta è "sì".

— Peter L.

2

@PeterL. Sì, se non si riscrive nulla, Linux richiederà un file system. Quando le persone parlano di usi pratici per Linux senza un file system, di solito si riferiscono a quelli supportati da un dispositivo a blocchi e puoi eseguire Linux senza un file system supportato da un dispositivo a blocchi. Avresti ancora una sorta di file system.

— Kasperd,

3

In Linux, quasi ogni dispositivo è un file , quindi è necessario disporre di un file system per eseguirlo.

— K7AAY
fonte

8

Ma ovviamente i driver di dispositivo esistono all'interno del kernel indipendentemente dal fatto che un file di dispositivo li punti o meno.

— Philip Couling il

6

Non tutti i dispositivi sono file. Interfacce di rete ( eth0, wlan0ecc) non sono, per esempio.

— Ruslan,

1

Questo è un malinteso comune. Mentre in teoria, tutto è un file nei sistemi UNIX e simili a UNIX, è completamente vero solo per sistemi altamente specializzati come Plan 9 (anche se è molto più vero che per Windows). Per Linux, alcune cose non sono file. Questo sta diventando sempre più vero poiché molti driver hanno iniziato a utilizzare netlink anziché ioctls sui dispositivi a caratteri (che sono file).

— foresta il

@forest Plan 9 non è un sistema "altamente specializzato" - doveva essere un sistema generico come Unix o Windows (perché non è riuscito a sostituire Unix ed è rimasto un sistema di ricerca è una storia completamente diversa). Ad ogni modo, proprio come Linux, plan9 sta esponendo interfacce virtualizzate al suo hardware (e non ha alcun ioctls - non vedo come l'utilizzo del fattore netlink vs ioctls in tutto questo), anche se cerca di essere più coerente (ad es. le interfacce di rete sono accessibili tramite il filesystem). Con l'introduzione degli spazi dei nomi, Linux è già più simile a plan9 che a unix classico.

— Zio Billy,

1

Molto bello argomento: o c'è devfs, che è un filesystem per definizione, o non c'è devfs, nel qual caso è necessario un filesystem per ospitare i nodi del dispositivo ...

— pmf

-1

Un kernel È un programma, proprio come un altro. Di default il kernel Linux tenta di accedere al file system, tuttavia questo comportamento può essere banalmente eliminato dalla modifica del kernel (in realtà solo un'aggiunta della funzione "arch_call_rest_init ()"). Al fine di eseguire "lavori utili", ci aspettiamo che lo sviluppatore possa includere thread del kernel (kthreads), elaborati in un driver personalizzato, per eseguire l'inizializzazione desiderata e il carico di lavoro del tipo di applicazione. Il kernel di Linux contiene già molti kthread, ma principalmente per eseguire lavori ausiliari al kernel o ai driver. Le API disponibili nel contesto del kernel sono abbastanza diverse da quelle disponibili nello spazio utente di Linux. Una grande parte della funzionalità di chiamata di sistema diventerebbe inutile in uno scenario senza filesystem.

Sì, Linux prevede l'accesso ai file system per impostazione predefinita. No, si potrebbe certamente creare un kernel modificato per eseguire lavori utili senza alcun file system. L'uso pratico di Linux senza filesystem è IMO abbastanza limitato, ma non nullo. FWIW, in passato molti kernel in tempo reale erano integrati nello stesso spazio dei nomi e binario delle applicazioni RT.

— stevea
fonte