the kernel use sysfs to export device nodes to user space to be used by udev
Não. Sysfs não contém nós de dispositivo. O Sysfs contém principalmente arquivos que fornecem informações sobre dispositivos, bem como alguns arquivos que permitem que os processos controlem como os dispositivos operam. Mas a maior parte dos dispositivos não pode ser usada com o que o sysfs fornece.
Vamos pegar um disco rígido, por exemplo. Há um diretório para ele em algum lugar em /sys/devices , com um caminho que depende de como ele está conectado ao computador (por exemplo, /sys/devices/pci0000:00/… para um disco conectado a um controlador conectado ao barramento PCI principal do computador). Nesse diretório, você pode encontrar várias informações, como seu tamanho, se é removível, seu estado de energia, etc. Existem subdiretórios para partições também. Mas não há nada lá que forneça acesso ao conteúdo do disco. Em outros lugares em /sys , há links simbólicos para o diretório correspondente a esse disco: em /sys/block , em /sys/class/block , etc. Mas ainda nada para acessar o conteúdo do disco.
Em /dev , a entrada para o disco é um arquivo especial - um dispositivo de bloqueio . Este arquivo permite que os processos leiam e gravem o conteúdo do disco. (Embora para um disco que geralmente não acontece, em vez disso o conteúdo do disco - ou de uma partição - é montado, então o kernel está acessando o dispositivo, os processos não.)
Os arquivos de dispositivos permitem que algumas operações, além de ler e escrever conteúdo, sejam feitas por meio de ioctl . Seria possível fornecer todas as informações e interfaces de controle fornecidas pelo sysfs através do ioctl no arquivo do dispositivo. No entanto, isso seria menos conveniente por vários motivos:
- Com arquivos separados em
/sys, as permissões podem ser definidas com granulação fina. Com um único arquivo por dispositivo em/dev, é tudo ou nada. - Arquivos separados podem ser lidos e gravados facilmente pelos aplicativos. Você pode usar apenas
catouecho. Com o ioctl, é muito mais difícil: não há interface shell, geralmente nenhuma interface em outras linguagens de alto nível. - Com o ioctl, o comando deve ser codificado em um número em vez de um nome, e o formato dos argumentos deve ser definido em um nível binário. Usar nomes e formatos de texto simples facilita a gravação de software.
Indo na outra direção, seria possível fornecer acesso ao conteúdo do dispositivo por meio de um arquivo no sysfs. Mas isso exigiria trabalho extra no kernel: o sysfs foi projetado principalmente para servir arquivos pequenos e links simbólicos e sem o suporte ioctl que os aplicativos existentes esperam. Eu não acho que haveria um benefício significativo em expandir o sysfs para suportar tipos de dispositivos existentes, daí a existência continuada de arquivos de dispositivos.
O Sysfs é automaticamente preenchido pelo kernel, refletindo os dispositivos realmente disponíveis em tempo real. O significado de um arquivo no sysfs vem de seu caminho, que é escolhido pelo driver que fornece esse arquivo. /dev funciona de maneira diferente: o significado de um arquivo vem do tipo de arquivo do dispositivo (bloco ou caractere) e seus números principais e secundários (é o que ls -l lista em vez do tamanho do arquivo de um dispositivo). Tradicionalmente, /dev era estático, com arquivos de dispositivos criados durante a instalação do sistema; mas isso não funciona tão bem quando os dispositivos podem ser hotplugged, daí o desejo de um /dev dinâmico que reflete os dispositivos conectados em tempo real.
O Linux passou por várias iterações de um dinâmico /dev . O Linux 2.4 tem devfs , onde o kernel cria automaticamente entradas para refletir os dispositivos conectados. Mas isso foi não tão legal , porque codificou as políticas de nomeação e permissão de dispositivos para o kernel, então foi substituído pelo programa udev da userland para gerenciar policy, e /dev em um sistema de arquivos tmpfs simples (um sistema de arquivos na memória sem significado especial para o kernel). E então o devfs fez um retorno parcial, com o devtmpfs , que é uma instância do tmpfs onde as entradas para os dispositivos disponíveis são criadas automaticamente pelo kernel, mas o udev faz todo o gerenciamento que quiser além disso.