Como descubro quais drivers do sistema de arquivos são compilados no kernel do Linux?

Question

Em um sistema linux em execução, o que é uma maneira portátil (entre distribuições linux) de descobrir quais sistemas de arquivos o kernel atual tem compilado (não através de módulos) de suporte para?

Considere, por exemplo, meu kernel atual do Ubuntu x86_64: 3.11.0-24-generic #41-Ubuntu . Não tem, por exemplo, /proc/config.gz , o que seria meu primeiro pensamento contrário.

O motivo pelo qual estou interessado é que eu gostaria de (programaticamente) construir um ambiente de resgate com o kernel atual e um ramdisk inicial que o kernel possa carregar / montar.

É tão simples quanto comparar /proc/filesystems com lsmod ?

Em caso afirmativo: Os módulos sempre têm o mesmo nome exato (primeira coluna de lsmod output) como o nome do sistema de arquivos (última coluna em /proc/filesystems )?

Existe talvez uma maneira mais moderna, como /sys em vez de /proc , de procurar informações?

Minha abordagem atual é a seguinte. Alguém pode confirmar que está correto ou aconselhar como fazê-lo?:

for fscand in $(awk '{print $NF}' /proc/filesystems)
do
  if test $(lsmod | grep -c -e '^'${fscand}'[^a-z0-9_-]') -eq 0
  then
    candlist="${fscand} ${candlist}"
  fi
done

for fscand in $candlist
do
  echo $fscand is compiled-in
done

    

Answer 1

Is is as simple as comparing /proc/filesystems with lsmod?

Não:

$ comm -31 <(lsmod | awk 'NR!=1 {print $1}' |sort) \
           <(</proc/filesystems awk '{print $NF}' |sort) | fmt
anon_inodefs autofs bdev cgroup cpuset debugfs devpts devtmpfs ext2 ext3
fuseblk fusectl hugetlbfs mqueue nfs4 pipefs proc pstore ramfs rootfs
rpc_pipefs securityfs sockfs sysfs tmpfs

Muitos deles não estão embutidos no kernel nesse sistema. autofs é fornecido por um módulo chamado autofs4 , enquanto nfs4 é fornecido por um módulo chamado nfs . O módulo ext4 fornece ext2 e ext3 , bem como ext4 ; fuse fornece fuseblk e fusectl . rpc_pipefs (não confundir com pipefs ) é fornecido por sunrpc .

Ainda assim, o sistema pode carregar um módulo para um sistema de arquivos sob demanda: quando você executa mount -t foo … , se foo não for compatível com o sistema de arquivos, o Linux tentará carregar um módulo que forneça esse sistema de arquivos. A maneira como isso funciona é que o kernel detecta que foo não é um sistema de arquivos suportado e chama modprobe para carregar um módulo chamado fs-foo . O mecanismo é semelhante ao pci:… aliases para carregar o driver para um periférico de hardware PCI por sua ID PCI e usb:… , que é semelhante à USB - consulte Como atribuir driver USB ao dispositivo e O Debian não detecta placa PCI serial após a reinicialização para mais explicações. Os aliases do módulo fs-… são registrados em /lib/$(uname -r)/modules.alias . Este arquivo é gerado quando você constrói o kernel.

Em condições normais, você pode usar isso para determinar quais sistemas de arquivos são fornecidos pelos módulos. Por eliminação, os sistemas de arquivos que não são fornecidos pelos módulos são embutidos no kernel. Há casos de borda raros em que essa abordagem não funcionaria, por exemplo, se você modificou ou apagou o arquivo modules.alias ou se um sistema de arquivos é fornecido por um módulo e em um formulário compilado. Eu não sei de uma maneira de lidar com esses casos antes de escrever algum código do kernel e carregá-lo como um módulo.

for fs in $(</proc/filesystems awk '{print "fs-" $NF}' |sort); do
  /sbin/modprobe -n $fs 2>/dev/null || echo "$fs is built in"
done