Organizzazione delle intestazioni del kernel Linux

Mentre stavo leggendo alcune chiamate di sistema, ho fatto una ricerca per "syscalls.h" per trovare il file header in LXR. I risultati della ricerca mi hanno lasciato perplesso. Esistono una dozzina di file "syscalls.h" provenienti da directory in "arch / _arch_name_ / include / asm". Questi sono ok, sono definizioni specifiche dell'architettura o qualcos'altro necessario. La domanda è: perché abbiamo due diverse intestazioni "syscalls.h" in entrambe / include / linux e / include / asm-generic?

Inoltre, voglio scoprire che cosa sono le intestazioni di cosa / include / linux e che cosa sono le intestazioni di / include / asm-generico. Come si differenziano tra loro? Qual è la logica dietro avere due cartelle di intestazione separate? Come si relazionano tra loro?

Grazie

Il software deve essere portatile. Se compili i tuoi sorgenti C / C ++, non devi sapere se stai eseguendo i386 / x86_64 / arm / mips o altro. Le intestazioni sono collegate in modo tale da compilare il software.

Tutti gli altri file di intestazione esistono perché sono stati implementati molti standard diversi, ci sono porte da BSD e così via. Quindi molti di essi sono storicamente basati. La provenienza di ognuno e il motivo per cui si trovano lì hanno molte ragioni diverse e sicuramente faranno esplodere le risposte.

E una risposta per asm-generico: stackoverflow

Le intestazioni sottostanti asm/genericsono intese principalmente come misure di stopgap, versioni portatili in C fino a quando non viene scritta una versione specifica per l'architettura. Scoprirai anche che in alcuni casi /usr/include/foobar.hinclude una serie di intestazioni di "implementazione interna", e infine ricadiamo su una parte che viene dal kernel, spesso chiamata la stessa. Esempi sono math.he (più dipendenti da Linux) syscall.h.

arch/x86/entry/ ha due file syscall speciali:

syscalls/syscall_32.tbl e dito "64"

I syscall sono speciali perché il kernel deve riunire ABI e API.

In generale, le directory include e gli altri file di intestazione (quelli indipendenti come kernel / sched / sched.h) seguono una logica gerarchica. Penso che sia make sia gcc abbiano un ruolo.

C'è un uso sistematico di questi simboli per assicurarsi che ogni "unità" di intestazione venga letta una sola volta. ("involucri protettivi" perché potrebbero esserci troppi incroci). Qui da 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 */

I file tbl hanno:

# 32-bit system call numbers and entry vectors

L'elenco inizia con:

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.

Farò il layout più tardi ...