introduction

Cet article est le 8ème jour du Calendrier de l'Avent Linux 2019 - Qiita.

Dans cet article, je vais vous montrer comment vérifier quel type de noyau est le noyau Linux que vous utilisez et sur quels paramètres il fonctionne. Le noyau Linux est utilisé à diverses fins. Par conséquent, même si vous dites Linux Kernel en un mot, le fonctionnement est complètement différent selon le système. Nous espérons que savoir comprendre la situation actuelle vous aidera à lire efficacement le code du noyau et à trouver de meilleurs paramètres.

De plus, les commentaires sont les bienvenus, alors n'hésitez pas à nous contacter si vous avez des questions.

--Que écrire dans cet article --Comment vérifier l'identité du noyau Linux

Comment vérifier les paramètres du noyau Linux

--Ce qu'il ne faut pas écrire dans cet article

Paramètres pour chaque processus, chaque utilisateur, etc. (ʻulimit, nice, quotal`, etc.)
Paramètres de l'espace utilisateur (tels que sysconf et pathconf) --Paramètres du pilote (paramètres au moment de insmod, etc.) --Explication de chaque élément de réglage

Les 6 éléments suivants sont présentés. Chaque élément est indépendant, veuillez donc voir d'où vous êtes intéressé.

Kernel Version
CPU Architecture
Kernel Build Config
Command-line Parameters
sysctl
Device Tree

Kernel Version

Voyons d'abord quelle version du noyau est utilisée. En connaissant la version, vous pouvez l'utiliser comme base pour rechercher si une fonction ou une modification spécifique est incluse.

Comment vérifier la version du noyau ʻuname -r`

Vous pouvez obtenir la version du noyau en cours d'exécution en exécutant la commande ʻuname -r`. Vous trouverez ci-dessous les résultats lors de l'utilisation d'un noyau Linux 5.3.10.

$ uname -r
5.3.10

Selon l'environnement, si vous exécutez ʻu nom -r`, il peut être bloqué après les trois nombres ci-dessus. Par exemple, voici le résultat de l'exécution sur Ubuntu 19.10.

$ uname  -r
5.3.0-19-generic

Dans ce cas, il s'agit d'un noyau modifié pour Ubuntu 19.10 basé sur la version du noyau Linux 5.3.0. Les corrections apportées devraient être publiées quelque part. Pour Ubuntu, paquet de code source et diff /primary/+sourcefiles/linux/5.3.0-19.20/linux_5.3.0-19.20.diff.gz) est distribué.

La signification de la chaîne de caractères («19-generic») après la version est différente pour chaque distribution. Pour Ubuntu, cela est expliqué dans ici.

Il existe de nombreuses autres façons de vérifier la version, et il y a un article détaillé dans ici, alors jetez un œil. De plus, le contenu de la commande ʻuname` est expliqué en détail dans Day 1 of Linux Advent Calendar 2019. Jetez-y également un œil.

Page de référence sur la version du noyau

CPU Architecture

Ensuite, vérifions pour quel CPU le noyau a été construit.

Dans le contexte du noyau Linux, «à quel processeur est destiné» est souvent exprimé comme architecture ou arch. L'architecture est utilisée de plusieurs manières, mais ici c'est l'ISA (architecture de jeu d'instructions) du CPU. Par exemple, «x86_64» et «arm».

Il peut y avoir peu de cas où vous ne connaissez pas l'architecture du processeur lorsque vous connaissez le noyau. Cependant, il y a des moments où un noyau surprenant pour l'architecture fonctionne. Vérifions-le juste au cas où.

Comment vérifier l'architecture du processeur ʻuname -m `ou ʻarch`

Les commandes de vérification de l'architecture du processeur incluent ʻuname -m et ʻarch. Les deux commandes sont fournies dans un package appelé coreutils, et l'implémentation est commune, vous pouvez donc utiliser celle que vous voulez.

Dans le cas d'un PC (Ubuntu 18.04), il sera affiché sous la forme x86_64.

$ uname -m
x86_64

Quand je l'essaye avec Raspberry Pi 3 Model B + (Raspbian), il dit «armv7l».

$ uname -m
armv7l

En fait, le Raspberry Pi 3 Model B + est équipé d'un processeur ARM 64 bits appelé Cortex-A53. Si tel est le cas, je pense que le noyau pour 64 bits fonctionne, mais dans ce cas, il devrait être affiché sous la forme ʻaarch64`. En d'autres termes, dans Raspbian, le noyau construit pour 32 bits fonctionne en mode compatible 32 bits. (Je suppose, probablement parce qu'il est partagé avec des modèles de CPU 32 bits tels que RasPi2 et RasPi zero)

