Quando uma nova chamada de sistema é adicionada ao Linux?

Question

Ao expor a funcionalidade do kernel, existem várias alternativas para desenvolvedores de kernel. Eles podem criar uma nova chamada de sistema ou expor a funcionalidade através de / sys ou entradas / proc.

Existe algum motivo para preferir um ao outro?

Os desenvolvedores de kernel evitam adicionar novas chamadas de sistema, a menos que ofereçam uma vantagem considerável, ou adicionam chamadas livremente, como e quando necessário?

EDIT: Estou trabalhando em um projeto para expor a funcionalidade netfilter a um contêiner Linux (LXC). A funcionalidade deve ser exposta de maneira controlada, por exemplo, quando um contêiner (digamos c1), deseja colocar um gancho netfilter, o gancho deve ser chamado somente quando os pacotes são para as interfaces de rede em c1.

Eu posso criar novas chamadas de sistema ou permitir que contêineres instalem um módulo e forneça uma camada de tradução no kernel, que protege o kernel do host do módulo de kernel instalado pelo guest. (A implementação deste módulo de tradução ou as implicações de segurança de permitir que os contêineres instalem um módulo podem ser um tópico para outra discussão).

Adicionar uma nova chamada de sistema garantiria um melhor isolamento, enquanto que permitir que os convidados instalem o módulo terá um melhor desempenho. O último também pode expor funcionalidades que não podem ser expostas por chamadas de sistemas, por exemplo, se o convidado quiser usar sua própria versão de pilha TCP / IP.

O que um experiente desenvolvedor de kernel do Linux prefere?

    

Answer 1

Novas chamadas de sistema são adicionadas muito raramente. A maioria das novas funcionalidades do kernel pode ser alcançada através de alguns mecanismos gerais:

• Os descritores de arquivos são um recurso muito geral para o gerenciamento de recursos.
• As ações personalizadas nos descritores de arquivos ocorrem por meio de ioctl .
• As interações também são possíveis através do sistema de arquivos proc e sua variante sysfs para informações relacionadas a hardware e driver.

Esses mecanismos gerais se beneficiam do suporte genérico existente. Por exemplo, recursos anexados a um descritor são automaticamente compartilhados com processos filhos, automaticamente fechados em execve se sinalizado para fazer isso, liberados quando o descritor é fechado (o que acontece quando o processo morre), etc. Controle de acesso a novos recursos implementados como arquivos é fornecido através dos mecanismos de controle de acesso a arquivos bem estabelecidos (permissões, SELinux, etc.).

Esses mecanismos gerais também são mais fáceis de usar do que uma nova chamada de sistema, pois podem ser usados imediatamente, sem esperar pelo suporte da biblioteca. Uma nova entrada em /proc pode ser usada diretamente de um script de shell. Um novo ioctl pode ser usado diretamente do aplicativo. Uma nova chamada de sistema precisa ser declarada na biblioteca padrão.

A página de manual syscalls lista a versão do kernel na qual cada chamada de sistema foi adicionada . A maioria das novas chamadas de sistema oferece novas maneiras de manipular certos tipos de arquivos, seja para gerenciar metadados e credenciais (por exemplo, suporte de atributo estendido no 2.6) ou como operações de variações antes impossíveis (por exemplo, execveat , renameat2 ).

    

Answer 2

Este documento do Linux fornece as diretrizes para adicionar novas chamadas de sistema.

Aqui estão os principais pontos do assunto, relacionados à nossa discussão

• Quando uma nova chamada de sistema é adicionada, ela se torna parte da API do kernel e precisa ser suportada indefinidamente.
• Criar uma nova chamada de sistema também é uma responsabilidade maior, pois envolve a criação de código de teste, páginas de manuais e uma motivação grande o suficiente para incluí-la no kernel principal, em vez de ser enviada como um módulo do kernel.
• Se a nova funcionalidade se assemelhar a interações de sistema de arquivos em uso (por exemplo, informações de tempo de execução como uso de memória podem ser obtidas por uma simples leitura em / proc / meminfo), use / proc, / sys, / dev entries. Eles podem ser criados por um módulo e podem ser colocados e retirados do kernel como e quando necessário. Eles também oferecem as vantagens dadas na resposta de Gilles.

Estas linhas de outro arquivo na documentação do kernel do Linux, explicando processo de desenvolvimento, destaque o esforço que deve ser feito antes de expor uma ABI de espaço de usuário.

Once an interface has been exported to user space, it must be supported indefinitely. This fact makes the creation of user-space interfaces particularly challenging: since they cannot be changed in incompatible ways, they must be done right the first time.

For this reason, a great deal of thought, clear documentation, and wide review for user-space interfaces is always required.