Como implemento um driver de driver de sistema de arquivos no Linux? [fechadas]


14

Suponha que eu inventei um novo sistema de arquivos e agora quero criar um driver para ele.

Como eu implementaria esse driver do sistema de arquivos, isso é feito usando um módulo do kernel?

E como o driver do sistema de arquivos pode acessar o disco rígido, o driver do sistema de arquivos deve conter código para acessar o disco rígido ou o Linux contém um driver de dispositivo para acessar o disco rígido usado por todos os drivers do sistema de arquivos?

Respostas:


24

Sim, os sistemas de arquivos no Linux podem ser implementados como módulos do kernel. Mas há também a interface FUSE (Filesystem in USErspace), que pode permitir que um processo regular do espaço do usuário atue como um driver do sistema de arquivos. Se você estiver criando um novo sistema de arquivos para prototipagem, implementá-lo primeiro usando a interface do FUSE pode facilitar o teste e o desenvolvimento. Depois de elaborar as partes internas do sistema de arquivos no formato FUSE, você poderá começar a implementar uma versão do módulo do kernel com desempenho otimizado.

Aqui estão algumas informações básicas sobre como implementar um sistema de arquivos no espaço do kernel. É bastante antigo (de 1996!), Mas isso deve fornecer pelo menos uma idéia básica para o tipo de coisa que você precisa fazer.

Se você optar por ir para a rota do FUSE, aqui está a libfuse, a implementação de referência do lado do espaço do usuário da interface do FUSE.

Driver do sistema de arquivos como um módulo do kernel

Basicamente, a função de inicialização do módulo do driver do sistema de arquivos precisa apenas chamar uma register_filesystem()função e fornecer como parâmetro uma estrutura que inclua um ponteiro de função que identifique a função no driver do sistema de arquivos que será usada como a primeira etapa na identificação do sistema de arquivos tipo e montagem. Nada mais acontece nessa fase.

Quando um sistema de arquivos está sendo montado e o tipo de sistema de arquivos é especificado para corresponder ao seu driver ou a detecção automática do tipo de sistema de arquivos está sendo executada, a camada Virtual FileSystem (VFS para abreviado) do kernel chama essa função. Basicamente, diz "Aqui está um ponteiro para uma representação no nível do kernel de um dispositivo de bloco padrão do Linux. Dê uma olhada, veja se é algo que você pode manipular e depois me diga o que você pode fazer com ele".

Nesse ponto, seu driver deve ler o que for necessário para verificar se é o driver correto para o sistema de arquivos e, em seguida, retornar uma estrutura que inclua ponteiros para outras funções que seu driver pode fazer com esse sistema de arquivos específico. Ou, se o driver do sistema de arquivos não reconhecer os dados no disco, ele deve retornar um resultado de erro apropriado e o VFS relatará uma falha no espaço do usuário ou - se a detecção automática do tipo de sistema de arquivos estiver sendo executada - solicitará outro sistema de arquivos motorista para tentar.

Os outros drivers no kernel fornecerão a interface padrão do dispositivo de bloco, portanto o driver do sistema de arquivos não precisará implementar o suporte de hardware. Basicamente, o driver do sistema de arquivos pode ler e gravar blocos de disco usando funções padrão no nível do kernel com o ponteiro do dispositivo fornecido.

A camada VFS espera que o driver do sistema de arquivos disponibilize várias funções padrão para a camada VFS; alguns deles são obrigatórios para que a camada VFS faça algo significativo com o sistema de arquivos, outros são opcionais e você pode simplesmente retornar um NULL no lugar de um ponteiro para uma função opcional.


1
Essa é uma resposta muito boa, mas para responder totalmente à pergunta, conforme indicado, você também precisará falar um pouco sobre a funcionalidade que a camada de dispositivo de bloco fornece para a camada do sistema de arquivos ser construída.
kasperd

Eu meio que aludei a isso com o bit "aqui está um ponteiro para um dispositivo de bloco padrão", mas um bom ponto; Eu expandi isso.
telcoM 24/03/19

Esta resposta, especificamente a descrição do que acontece em que ordem, é divina. Existe algum tipo de livro / site que eu possa ler que tenha descrições como essa para todos "como o linux funciona"?
Adam Barnes

Você pode estar interessado em Linux Kernel Internals ou Linux Device Drivers, 3rd Edition . E, claro, há a opção de ler o código fonte real.
TelcoM 25/03/19


0

Sim, isso normalmente seria feito usando um driver do kernel que pode ser carregado como um módulo do kernel ou compilado no kernel.

Você pode conferir drivers semelhantes do sistema de arquivos e como eles funcionam aqui .

Esses drivers provavelmente usam funções internas do kernel para acessar dispositivos de armazenamento como blocos de bytes, mas você também pode usar dispositivos de bloco expostos por drivers nas pastas de dispositivos de bloco e dispositivos de caracteres .


0

Você pode usar o fusível, para criar um sistema de arquivos do usuário ou gravar um módulo do kernel. É mais fácil fazer o fusível, pois você tem uma escolha de idiomas e não trava o kernel (e, portanto, todo o sistema).

Os módulos do kernel podem ser mais rápidos, mas a primeira regra de otimização é: Não faça isso até que você tenha testado o código de funcionamento. A segunda é a seguinte: não faça isso até ter provas de que é muito lento. E a terceira: não guarde, a menos que você tenha evidências de que o torna mais rápido / menor.

E sim, o kernel já possui drivers para o hardware, você não os implementa novamente.


Existem outras desvantagens do FUSE além do desempenho: é difícil usá-lo no seu sistema de arquivos raiz. (Talvez possível com um initrd, mas o binário FUSE não poderia ser liberada após a inicialização porque ele ainda seria executar a partir do disco RAM.)
Peter Cordes

1
@ PeterCordes Não foi possível liberar , mas isso não significa que não possa ser desvinculado. Se ainda houver uma referência a ela, ela será mantida na memória, independentemente de você ter ou não deixado o initramfs e excluído o binário subjacente.
forest

@forest: certo, portanto você não pode desmontar o initrd depois pivot_root, porque ainda existem inodes ocupados no initramfs.
Peter Cordes

Um normal /initiniciado a partir de um initramfs (acho) será executado /initapós pivot_root, para transferir o controle para os FS raiz reais /init. Mas um binário do FUSE não poderia se substituir pelo execve se o acesso ao FS raiz dependesse do processo do FUSE responder ao kernel. Bem, talvez preparando o pagecache primeiro, mas isso não parece confiável.
Peter Cordes
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.