☰

Existem alternativas para usar o `udev`?

tag-icon • tag-icon linux devices udev
Existem alternativas para usar o `udev`?

Embora eu entenda a grandeza do udev e aprecie o esforço dos desenvolvedores, estava simplesmente me perguntando se existe uma alternativa para ele.

Por exemplo, posso imaginar que deveria haver uma maneira de criar um script de inicialização que criasse a maioria dos nós de dispositivos que em meu sistema (sem alteração de hardware) são praticamente os mesmos.

O benefício ou motivo que eu gostaria de pular udevseria o mesmo de pular dbus, ou seja, reduzir a complexidade e, com isso, aumentar minhas alterações para configurar o sistema com mais segurança.

Responder1

Os kernels Linux modernos suportam o devtmpfssistema de arquivos (não confunda com antigo devfs) , que cria todos os nós de dispositivos dinamicamente assim que o kernel os descobre. (Na verdade, os últimos udevlançamentosexigiresse; você descobrirá que o udev não cria mais nenhum nó de dispositivo, apenas links simbólicos.)

Da mesma forma, o carregamento do firmware também foi movido para o kernel, portanto, as únicas tarefas restantes udevexecutadas são o carregamento do módulo (de acordo com modaliases) e a aplicação de permissões de dispositivo e outras regras do udev.

Então, em teoria, um kernel totalmente monolítico deveriabotamuito bem sem o udev.

No entanto, o verdadeiro problema aqui é o que acontece depois.

  1. Muitos programas de espaço de usuário dependem do udev para manter seu banco de dados de dispositivos, acessível através do libudev. Embora a enumeração de dispositivos e a escuta de eventos adicionados/removidos possam ser feitas diretamente usando as interfaces do kernel (sysfs e netlink), você ainda ficará sem todos os metadados que várias regras do udev anexaram.

  2. As regras do udev também mantêm vários links simbólicos "persistentes" em /dev/disk/by-*, /dev/mapper, /dev/input/by-path, /dev/snd/by-pathe assim por diante. Por exemplo, se você tiver dois discos conectados, não há garantia de que o primeiro será sempre sdaou sdb, mas o udev garante que os links simbólicos /dev/disk/by-uuidcontinuarão apontando para o correto.

  3. Embora os nós de dispositivos agora sejam criados pelo kernel e, portanto, não sejam mais sua preocupação, ainda é importante observar que alguns tipos de dispositivos começaram a usar números maiores/secundários atribuídos dinamicamente, portanto, mesmo que você tenha /dev/fuse10.228 e /dev/hpet10.229 hoje, elesvaitêm números diferentes após cada reinicialização, então devtmpfsou (em sistemas mais antigos) um programa que escuta uevents éobrigatório.

Muitas dessas coisas poderiam ser facilmente feitas por outros programas como o mdev, é claro. O que quero dizer é que um /etc/MAKEDEVscript estático não funcionará mais ...

Então, basicamente, quando se trata de complexidade de inicialização, o udev é provavelmente oao menosde suas preocupações.

Responder2

Existem várias alternativas por udevaí. Aparentemente o Gentoo pode usar algo chamadomdev. Outra opção seria tentar usar udevo antecessor do devfsd. Finalmente, você sempre pode criar todos os arquivos de dispositivo necessários com a extensão mknod.

Observe que com este último não há necessidade de criar tudo no momento da inicialização, pois os nós podem ser criados no disco e não em um sistema de arquivos temporário como acontece com as outras opções. É claro que você perde a flexibilidade de criar arquivos de dispositivos dinamicamente quando um novo hardware é conectado (por exemplo, um pendrive). Acredito que a abordagem padrão nesta época era ter todos os arquivos de dispositivo que você poderia razoavelmente precisar já criados /dev(ou seja, muitos arquivos de dispositivo).

É claro que a dificuldade de fazer com que qualquer uma dessas abordagens funcione em uma distribuição moderna é provavelmente bastante alta. O wiki do Gentoo menciona dificuldades em mdevtrabalhar com um ambiente desktop (muito menos fora do Gentoo). O último devfsdlançamento foi em 2002, não tenho ideia se funcionará com kernels modernos. Criar os nós manualmente é provavelmente a abordagem mais viável, mas até mesmo desativá-los udevpode ser um desafio, especialmente no uso disto systemd( udevagora faz parte do systemd, o que sugere uma forte dependência).

Meu conselho é ficar com udev;)

Responder3

Existem várias alternativas:

  • Basta ter um conjunto de comandos apropriados chmod, chown, lne similares em um script que é executado como parte do bootstrap.
  • Use o systemd-udev, o gerenciador plug-and-play que faz parte do projeto systemd.
  • UsarGentooeudev, que é um fork do systemd-udevqual o systemd agora divergiu significativamente.
  • UsarDevuanvdev, que é um gerenciador plug-and-play desenvolvido por Jude Nelson, que faz parte do Devuan.
  • Use mdev, que ao contrário de outra resposta não é coisa do Gentoo. É o gerenciador plug-and-play integradoOcupadoBox.
  • UsarInútilmdevque é um gerenciador plug-and-play desenvolvido por Dimitris Papastamos.
  • UsarLaurent Bercotmdevd, que tem configuração compatível com o BusyBox, mdevmas faz seu próprio manuseio de soquete e não entende o protocolo LISTEN.

Todos estes, exceto o primeiro, exigem conjuntos de regras que descrevem como reagir a eventos de notificação do kernel sobre dispositivos. Obviamente.

Existem também ferramentas que pegam programas projetados para /proc/sys/kernel/hotplug, como os dois mdevprogramas, e que os adaptam e serializam ouvindo um soquete netlink e, em seguida, gerando esses programas:

Responder4

Isso é antigo, mas quero capturar minha solução aqui para qualquer pessoa que esteja pesquisando em vão.
Não é fácil evitar o udev. Deixar o DEVTMPFS fora da configuração não impede o kernel de montar um disco RAM em /dev e preenchê-lo. Infelizmente, ele não cria os pontos de montagem /dev/shm e /dev/pts necessários. O que é necessário é adicionar devtmpfs.mount=0 aos argumentos de inicialização.

informação relacionada