Existem alternativas para usar o 'udev'?

Question

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

Por exemplo, posso imaginar que deve haver uma maneira de criar um script de inicialização que crie a maioria dos nós de dispositivos que, no meu sistema (sem alterar hardware), são os mesmos da mesma forma.

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

    

Answer 1

Existem várias alternativas para udev lá fora. Aparentemente, o Gentoo pode usar algo chamado mdev . Outra opção seria tentar usar o predecessor udev do devfsd . Finalmente, você sempre pode criar todos os arquivos do dispositivo que você precisa com 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 nas outras opções. Naturalmente, você perde a flexibilidade de ter criado arquivos de dispositivo dinamicamente quando um novo hardware é conectado (por exemplo, um dispositivo USB). Acredito que a abordagem padrão nesta era era ter todos os arquivos de dispositivos que você poderia razoavelmente precisar já criados em /dev (ou seja, muitos arquivos de dispositivos).

É claro que a dificuldade em fazer com que qualquer uma dessas abordagens funcione em uma distro moderna é provavelmente bem alta. O wiki do Gentoo menciona dificuldades em fazer com que mdev trabalhasse com um ambiente de desktop (quanto mais fora do Gentoo). A última versão devfsd foi 2002, não tenho idéia se ela funcionará mesmo com os kernels modernos. Criar os nós manualmente é provavelmente a abordagem mais viável, mas até mesmo desabilitar udev pode ser um desafio, particularmente em distos usando systemd ( udev agora faz parte de systemd , o que sugere uma strong dependência).

Meu conselho é ficar com udev ;)

    

Answer 2

Os kernels Linux modernos suportam o sistema de arquivos devtmpfs ^{(não confunda com o antigo devfs )} , que cria todos os nós de dispositivos dinamicamente assim que o kernel os descobre. (Na verdade, os últimos udev releases exigem isso; você verá 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 que o udev realiza são o carregamento do módulo (de acordo com as modalias) e a aplicação de permissões do dispositivo & outras regras do udev.

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

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

1. Alguns programas de espaço de usuário contam com o udev mantendo seu banco de dados de dispositivos, acessível através de libudev . Embora enumerar dispositivos e ouvir eventos adicionados / removidos possa ser feito 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-path e assim por diante. Por exemplo, se você tiver dois discos conectados, não há garantia de que o primeiro sempre será sda ou sdb , mas o udev garante que os links simbólicos em /dev/disk/by-uuid continuem apontando para o caminho certo.

3. Embora os nós de dispositivos agora sejam criados pelo kernel e, portanto, não são mais sua preocupação, ainda é importante observar que alguns tipos de dispositivos começaram a usar números principais / secundários atribuídos dinamicamente, embora você tenha /dev/fuse como 10,228 e /dev/hpet como 10,229 hoje, eles terão números diferentes após cada reinicialização, então devtmpfs ou (em sistemas mais antigos) um programa que escuta uevents é necessário .

Muitas dessas coisas podem ser facilmente realizadas por outros programas, como mdev , é claro. Meu ponto é que um script /etc/MAKEDEV estático não vai funcionar mais ...

Então, basicamente, quando se trata de complexidade de inicialização, o udev é provavelmente o mínimo das suas preocupações.

    

Answer 3

Existem várias alternativas:

• Basta ter um conjunto de comandos chmod , chown , ln e semelhantes em um script que é executado como parte do bootstrap.
• Use systemd-udev , o gerenciador plug-and-play que faz parte do projeto systemd.
• Use eudev do Gentoo, que é uma bifurcação de systemd-udev da qual o systemd agora divergiu significativamente.
• Use o Devuan's vdev , que é um gerenciador plug-and-play desenvolvido por Jude Nelson, que faz parte de Devuan.
• Use mdev , que, ao contrário de outra resposta, não é uma coisa do Gentoo. É o gerenciador plug-and-play embutido no BusyBox .
• Use Suckless mdev que é um gerenciador plug-and-play do pessoal do Suckless.

Todos esses, além do primeiro, exigem conjuntos de regras descrevendo como reagir a eventos de notificação do kernel sobre dispositivos. Obviamente,

Também há ferramentas que executam programas criados para /proc/sys/kernel/hotplug , como os dois mdev s, e que os adaptarão e serializarão ouvindo um soquete de link de rede e gerando esses programas:

• s6-netlink-listener e s6-uevent-spawner
• netlink-datagram-socket-listen e plug-and-play-event-handler de the tools tool

Answer 4

udev? A melhor alternativa é não usá-lo. E aprendendo a não usá-lo, o Linux e o mundo do * NIX começarão a fazer mais sentido lógico.

A melhor alternativa a longo prazo é usar dispositivos estáticos (veja nota). Se você tem o driver, o kernel Linux gerencia o hot-plugging. Eu prefiro não ter executado o udevd nunca.

dbus é outro assunto. Isso faz abrandar o seu sistema, mas o mundo em constante mudança das pessoas de script adoram. Então, muitas coisas, você está acostumado, como navegadores da Web ou aplicativos com backends de script, precisam ser corrigidos (lançados ou reconstruídos sem essas coisas ou descartados para outro aplicativo).

Nota: Se você estiver apenas conectando uma unidade flash ou dispositivo de dvd, use dmesg|tail para ver o nome do dispositivo a ser montado. Aprender quando um dispositivo é um dispositivo de caracteres ou de bloco é um conhecimento fundamental do sistema no mundo do hardware do computador. No Linux é open source, veja isso muito sobre Linux, não apenas embutido . É o melhor para uma compreensão mais ampla da lógica direta (não da filosofia) de todos os * NIXs, como o Linux (Solaris, HPUX, AIX, etc.).

Udev, dbus, gconf / dconf, systemd, gnome-shell, Gnome, Glib, mono e Fedora são para pessoas com muito tempo em suas mãos que não podem RTFM, ou querendo uma atualização automática realmente fluida (procurando) mas, mais lento que o melaço, com buggy, meio caminho-lá Linux. (Um lugar realmente horrível, olhe ao redor da web para toneladas de experiências semelhantes).

O sistema inicializa e executa o udevd. Mas, alegou que o udev é necessário porque, números menores do dispositivo will change na reinicialização. A razão de ser de Udev parece se contradizer a cada passo. E onde estão os arquivos parece sempre errado, não importa quem você consulta. Não confie ou freedesktop.org.

Além disso, o udev está sendo absorvido pelo horror conhecido como systemd, não sei o que se faz com o lixo do / etc / udev. E é estúpido dizer que escrever regras do udev é de alguma forma melhor que qualquer coisa. O pessoal do gentoo parece querer segurá-lo e não ter que ter o systemd, então eles o colocaram no eudev.

Se você quer um sistema de surpresas ridiculamente rápido, não desagradável, use os princípios básicos do Linux.