Pourquoi n'y a-t-il pas de fichiers README dans la hiérarchie du système de fichiers Linux?

La hiérarchie du système de fichiers Linux ( FHS ) contient de nombreux répertoires importants. Par exemple, je viens de découvrir /sys/class/inputen jouant avec mes paramètres de clavier PS / 2.

Mais tous ces répertoires importants sont documentés ailleurs, donc man /sys/class/inputne fonctionne pas pour expliquer ce qui se passe à un certain point.

Pourquoi ne pas placer des READMEfichiers dans la hiérarchie pour permettre aux gens d'apprendre plus facilement ce qui se passe à certains niveaux et de jouer avec le contenu? Ce serait vraiment génial si les appareils pouvaient même monter leur propre READMEs.

documentation fhs

— anatoly techtonik
source

Peut-être parce que la plupart des gens ne veulent pas savoir ce qui se passe à ces différents niveaux? Ils veulent juste qu'ils travaillent, afin qu'ils puissent accomplir toutes les tâches dont ils ont besoin / veulent faire. Quelqu'un devrait écrire tous ces fichiers LISEZMOI, et ils ajouteraient plus de ballonnement à un système de fichiers déjà surchargé (comme une grande partie de / usr / share) que la plupart des gens n'utiliseront jamais.

— jamesqf

@jamesqf parce que la plupart des gens ne veulent pas savoir ce qui se passe à ces différents niveaux? Ils veulent juste qu'ils fonctionnent, afin qu'ils puissent accomplir toutes les tâches dont ils ont besoin / veulent faire Et si ma tâche est liée au système de fichiers, comme l'OP semble l'être? Avez-vous également rencontré un utilisateur Linux? Nous ne voulons apprendre. C'est un argument terrible.

— kaqqao

La différence fondamentale entre Linux et Windows / Mac, au cas où vous ne l'auriez pas remarqué, est que Linux sait que vous avez quitté l'utérus en sachant déjà tout. Un README serait donc redondant.

— user541686

@kaqqao: Eh bien, JE SUIS un utilisateur Linux, et j'en ai été un assez depuis qu'il y avait un Linux. Et avant cela, un utilisateur d'Unix car il fonctionnait sur le PDP-11 de mon école. Peu m'importe comment des choses comme le système de fichiers fonctionnent, je veux juste (pour le moment) faire fonctionner mon code de tomographie sismique. Je ne me soucie pas non plus de / sys / class / input, tant que mon clavier et mon trackball fonctionnent. Pour la petite minorité qui s'intéresse à ces choses, il existe un outil pratique appelé Google, accessible à partir de la plupart des navigateurs Web :-)

— jamesqf

Voilà man hier.

— el.pescado

Réponses:

Pour utiliser votre exemple: /sys/ne contient pas de "vrais" fichiers, mais est entièrement fourni par le noyau. Voulez-vous que tous les fichiers README fassent partie du noyau? Vous ne le faites probablement pas.

La documentation est en /usr/share/doc. Qui contient des fichiers normaux sur votre disque dur. Une documentation sur /syset se /proctrouve dans la source du noyau, c'est-à-dire dans /usr/src/linux/Documentation(si vous avez installé la source du noyau et créé le lien symbolique pour votre noyau actuel).

— dirkt
source

sysfs et procfs sont des systèmes de fichiers entièrement virtuels qui n'ont pas de stockage de sauvegarde. Tout y est synthétisé à la volée par le noyau. Si les fichiers README ne sont pas stockés en mémoire, d'où proviendraient-ils?

— Jörg W Mittag

@ JörgWMittag: De toute évidence, le noyau pourrait synthétiser des liens symboliques vers /use/share/doc.

— MSalters

Le noyau est déjà un logiciel volumineux et compliqué, et "faciliter l'apprentissage des gens" ne fait pas partie des principaux objectifs de leurs développeurs. Ce n'est pas si difficile d'y aller à la /usr/share/docplace.

— Federico Poloni

@MSalters: cela signifierait que le noyau doit soit a) analyser l'ensemble du système de fichiers pour trouver ces fichiers et créer des liens symboliques vers ceux-ci, b) doit avoir une charge d'options de configuration pour dire au noyau où se trouvent ces fichiers afin qu'il puisse créer des liens symboliques vers eux, ou c) doit prescrire les emplacements de ces fichiers aux responsables de la distribution (ce qui violerait la maxime n ° 1 de Linus selon laquelle la politique appartient à l'espace utilisateur, seul le mécanisme appartient au noyau). De plus, comment vous assurez-vous que les fichiers correspondent à la version du noyau en cours d'exécution? Qu'en est-il des distributions qui ont leur…

— Jörg W Mittag

@FedericoPoloni: le FHS n'est obligatoire que pour les distributions Linux conformes au LSB. La plupart n'en ont pas. En particulier, il existe un certain nombre de distributions qui ont été spécifiquement fondées pour nettoyer (ce qu'elles perçoivent comme) des fosses historiques, qui dans de nombreux cas incluent explicitement le FHS.

— Jörg W Mittag

Parce qu'Unix et Linux ont une tradition vieille de plusieurs décennies de documentation avec des manpages (et, sur les systèmes GNU, des infofichiers ...). Voir man (1) , man (7) , man-pages (7) . BTW, la mancommande et les pages sont facultatifs (et vous ne les installerez pas sur tous les systèmes Unix).

La hiérarchie du système de fichiers est décrite dans hier (7) .

Il est défini par le Filesystem Hierachy Standard disponible sur https://wiki.linuxfoundation.org/lsb/fhs

Plusieurs systèmes de fichiers, notamment /proc/(voir proc (5) ) et /sys/(voir sysfs (5) ) sont des systèmes de pseudo-fichiers fournis par le code du noyau. Vous ne voulez pas gonfler le noyau avec du code supplémentaire produisant de tels README-s (ce qui est inutile pour la grande majorité des utilisateurs). Même le fichier de configuration du noyau n'est disponible qu'en option car il /proc/config.gzest souvent désactivé dans la plupart des configurations du noyau. Et de nombreux systèmes Linux sont des systèmes embarqués (par exemple votre smartphone, votre appareil intelligent ou appareil IoT, votre RaspberryPI) où les ressources sont suffisamment effrayantes pour éviter d'être gaspillées.

Il /sys/est particulièrement utile aux administrateurs système et aux développeurs qui écrivent des utilitaires de bas niveau, et les deux sont censés être en mesure de trouver la documentation de manière appropriée.

Pourquoi ne pas placer des READMEfichiers dans la hiérarchie pour permettre aux gens de savoir plus facilement ce qui se passe

Si vous voulez vraiment de tels READMEs, écrivez votre propre module noyau chargeable en les fournissant, ou configurez certains unionfs pour les fournir. Je ne pense pas que cela en vaille la peine (et un unionfs sur /sysralentirait probablement tout votre système).

N'oubliez pas que le code du noyau consomme de la RAM (il n'est jamais paginé et se trouve dans la mémoire physique , pas dans la mémoire virtuelle), même s'il n'est pas utilisé. Il est donc logique d'éviter les ballonnements.

— Basile Starynkevitch
source

Je peux donc écrire un paquet qui documente tous ces chemins sans toucher au noyau ou le faire gonfler?

— anatoly techtonik

Vous pourriez, mais utiliser un unionfs sur /sysralentirait votre système. Je ne pense pas que cela vaille la peine de perdre votre temps de cette façon. La vie est courte ... Et vous passerez plus de temps à faire cela qu'à lire la documentation

— Basile Starynkevitch