Organisation des en-têtes du noyau Linux

Pendant que je faisais une lecture sur les appels système, j'ai fait une recherche sur "syscalls.h" pour trouver le fichier d'en-tête dans LXR. Les résultats de la recherche m'ont laissé perplexe. Il existe une douzaine de fichiers "syscalls.h" provenant de répertoires sous "arch / _arch_name_ / include / asm". Ce sont ok, ce sont des définitions spécifiques à l'architecture ou quelque chose d'autre nécessaire. La question est de savoir pourquoi avons-nous deux en-têtes "syscalls.h" différents sous / include / linux et / include / asm-generic?

Aussi, je veux savoir à quoi servent les en-têtes / include / linux et à quoi servent les en-têtes / include / asm-generic. Comment se différencient-ils? Quelle est la logique derrière deux dossiers d'en-tête distincts? Comment se rapportent-ils les uns aux autres?

Merci

Le logiciel doit être portable. Si vous compilez vos sources C / C ++, vous n'avez pas besoin de savoir si vous exécutez i386 / x86_64 / arm / mips ou quoi que ce soit. Les en-têtes sont liés de telle manière que le logiciel se compile.

Tous les autres fichiers d'en-tête existent car ils ont été mis en œuvre de nombreuses normes différentes, il existe des ports de BSD et ainsi de suite. Beaucoup d'entre eux sont historiquement basés. D'où vient chacun et pourquoi ils sont là a de nombreuses raisons différentes et fera sûrement exploser les réponses.

Et une réponse pour asm-generic: stackoverflow

Les en-têtes ci-dessous asm/genericsont principalement conçus comme des mesures d'interruption, des versions portables en C jusqu'à ce qu'une version spécifique à l'architecture soit écrite. Vous constaterez également que dans certains cas, il /usr/include/foobar.hy a une multitude d'en-têtes «d'implémentation interne», et que vous retombez finalement sur une partie qui vient du noyau, souvent appelée la même. Les exemples sont math.het (plus dépendants de Linux) syscall.h.

arch/x86/entry/ a deux fichiers syscall spéciaux:

syscalls/syscall_32.tbl et dito "64"

Les appels système sont spéciaux car le noyau doit réunir ABI et API.

En général, les répertoires d'inclusion et les autres fichiers d'en-tête (ceux indépendants comme kernel / sched / sched.h) suivent une logique hiérarchique. Je pense que make et gcc jouent un rôle.

Ces symboles sont systématiquement utilisés pour s'assurer que chaque "unité" d'en-tête n'est lue qu'une seule fois. ("enveloppes de protection" car il peut y avoir trop de quadrillage). Ici de include/linux/mm.h:

    #ifndef _LINUX_MM_H
    #define _LINUX_MM_H

    #include <linux/errno.h>

    #ifdef __KERNEL__

    ...  (#includes)
    ...  (ext. decl. etc., the whole mm.h)

    #endif /* __KERNEL__ */
    #endif /* _LINUX_MM_H */

Les fichiers tbl ont:

# 32-bit system call numbers and entry vectors

La liste commence par:

0    i386    restart_syscall    sys_restart_syscall       __ia32_sys_restart_syscall
1    i386    exit               sys_exit                  __ia32_sys_exit
2    i386    fork               sys_fork                  __ia32_sys_fork
3    i386    read               sys_read                  __ia32_sys_read




#
# 64-bit system call numbers and entry vectors
#
# The format is:
# <number> <abi> <name> <entry point>
#
# The __x64_sys_*() stubs are created on-the-fly for sys_*() system calls
#
# The abi is "common", "64" or "x32" for this file.

Je ferai la mise en page plus tard ...