Estou construindo o busy-box e o iptables para um dispositivo incorporado e uma das dependências para eles são os cabeçalhos do kernel.
Procurei em todo o sistema de arquivos por arquivos * .ko e não os encontrei. Então concluí que os aplicativos não estão criando drivers carregáveis ​​(módulos do kernel).
Quais são os outros casos para um aplicativo de espaço do usuário exigir cabeçalhos de kernel?
Um exemplo fácil de apresentar é quando algo no espaço do usuário emite uma chamada do sistema.
@SamiLaine Eu acho que a biblioteca c forneceria a interface para as chamadas do sistema. Se o que você está dizendo era o caso, você não teria, por exemplo, que importar cabeçalhos do kernel apenas para abrir um soquete?
Soquete (2), é uma chamada do sistema, não uma função de biblioteca, então sim.
@SamiLaine Você pode dar um exemplo em que é necessário include <linux/*.h>abrir um soquete? (Eu estava apontando para sys / socket.h)
Como esses programas são criados para usar as coisas definidas nos cabeçalhos do kernel:
Para cada ferramenta específica, você precisa ler a fonte da ferramenta e o cabeçalho do kernel relevante para descobrir exatamente o que.
Você pode ver algumas coisas comentadas para facilitar.
Por exemplo, mkfs_vfatinclui linux/fd.hpara obter FDGETPRM:
Provavelmente, você pode remover o relevante #includee observar os erros do compilador para facilitar, receberá avisos de que algumas coisas não estão definidas. Provavelmente, essas coisas vêm dos cabeçalhos do kernel.
1. O Busybox foi projetado para sistemas embarcados e outros sistemas leves, nos quais você deseja carregar o mínimo possível de bibliotecas na memória. Eu não li a fonte, mas provavelmente o BB está basicamente evitando as bibliotecas e vinculando diretamente o kernel. 2. Não. Ele combina o binário do espaço do usuário com uma versão da API do kernel , que é compatível com versões anteriores: um binário compilado hoje pode não funcionar em um kernel antigo (dependendo dos símbolos incluídos ... leia o código-fonte), mas irá trabalhe com kernels futuros.
@suprjami A ABI obedece à ABI SysV padrão, que pode ser razoavelmente assumida como não sendo alterada; entre outras coisas, o SysV ABI é o motivo pelo qual você pode vincular o kernel ao seu compilador (e versão) de sua escolha, não necessariamente o mesmo que emitiu o binário do kernel.
... também possibilita chroot / LXC em uma distribuição distribuída com um kernel diferente. etc
(Para maior clareza: observe que o kernel possui uma ABI externa , da qual estamos discutindo aqui, e uma ABI interna entre os módulos do kernel, que sofre alterações frequentes e possivelmente incompatíveis, mas não é vista pelo espaço do usuário e é irrelevante ao compilar o espaço do usuário código).
(Observe também que ABI = / = API. A API (externa) do kernel inclui os símbolos referenciados no código-fonte, e os desenvolvedores do kernel se comprometeram a manter a compatibilidade; a menos que os símbolos sejam muito raramente usados ​​em software do mundo real, seria um movimento razoável para que façam mudanças incompatíveis, embora não de terceiros mandatos padrão o conjunto da API do Linux e, portanto, nada tecnicamente impede-lo).