Répertoire ʻarch` du noyau

Maintenant que j'ai confirmé l'architecture du processeur, le traitement de l'architecture du processeur que j'utilise est Voyons où il se trouve sur le code source du noyau.

En regardant le code source du noyau, sous le répertoire ʻarch / ` Vous pouvez voir qu'il existe un répertoire pour chaque architecture de processeur.

$ ls -F arch/
Kconfig  arm/	 csky/	   ia64/	mips/	openrisc/  riscv/  sparc/      x86/
alpha/	 arm64/  h8300/    m68k/	nds32/	parisc/    s390/   um/	       xtensa/
arc/	 c6x/	 hexagon/  microblaze/	nios2/	powerpc/   sh/	   unicore32/

Le nom du répertoire est un léger remplacement du résultat de la commande ʻuname -mintroduite plus tôt. Le remplacement se fait dans un Makefile appeléscripts / subarch.include. Par exemple, lors de la construction d'un noyau pour x86_64, le répertoire x86 / est utilisé. De même, pour ʻarmv7l de Raspbian, le répertoire ʻarm / `est utilisé.

`scripts/subarch.include`


SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
				  -e s/sun4u/sparc64/ \
				  -e s/arm.*/arm/ -e s/sa110/arm/ \
				  -e s/s390x/s390/ -e s/parisc64/parisc/ \
				  -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
				  -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
				  -e s/riscv.*/riscv/)

Page de référence de l'architecture du processeur

Kernel Build Config

Vient ensuite Kernel Build Config. Selon la personne, il peut être plus approprié de dire un commutateur de compilation ou «# ifdef». Lorsque nous disons simplement Kernel Config, nous y faisons souvent référence.

Comme mentionné précédemment, le noyau Linux est utilisé à des fins très diverses, mais si vous créez un noyau universel qui peut tout faire, la taille de l'image deviendra inutilement grande. Par conséquent, nous économisons de la taille en excluant les fonctionnalités inutilisées de la compilation.

Puisque la fonction de débogage est souvent activée / désactivée avec la configuration de compilation du noyau, vous pouvez également savoir quel type de fonction de débogage peut être utilisé.

Comment vérifier Kernel Build Config 1. `/ boot / config-X.Y.Z`

Selon la distribution Linux, il est laissé sous / boot avec l'image du noyau. Par exemple, dans Ubuntu 19.10, il est stocké dans un fichier appelé / boot / config-5.3.0-19-generic. Il existe des fichiers équivalents dans CentOS 8 et Debian 10.

$ head /boot/config-$(uname -r)
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 5.3.0-19-generic Kernel Configuration
#

#
# Compiler: gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=90201

Comment vérifier Kernel Build Config 2. `/ proc / config.gz`

Pour les noyaux avec CONFIG_IKCONFIG_PROC activé Vous pouvez vérifier la configuration de construction du noyau dans / proc / config.gz.

Malheureusement, il n'y a pas beaucoup d'environnement utilisable. Cependant, c'est une méthode de confirmation plus fiable car le noyau en cours d'exécution vous le dira. Utilisons-le positivement dans un environnement où il peut être utilisé.

Par exemple, le noyau Linux utilisé sur Android fonctionne souvent avec cette méthode. Ce qui suit est le résultat une fois confirmé avec l'émulateur d'Android 10. (Notez que vous utilisez la commande zcat car elle est gzippée) Le / proc / config.gz était également activé sur Samsung Galaxy Note8 (Android 9).

$ zcat /proc/config.gz | head
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.14.112 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"

Quels sont les éléments de Kernel Build Config?

Il est défini dans un fichier appelé Kconfig inclus dans le code source du noyau. Les dépendances et explications de chaque élément y sont également décrites.

De plus, si vous exécutez make xconfig, vous pouvez voir la liste tout en regardant l'explication de chaque élément de réglage, c'est donc recommandé.

Vous pouvez également rechercher avec Ctrl-f.

Voici quelques-uns des éléments les plus fréquemment utilisés.

