Quais problemas o udev realmente resolve?

Question

Para essa questão, o que exatamente estava errado com um monte de arquivos estáticos em /dev ? É aparentemente insatisfatório o suficiente para os desenvolvedores reinventarem essa roda pela minha contagem 3 vezes agora ( devfs - > udev + HAL - > udev ), e agora aparentemente está entrando também no Grand Unified Init Program, então quatro vezes.

Eu me lembro quando comecei a usar o Linux anos atrás surpreendendo-me que apesar das afirmações de que "tudo é um arquivo", não há /dev/eth0 (que depois fazia sentido, já que não é um dispositivo char ou block) um tipo de dispositivo "pacote" seria interessante ...). Dado isso, por que o programa que manipula a árvore de arquivos de dispositivos char e block também é responsável pelos dispositivos de rede? Já vi referências vagas à "flexibilidade", mas o que isso adiciona ao que, digamos, o ifconfig (8) faz apenas olhando em /proc/net/dev ? Eu sei, por exemplo, que o NetworkManager não estará na Net ou no OpenBSD em breve porque depende de udev , que nenhuma das duas equipes quer escrever; o que eu não entendo é por que um programa que pelo menos nominalmente existe para gerenciar a árvore /dev aparentemente é a única maneira de expor dispositivos de rede que já estão expostos de várias formas pelo kernel (e nenhum deles em /dev !).

É só por causa do hotplugging? Houve problemas com o kernel apenas ouvindo os barramentos físicos e carregando os módulos apropriados em uma mensagem "dispositivo adicionado"? Ou, Deus me livre, o administrador atual está fazendo isso? Eu lembro que no início dos anos 2000 meus servidores às vezes inicializavam suas placas de rede em uma ordem inesperada, e eu suponho que faz sentido ter essa nomenclatura sendo decidida em userland (embora não fosse muito difícil consertar isso na época), mas isso parece uma marreta para uma barata. (Ou talvez esse problema atinja casos de uso. Não estou pensando muito mais do que em servidores ou PCs montados em rack, que são minha experiência.)

Então, para declarar minha pergunta claramente: quais problemas o udev realmente resolve, e como o devfs, o HAL e / ou um arquivo antigo não conseguem resolvê-los? Existe uma razão particular para que muitas coisas diferentes (hotplugging, gerenciamento geral de dispositivos, gerenciamento de dispositivos de rede, nomeação de dispositivos, prioridade de driver, etc.) sejam todas um programa?

    

Answer 1

Mais duas coisas: a migração do Linux para a empresa & outros servidores grandes estavam expondo a static /dev a ser quebrada. O avanço da tecnologia, tanto no consumidor quanto na empresa, estava expondo a static / dev como uma brincadeira. [Esta resposta preenche mais o histórico, não particularmente porque o devfs foi substituído pelo udev].

Exaustão de Major & Espaço Numérico Menor

/dev arquivos são identificados dentro do kernel por seus números maiores e menores. O kernel nunca se importou com o nome (e você poderia, por exemplo, mv /dev/sda /dev/disk-1 e continuar a trabalhar - embora os programas do curso não saibam onde encontrá-lo).

Com um /dev estático, você precisa alocar um número maior / menor para cada dispositivo em potencial que possa existir. Esses números precisam ser únicos globalmente, já que são enviados como parte de distros, não criados sob demanda. O problema é que eles são números de 8 bits - o intervalo é de 0 a 255.

Originalmente, por exemplo, o Linux começou com 8,0 sendo sda, 8,1 sendo sda1, 8,16 sendo sdb, etc. Mas as pessoas continuaram adicionando mais e mais discos às máquinas, especialmente quando você considera coisas como o canal de fibra . Então, em algum momento, números maiores de 65 a 71 foram adicionados para mais discos. Mais tarde, grandes números 128–135. E ainda assim as pessoas continuaram querendo mais discos ...

E os formatos de tabelas de partições como o GPT surgiram, suportando mais partições por disco. E, claro, outros dispositivos estavam comendo o espaço numérico: vários controladores RAID, gerenciamento de volume lógico, etc.

O resultado final pode ser visto na Lista de dispositivos LANANA Linux . Se você olhar para a lista 2.6 (a única que ainda existe), muitos dos números maiores do bloco até 200 (máx: 255) são usados. Claramente, os números teriam acabado.

Mudar para números maiores não foi fácil. Altera o kernel ABI. Dependendo do sistema de arquivos, ele altera o layout do disco. Mas, é claro, a maioria desses dispositivos não existia em nenhum sistema, mesmo um que estivesse (por exemplo) sem discos SCSI provavelmente tinha muitas coisas gratuitas - provavelmente não precisa de um disco rígido IBM XT, por exemplo.

