Perché non ci sono README nella gerarchia del filesystem Linux?

La gerarchia del filesystem di Linux ( FHS ) contiene molte directory importanti. Ad esempio, l'ho appena scoperto /sys/class/inputgiocando con le impostazioni della mia tastiera PS / 2.

Ma tutte quelle importanti directory sono documentate altrove, quindi man /sys/class/inputnon funziona per spiegare cosa succede a un certo punto.

Perché non inserire i READMEfile nella gerarchia per rendere più facile per le persone imparare cosa sta succedendo a determinati livelli e giocare con i contenuti? Sarebbe davvero fantastico se i dispositivi potessero persino montare i propri README.

documentation fhs

— Anatoly Techtonik
fonte

Forse perché la maggior parte delle persone non vuole imparare cosa sta succedendo a quei diversi livelli? Vogliono solo che lavorino, in modo da poter svolgere qualsiasi attività di cui hanno bisogno / vogliano fare. Qualcuno dovrebbe scrivere tutti quei file README e aggiungerebbe più gonfiore a un file system già sovraccarico di cose (come gran parte di / usr / share) che la maggior parte delle persone non utilizzerà mai.

— jamesqf,

@jamesqf perché la maggior parte delle persone non vuole imparare cosa sta succedendo a quei diversi livelli? Vogliono solo che funzionino, in modo da poter svolgere qualsiasi attività di cui hanno bisogno / vogliano fare E se la mia attività fosse correlata al file system, come sembra che l'OP sia? Inoltre, hai incontrato un utente Linux? Noi facciamo vogliamo imparare. Questa è una discussione terribile.

— Kaqqao,

La differenza fondamentale tra Linux e Windows / Mac, nel caso non l'avessi notato, è che Linux sa che hai lasciato l'utero già sapendo tutto. Quindi un file README sarebbe ridondante.

— user541686

@kaqqao: Beh, sono un utente Linux, e sono stato uno praticamente da quando c'era un Linux. E prima ancora un utente di Unix da quando era in esecuzione sul PDP-11 della mia scuola. Non mi interessa particolarmente come funzionano le cose come il file system, voglio solo (al momento) far funzionare il mio codice di tomografia sismica. Né mi interessa / sys / class / input, purché la mia tastiera e trackball funzionino. Per la piccola minoranza che è interessata a queste cose, esiste uno strumento utile chiamato Google, accessibile dalla maggior parte dei browser Web :-)

— jamesqf

C'è man hier.

— el.pescado

Risposte:

Per usare il tuo esempio: /sys/non contiene file "reali", ma è interamente fornito dal kernel. Vuoi che tutti i README diventino parte del kernel? Probabilmente no.

La documentazione è in /usr/share/doc. Che contiene file normali sul tuo disco rigido. Parte della documentazione su /sysed /procè nel sorgente del kernel, ovvero /usr/src/linux/Documentation(se hai installato il sorgente del kernel e hai creato il link simbolico per il tuo kernel corrente).

— dirkt
fonte

sysfs e procfs sono filesystem completamente virtuali che non hanno un archivio di backup. Tutto dentro è sintetizzato al volo dal kernel. Se i README non vengono archiviati in memoria, da dove altro potrebbero provenire?

— Jörg W Mittag,

@ JörgWMittag: Ovviamente il kernel potrebbe sintetizzare i collegamenti simbolici /use/share/doc.

— MSalter

Il kernel è già un software ampio e complicato e "facilitare l'apprendimento delle persone" non è tra gli obiettivi principali dei loro sviluppatori. Non è poi così difficile andare /usr/share/doc.

— Federico Poloni,

@MSalters: ciò significherebbe che il kernel deve o a) scansionare l'intero filesystem per trovare quei file e creare collegamenti simbolici, b) deve avere un carico di opzioni di configurazione per dire al kernel dove si trovano quei file in modo che possa creare collegamenti simbolici o c) deve prescrivere le posizioni di tali file ai manutentori della distribuzione (il che violerebbe la massima n. 1 di Linus secondo cui la politica appartiene allo spazio utente, solo il meccanismo appartiene al kernel). Inoltre, come ti assicuri che i file corrispondano alla versione del kernel attualmente in esecuzione? Che dire delle distribuzioni che hanno il loro ...

— Jörg W Mittag

@FedericoPoloni: l'FHS è obbligatorio solo per le distribuzioni Linux conformi all'LSB. La maggior parte no. In particolare, ci sono un certo numero di distribuzioni che sono state fondate specificamente per ripulire (ciò che percepiscono come) cruft storico, che in molti casi include esplicitamente l'FHS.

— Jörg W Mittag

Perché Unix e Linux hanno una tradizione decennale di documentazione con manpagine (e, su sistemi GNU, infofile ...). Vedi man (1) , man (7) , man-pages (7) . A proposito, mancomando e pagine sono opzionali (e non li installerai su tutti i sistemi Unix).

La gerarchia del file system è descritta in hier (7) .

È definito dal Filesystem Hierachy Standard disponibile su https://wiki.linuxfoundation.org/lsb/fhs

Diversi filesystem, in particolare /proc/(vedi proc (5) ) e /sys/(vedi sysfs (5) ) sono sistemi pseudofili forniti dal codice del kernel. Non vuoi gonfiare il kernel con un codice aggiuntivo che produce tali README-s (che è inutile per la stragrande maggioranza degli utenti). Anche il file di configurazione del kernel è disponibile solo facoltativamente in quanto /proc/config.gzè spesso disabilitato nella maggior parte delle configurazioni del kernel. E molti sistemi Linux sono sistemi integrati (ad es. Il tuo smartphone, il tuo dispositivo intelligente o dispositivo IoT, il tuo RaspberryPI) in cui le risorse sono abbastanza spaventose per evitare di essere sprecate.

In particolare /sys/è utile soprattutto per amministratori di sistema e sviluppatori che scrivono programmi di utilità di basso livello ed entrambi dovrebbero essere in grado di trovare la documentazione in modo appropriato.

Perché non posizionare i READMEfile nella gerarchia per rendere più semplice per le persone sapere cosa sta succedendo

Se vuoi davvero questi messaggi README, scrivi il tuo modulo kernel caricabile fornendo loro, o imposta alcuni unionfs per fornirli. Non penso che valga la pena (e un sindacato su /sysprobabilmente rallenterebbe l'intero sistema).

Ricorda che il codice del kernel consuma RAM (non viene mai eseguito il paging e si trova nella memoria fisica , non nella memoria virtuale), anche se non utilizzato. Quindi ha senso evitare di gonfiarlo.

— Basile Starynkevitch
fonte

Quindi posso scrivere un pacchetto che documenta tutti quei percorsi senza toccare il kernel o renderlo gonfio?

— Anatoly Techtonik,

Potresti, ma usare un unionfs su /sysrallenterebbe il tuo sistema. Non penso che valga la pena perdere il tempo in questo modo. La vita è breve ... E passerai più tempo a farlo che a leggere la documentazione

— Basile Starynkevitch