Organización de encabezados de kernel de Linux

Mientras leía un poco sobre las llamadas al sistema, busqué "syscalls.h" para encontrar el archivo de encabezado en LXR. Los resultados de la búsqueda me desconcertaron. Hay una docena de archivos "syscalls.h" que provienen de directorios en "arch / _arch_name_ / include / asm". Están bien, son definiciones específicas de la arquitectura o se necesita algo más. La pregunta es ¿por qué tenemos dos encabezados "syscalls.h" diferentes en / include / linux y / include / asm-generic?

Además, quiero saber para qué sirven los encabezados / include / linux y para qué están los encabezados / include / asm-generic. ¿Cómo se diferencian entre sí? ¿Cuál es la lógica detrás de tener dos carpetas de encabezado separadas? ¿Cómo se relacionan entre sí?

Gracias

El software tiene que ser portátil. Si compila sus fuentes C / C ++, entonces no necesita saber si está ejecutando i386 / x86_64 / arm / mips o lo que sea. Los encabezados están vinculados de tal manera que el software compila.

Todos los demás archivos de encabezado existen porque se implementaron muchos estándares diferentes, hay puertos de BSD, etc. Muchos de ellos tienen una base histórica. De dónde viene cada uno y por qué están allí tiene muchas razones diferentes y seguramente dará respuestas.

Y una respuesta para asm-generic: stackoverflow

Los encabezados debajo asm/genericestán destinados principalmente a medidas provisionales, versiones portátiles en C hasta que se escriba una versión específica de la arquitectura. También encontrará que en algunos casos /usr/include/foobar.hincluye una gran cantidad de encabezados de "implementación interna", y finalmente recurre a una parte que proviene del núcleo, a menudo llamada la misma. Los ejemplos son math.hy (más dependientes de Linux) syscall.h.

arch/x86/entry/ tiene dos archivos especiales de syscall:

syscalls/syscall_32.tbl y dito "64"

Las llamadas al sistema son especiales porque el núcleo tiene que unir ABI y API.

En general, los directorios de inclusión y los otros archivos de encabezado (independientes como kernel / sched / sched.h) siguen una lógica jerárquica. Creo que tanto make como gcc juegan un papel importante.

Hay un uso sistemático de estos símbolos para asegurarse de que cada "unidad" de encabezado se lea solo una vez. ("envolturas protectoras" porque puede haber demasiado entrecruzado). Aquí 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 */

Los archivos tbl tienen:

# 32-bit system call numbers and entry vectors

La lista comienza 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.

Haré el diseño más tarde ...