CONFIG_IKCONFIG_PROC Vous permet d'obtenir la configuration de construction du noyau via / proc / config.gz. Il est facile de comprendre si vous activez d'abord Kernel Build Config lorsque vous jouez avec.
CONFIG_DEBUG_INFO Il va maintenant générer une image du noyau avec des symboles de débogage. Requis lors du débogage du noyau à l'aide de gdb.
CONFIG_FTRACE Active une fonction appelée Ftrace pour analyser le comportement du noyau. Présentation de Ftrace à Linux - Qiita explique en détail.
CONFIG_KPROBE Activez Kprobe, un mécanisme pour appliquer des correctifs binaires à un noyau en cours d'exécution. Vous en avez également besoin pour utiliser SystemTap, un outil qui rend Kprobe un peu plus facile à utiliser.

Comment changer la configuration de compilation du noyau

Pour changer la configuration de construction du noyau, vous devez reconstruire le noyau.

La méthode de changement générale est de reconstruire le noyau en éditant avec make menu config ou make xconfig basé sur le .config actuel obtenu par la méthode ci-dessus.

Cependant, .config est un fichier généré par la construction et doit être exclu du contrôle du code source. Une fois que vous avez créé le .config souhaité avec make menuconfig, assurez-vous de valider la sortie de defconfig avec make saved efconfig. make savedefconfig affichera la configuration minimale pour régénérer le .config actuel.