Com um /dev dinâmico, a distro não precisa enviar os números dos dispositivos. Eles não precisam mais ser globalmente únicos. Eles nem precisam ser únicos nas botas.

Os nomes dos dispositivos eram imprevisíveis

Costumava ser muito fácil atribuir um número a tudo. Uma placa tinha dois canais IDE; Cada canal IDE suportava um mestre e um escravo. Você pode atribuir na ordem do canal e na ordem do mestre-então-escravo. Então hda se torna primeiro canal, mestre; hdb primeiro canal, escravo; hdc segundo canal, mestre; Esses eram previsíveis e estáveis. Eles podem mudar se você adicionar uma nova unidade, ou remover uma, mas sem alteração de hardware, eles são estáticos.

Você pode colocar /dev/hda1 no seu /etc/fstab e ter certeza de que ele continuará funcionando, pelo menos com alterações de hardware ausentes.

IDE funcionou assim. Nada depois disso.

O SATA parece ser simples: uma porta, um disco. Mas não é assim; permite multiplicadores de porta. E isso permite hot-swap. Ainda assim, alterações de hardware ausentes, você ainda pode manter o mapeamento funcionando.

O USB é muito pior. Não só permite hot swap, é típico. As pessoas conectam drives flash USB o tempo todo. Além disso, os dispositivos podem demorar um pouco para serem investigados e, na verdade, podem ser alterados sempre que quiserem (por exemplo, quando você ativa ou desativa o modo de armazenamento USB no telefone). Firewire é semelhante. Com nem você pode realmente chegar a um mapeamento estável.

Os discos conectados à rede não têm nenhuma ordem de porta inerente. A única ordem que o kernel usa é a ordem em que aparecem. O mesmo acontece com os volumes lógicos.

A busca pela velocidade de inicialização também piorou as coisas. Originalmente, o kernel ficaria feliz em ficar sentado e esperar bastante tempo por, por exemplo, todos os dispositivos USB para inicializar. Para testar completamente todos os barramentos SCSI, etc. Esses testes foram feitos em tarefas em segundo plano; boot não iria mais esperar por eles. Os dispositivos são adicionados conforme as sondas são concluídas.

Assim, o kernel ficou com, mais ou menos, "qualquer ordem em que aparecem". Isso significa que muitos tipos de dispositivos podem e mudam a ordem de cada inicialização - o que estava em uma inicialização /dev/sdb estava em outra inicialização /dev/sdc . Isso torna a idéia de uma piada /dev a estática.

Resumo

Quando você toma a combinação de estática /dev se tornando cada vez mais insignificante devido a ordens de sondagem de dispositivo imprevisíveis e continua alocando números principais / secundários estáticos levando a um trabalho substancial para não acabar, fica claro por que os desenvolvedores do Linux optaram por mudar para um% dinâmico/dev.

    

Answer 2

Boa pergunta.

De certa forma, este argumento poderia ser revertido: desde que o kernel 2.6.13 introduziu uma nova versão de uevent , estava fadado a acontecer que devfs precisaria ser reescrito para tirar proveito da interface Novas características. Então, de certo modo, a questão deveria ser por que a mudança no kernel.

No entanto, considerando o valor de face, sua pergunta é respondida em artigo da Wikipédia :

Unlike traditional Unix systems, where the device nodes in the /dev directory have been a static set of files, the Linux udev device manager dynamically provides only the nodes for the devices actually present on a system. Although devfs used to provide similar functionality, Greg Kroah-Hartman cited a number of reasons for preferring its implementation over devfs:

1) udev supports persistent device naming, which does not depend on, for example, the order in which the devices are plugged into the system. The default udev setup provides persistent names for storage devices. Any hard disk is recognized by its unique filesystem id, the name of the disk and the physical location on the hardware it is connected to.

2) udev executes entirely in user space, as opposed to devfs' kernel space. One consequence is that udev moved the naming policy out of the kernel and can run arbitrary programs to compose a name for the device from the device's properties, before the node is created; there, the whole process is also interruptible and it runs with a lower priority.

Eu provavelmente deveria acrescentar que com o udev a possibilidade de um race condition , que basicamente solapou a nomeação de dispositivos no devfs e hotplug, é evitada. Em outras palavras: com o devfs não havia como assegurar que sua porta ethernet mais à esquerda seria chamada eth0 e sua mais à direita eth1 , fazendo (como um exemplo) a configuração de roteadores (uma porta para WAN, uma porta para a LAN) difícil de implementar.

A adoção do esquema de nomenclatura dos discos com base no GUID é outra vantagem, e mover todo o processo para o espaço do usuário é ainda maior: você pesquisou por este site para ver quantas pessoas escrevem suas próprias regras do udev?

Como um exemplo simples das vantagens inerentes em ter o udev no userspace, marque ou esta questão ou esta outra questão , ambos neste mesmo site.