☰

Organização dos cabeçalhos do kernel Linux

tag-icon • tag-icon linux kernel linux-kernel
Organização dos cabeçalhos do kernel Linux

Enquanto lia algumas chamadas do sistema, fiz uma pesquisa por "syscalls.h" para encontrar o arquivo de cabeçalho no LXR. Os resultados da pesquisa me intrigaram. Há uma dúzia de arquivos "syscalls.h" provenientes de diretórios em "arch/_arch_name_/include/asm". Tudo bem, são definições específicas da arquitetura ou algo mais necessário. A questão é por que temos dois cabeçalhos "syscalls.h" diferentes em /include/linux e /include/asm-generic?

Além disso, quero descobrir para que servem os cabeçalhos /include/linux e para que servem os cabeçalhos /include/asm-generic. Como eles se diferenciam? Qual é a lógica por trás de duas pastas de cabeçalho separadas? Como eles se relacionam?

Obrigado

Responder1

Os cabeçalhos abaixo asm/genericservem principalmente como medidas provisórias, versões portáteis em C até que uma versão específica da arquitetura seja escrita. Você também descobrirá que, em alguns casos, /usr/include/foobar.hinclui uma série de cabeçalhos de "implementação interna" e, finalmente, recorre a uma parte que vem do kernel, geralmente chamada de igual. Os exemplos são math.he (mais dependente do Linux) syscall.h.

Responder2

O software deve ser portátil. Se você compilar suas fontes C/C++, não precisará saber se está executando i386/x86_64/arm/mips ou qualquer outra coisa. Os cabeçalhos são vinculados de forma que o software seja compilado.

Todos os outros arquivos de cabeçalho existem porque foram implementados em vários padrões diferentes, existem portas do BSD e assim por diante. Muitos deles têm base histórica. De onde vem cada um e por que existe tem muitos motivos diferentes e certamente irá explodir as respostas.

E uma resposta para asm-genérico:fluxo de pilha

Responder3

arch/x86/entry/tem dois arquivos syscall especiais:

syscalls/syscall_32.tbl e aqui "64"

Syscalls são especiais porque o kernel precisa unir ABI e API.

Em geral, os diretórios de inclusão e os demais arquivos de cabeçalho (independentes como kernel/sched/sched.h) seguem uma lógica hierárquica. Acho que tanto o make quanto o gcc desempenham um papel.

Há um uso sistemático desses símbolos para garantir que cada “unidade” de cabeçalho seja lida apenas uma vez. ("invólucros protetores" porque pode haver muitas linhas cruzadas). Aqui 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 */

Os arquivos tbl possuem:

# 32-bit system call numbers and entry vectors

A lista começa com:

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.

mais tarde farei o layout...

informação relacionada