Por que o libdevmapper tem estruturas de dados?

Question

Enquanto estou pesquisando libdevmapper.h para dicas sobre como usar corretamente o ioctls do mapeador de dispositivos (ou usar potencialmente o libdevmapper), estou confuso sobre o porquê de haver código aqui para criar / gerenciar uma árvore e tabela de hash .

Se o libdevmapper serve para fornecer uma interface para o mapeador de dispositivo subjacente ioctls, então qual é a motivação para incluir estruturas de dados aqui? Além disso, se o kernel já tiver estruturas de dados para gerenciar todos os mapeamentos de dispositivos, parece que qualquer estrutura de dados em nível de biblioteca abstraída seria uma versão em cache da informação real na melhor das hipóteses.

Lembre-se de que sou novo no mapeador de dispositivos, no código do kernel e nas chamadas do sistema. O que estou perdendo aqui?

    

Answer 1

Esta é uma resposta muito genérica - confesso que nem li o arquivo de cabeçalho. (Se você quiser fazer perguntas detalhadas sobre o código, estouro de pilha é o lugar certo.)

O que você parece ter perdido é que as estruturas de dados são como os programas (e até partes separadas do mesmo programa) se comunicam. Cada lado dessa comunicação precisa entender a estrutura de dados, ou então a mensagem é ininteligível.

Então, por exemplo, o kernel tem uma definição de struct stat em algum lugar, em algum cabeçalho. Seu programa também possui um, a partir de um cabeçalho diferente fornecido pela glibc (embora provavelmente ele tenha sido copiado do kernel). Quando você usa o stat syscall para obter informações sobre um arquivo, você passa ao kernel o endereço de um struct stat . O kernel preenche as informações nessa estrutura de dados. Então o seu programa lê as informações. Seu programa se comunicava com o kernel usando uma estrutura de dados.

Outro exemplo, se você passar esse struct stat * para outra função em seu programa (digamos, um responsável por exibi-lo), então seu programa se comunicou entre duas partes de si mesmo usando uma estrutura de dados.

Assim, as implementações tree e hash table no libdevmapper e, em geral, as estruturas de dados em qualquer cabeçalho da biblioteca de recursos do kernel, servirão a um (ou mais) de alguns propósitos:

1. Eles são como a biblioteca se comunica com o kernel.
2. Eles são como a biblioteca se comunica com seu programa.
3. Eles são algo que os desenvolvedores da biblioteca acham que seu programa achará útil (por exemplo, para acompanhar o estado do desvalorizador) e eles são pequenos o suficiente e / ou intimamente relacionados o suficiente para incluir sem inchar.