Par exemple, si vous confiez defconfig à ʻarch / x86 / configs / mytest_defconfig, vous pouvez utiliser make mytest_defconfig à partir de maintenant afin que tous les membres du développement puissent générer le .config` édité. Je peux le faire.


$ make savedefconfig
$ mv defconfig arch/x86/configs/mytest_defconfig
$ mv .config .config.back
$ make mytest_defconfig
#
# configuration written to .config
#
$ diff .config .config.back

Page de référence de Kernel Build Config

Command-line Parameters

Ensuite, je présenterai les paramètres de ligne de commande. Les paramètres de ligne de commande sont des options spécifiées comme arguments lors du démarrage de Kernel. Par conséquent, il est généralement spécifié par le chargeur de démarrage.

La version du noyau, l'architecture du processeur et la configuration de construction du noyau introduites jusqu'à présent ont toutes été décidées au moment de la compilation du noyau. D'autre part, ce que nous allons introduire à partir de là est un mécanisme pour changer l'opération sans changer le noyau lui-même.

Comment vérifier les paramètres de ligne de commande 1. `/ proc / cmdline`

Vous pouvez vérifier les paramètres de ligne de commande dans / proc / cmdline.

$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.3.7+ root=UUID=71b4dc0a-e498-41f4-9cd2-a81e8c03cda8 ro quiet splash vt.handoff=1

Comment vérifier les paramètres de la ligne de commande 2. `dmesg`

Puisqu'il est également sorti vers dmesg, vous pouvez le vérifier même s'il ne reste que le journal.

$ dmesg | grep "Kernel command line"
[    0.104775] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.3.7+ root=UUID=71b4dc0a-e498-41f4-9cd2-a81e8c03cda8 ro quiet splash vt.handoff=1

Quels types d'éléments y a-t-il dans les paramètres de ligne de commande?

Il existe une Documentation pour les éléments de configuration des paramètres de ligne de commande.

Bien que ce soit une très petite partie, je vais en présenter quelques-unes pour référence. Il y en a beaucoup d'autres, alors assurez-vous de lire également la documentation.

loglevel Vous pouvez modifier le niveau de sortie du journal du noyau vers la console. Il est souvent modifié lors de l'analyse des défauts immédiatement après le démarrage.
log_buf_len Vous pouvez modifier la taille du tampon en anneau du journal du noyau. Lorsque le journal coule, vous pouvez voir le journal en augmentant la taille. La valeur par défaut peut être modifiée avec CONFIG_LOG_CPU_MAX_BUF_SHIFT, mais si vous voulez l'augmenter temporairement, utilisez ceci.
mem Vous pouvez spécifier la taille de la mémoire utilisée par le noyau. Il est utilisé lors de la simulation d'une situation où la mémoire est faible ou lorsque la carte mémoire est suspecte.
ftrace Activez la fonction appelée Ftrace pour analyser le fonctionnement du noyau immédiatement après le démarrage. Il est utilisé pour analyser le comportement du noyau immédiatement après le démarrage.

Page de référence des paramètres de ligne de commande

The kernel's command-line parameters - The Linux Kernel documentation

sysctl

Le sysctl suivant est un mécanisme pour changer le paramètre du noyau pendant l'exécution. Vous pouvez le modifier à tout moment, pas seulement au démarrage comme les paramètres de ligne de commande.

Comment vérifier sysctl 1. `sysctl`

Vous pouvez vérifier les valeurs actuelles de tous les paramètres en exécutant sysctl -a. Vous avez besoin des privilèges root pour voir certains paramètres.

$ sudo sysctl -a | head
abi.vsyscall32 = 1
debug.exception-trace = 1
debug.kprobes-optimization = 1
dev.cdrom.autoclose = 1
dev.cdrom.autoeject = 0
dev.cdrom.check_media = 0
dev.cdrom.debug = 0
dev.cdrom.info = CD-ROM information, Id: cdrom.c 3.20 2003/12/17
dev.cdrom.info = 
dev.cdrom.info = drive name:

Comment vérifier sysctl 2. `/ proc / sys /`

Tous les paramètres qui peuvent être définis avec sysctl sont publiés sous forme de fichiers sous / proc / sys. Vous pouvez vérifier la valeur du paramètre en lisant ce fichier, et vous pouvez le modifier en l'écrivant. En fait, la commande sysctl est également vérifiée en interne et modifiée via / proc / sys.

$ find /proc/sys -type f | head | xargs -I@ sh -c 'echo "@ = $(cat @ | head -1)"'
/proc/sys/abi/vsyscall32 = 1
/proc/sys/debug/exception-trace = 1
/proc/sys/debug/kprobes-optimization = 1
/proc/sys/dev/cdrom/autoclose = 1
/proc/sys/dev/cdrom/autoeject = 0
/proc/sys/dev/cdrom/check_media = 0
/proc/sys/dev/cdrom/debug = 0
/proc/sys/dev/cdrom/info = CD-ROM information, Id: cdrom.c 3.20 2003/12/17
/proc/sys/dev/cdrom/lock = 1
/proc/sys/dev/hpet/max-user-freq = 64

Si vous voulez savoir à l'avance s'il s'agit d'un paramètre modifiable ou si vous avez besoin de privilèges root, Vous pouvez le vérifier en regardant les permissions des fichiers sous / proc / sys.

En regardant ce qui suit, fs.file-max est accessible en écriture, Vous pouvez voir que fs.file-nr n'est pas accessible en écriture. Vous pouvez également voir que vous avez besoin des privilèges root pour modifier fs.file-max.

$ ls -l /proc/sys/fs/file-*
-rw-r--r--1 racine racine 0 6 décembre 14:01 /proc/sys/fs/file-max
-r--r--r--1 racine racine 0 6 décembre 14:01 /proc/sys/fs/file-nr

Quel type d'éléments possède sysctl?

Il existe également de la Documentation pour les éléments qui peuvent être définis avec sysctl.

Il s'agit également d'une toute petite partie, mais je vais vous présenter le type d'éléments à titre de référence.

fs.file-max Vous pouvez vérifier et modifier le nombre de fichiers pouvant être ouverts sur l'ensemble du système.
fs.file-nr Vous pouvez voir combien de fichiers sont actuellement ouverts et combien de fichiers peuvent être ouverts à l'échelle du système. Comme mentionné précédemment, il est en lecture seule. Par exemple, s'il s'agissait de "15840 0 3231322", Le nombre de fichiers actuellement ouverts est de "15840", et le nombre de fichiers qui peuvent être ouverts à l'échelle du système est de "3231322". Le «0» au milieu est toujours 0, il ne reste que pour la compatibilité, alors ne vous inquiétez pas. Il est utilisé pour vérifier si une fuite de fd s'est produite en tant que système.
fs.nr_open Le nombre de fichiers pouvant être ouverts par processus. Cependant, en réalité, il est souvent plus strict avec l'ensemble ʻulimit pour chaque processus. Vous pouvez vérifier les limites par ʻulimit dans / proc / $ {PID} / limites.
kernel.print-fatal-signals Une valeur de 1 laisse le nom du processus et la valeur de registre dans le journal du noyau lorsque le processus se termine anormalement.
kernel.core_pattern Vous pouvez définir comment conserver Coredump lorsqu'un processus se termine anormalement. En plus de renommer les fichiers Coredump, vous pouvez également rediriger vers des programmes spécifiques. Linux Effective Coredump --Qiita explique en détail.
vm.drop_caches Libère le cache du noyau lorsque vous écrivez une valeur. Le seul changement dans cet élément est que la valeur lue n'a pas de sens et que le processus s'exécute lorsqu'il est écrit. Suivre le mouvement lors de l'écriture sur drop_caches de Linux --Qiita explique en détail. L'autorisation de fichier pour cet élément est en lecture-écriture, mais elle devrait vraiment être en écriture seule.

Combien de temps la valeur définie dans sysctl est-elle valide?

Fondamentalement, les paramètres définis par sysctl ne sont enregistrés que dans la variable globale du noyau, vous les oublierez donc lorsque vous redémarrerez le système.

Le mécanisme pour le définir dépend en permanence de la distribution, mais de nombreuses distributions chargent / etc / sysctl.conf comme valeur par défaut au démarrage. Ceci est réalisé en exécutant sysctl --system à partir du script init au démarrage du système.

Pour Android, écrivez dans / proc / sys directement à partir du script initrc qui décrit le processus de démarrage.

`/init.rc`


on early-init
    # Disable sysrq from keyboard
    write /proc/sys/kernel/sysrq 0

Page de référence de `sysctl`

Device Tree

Enfin, vérifions l'arborescence des périphériques.

L'arborescence des périphériques contient des informations de configuration matérielle. Il est souvent utilisé dans les systèmes embarqués qui utilisent des processeurs ARM.

Dans les systèmes embarqués, les adresses de mémoire des périphériques, les numéros d'interruption, etc. diffèrent d'un système à l'autre. Leur intégration dans le code source du pilote de périphérique les rend difficiles à lire et à maintenir. Par conséquent, il est courant d'écrire ces informations de configuration matérielle dans une source d'arborescence de périphériques (fichier .dts) indépendante du code source.

Si vous regardez le classement du nombre de fichiers .dts par arch dans 5.3.10, arm est de loin le meilleur. Vient ensuite powerpc. Il semble que Device Tree ait été développé à l'origine pour powerpc, c'est probablement pourquoi.

$ find arch/ -name *.dts | cut -d '/' -f 2 | uniq -c | sort -n -r
   1176 arm
    265 arm64
    200 powerpc
     50 mips
     17 arc
      7 xtensa
      5 c6x
      3 h8300
      2 openrisc
      2 nios2
      1 x86
      1 sh
      1 riscv
      1 nds32
      1 microblaze

Ensuite, que se passe-t-il dans le monde des PC? Il semble que le BIOS UEFI reçoive des informations matérielles selon la norme ACPI, mais je ne suis pas sûr. Pardon.

Comment vérifier l'arborescence des périphériques `/ sys / firmware / fdt`

Pour les systèmes qui utilisent l'arborescence des périphériques Il existe une arborescence de périphériques convertie au format FDT dans / sys / firmware / fdt. FDT est une abréviation de Flattend Device Tree et est également appelé DTB (Device Tree Blob). Vous pouvez convertir le FDT en un fichier .dts avec la commande dtc (Device Tree Compiler).

Pour les systèmes embarqués, il est également possible de transférer / sys / firmware / fdt sur un PC puis de le convertir en .dts sur le PC. Sous / proc / device-tree, il y a aussi une arborescence de périphériques étendue au système de fichiers, mais je pense que / sys / firmware / fdt est plus pratique car il est plus facile à gérer.

Ce qui suit est le résultat de la confirmation de Device Tree sur Raspberry Pi 3 ModelB + (Raspbian).

$ sudo dtc /sys/firmware/fdt 2> /dev/null | head
/dts-v1/;

/memreserve/	0x0000000000000000 0x0000000000001000;
/ {
	memreserve = < 0x3b400000 0x4c00000 >;
	serial-number = "00000000c97f6276";
	compatible = "raspberrypi,3-model-b\0brcm,bcm2837";
	model = "Raspberry Pi 3 Model B Rev 1.2";
	interrupt-parent = < 0x01 >;
	#address-cells = < 0x01 >;

Quels types d'éléments se trouvent dans l'arborescence des appareils?

Les spécifications de l'arborescence des appareils sont publiées ici [https://www.devicetree.org/specifications/).

Cependant, la signification des paramètres réels écrits dans l'arborescence des périphériques dépend en grande partie des spécifications matérielles cibles et des spécifications des pilotes de périphériques. Il existe de nombreux cas où il est utilisé de manière inattendue, donc lorsque vous regardez l'arborescence des périphériques, vérifiez l'implémentation qui utilise cette valeur autant que possible.

Page de référence de l'arborescence des périphériques

en conclusion

Merci d'avoir lu jusqu'au bout.

Les paramètres peuvent modifier directement le comportement du noyau, donc je pense que c'est un très bon point de départ pour la lecture du code du noyau. Dès que vous grepez le nom de l'élément de réglage, vous pouvez trouver l'implémentation associée, et surtout, il est facile de changer la valeur de réglage et de voir l'opération.

Je serais très heureux si cet article était utile à quiconque.

Quel type de noyau est ce noyau?