Como o Linux manipula drivers ao mudar de sistema?

Question

Isso sempre me fez pensar, mas como o Linux lida com drivers de dispositivo de sistema para sistema, então digamos que você o conecte no computador A e então mude para o computador B com especificações completamente diferentes. Além disso, os drivers também seriam afetados se você tivesse uma instalação persistente e a movesse para outro PC, o kernel iria se ajustar na inicialização, é claro que essa questão está fora dos kernels compilados customizados.

    

Answer 1

Ao contrário de outros sistemas operacionais, como o Windows, que cria uma lista do hardware com os drivers correspondentes que acompanham cada inicialização, muitas distribuições do Linux incluirão módulos do kernel para suportar a maioria das configurações de hardware para fornecer a facilidade de uso parece gostar.

Isso obviamente torna o processo de inicialização mais longo, já que o hardware é testado por todos os drivers incluídos (módulos do kernel) em vez de apenas pelos que você precisa. Graças ao design do kernel do Linux, todo esse processo normalmente não é (muito) mais lento do que executar um sistema pré-configurado, mas uma instalação personalizada do Linux pode ser inicializada mais rapidamente.

    

Answer 2

Os drivers do Linux são módulos do kernel.

Isso significa que eles podem fazer parte do grande arquivo binário que é o kernel (e, portanto, embutido), ou carregados mais tarde, após o início do kernel.

Os únicos drivers que você realmente precisa ter embutido no kernel são aqueles para acessar o sistema de arquivos raiz. Mesmo assim, é possível ter um sistema utilizável sem esses drivers, se você tiver tudo o que precisa em um disco RAM inicial. (O bootloader é responsável por carregar tanto o binário do kernel quanto o disco RAM inicial, e então o bootloader informa ao kernel onde o disco RAM inicial está quando ele inicia o kernel.)

Portanto, há algumas coisas que podem acontecer e depende inteiramente de você:

• Você pode construir um kernel com todos os drivers que ele precisa embutido. Você criaria arquivos apropriados em /dev com mknod ou similar e eles simplesmente funcionariam. Foi assim que o UNIX e o início do Linux funcionaram. É claro que se você executar o kernel + disco RAM inicial em um sistema diferente, alguns dos dispositivos não funcionarão, e se o seu controlador de disco rígido for um deles, você não conseguirá inicializar com êxito.

• Você pode ter um driver de carregamento de processo do espaço do usuário. Um trabalho de inicialização do kernel é preparar os sistemas de arquivos proc e sys virtual que dão acesso aos barramentos ACPI e PCI, que podem ser mais explorados para determinar o hardware atual. Os arquivos executáveis e de suporte responsáveis podem estar no disco RAM inicial. Isso é praticamente o que udev e systemd são. Em um sistema init Linux tradicional, udev será um dos primeiros serviços gerados em segundo plano e passará pela ACPI e por todos os busses e criará dinamicamente /dev nodes. Em um sistema baseado em systemd mais recente, a funcionalidade de udev é incluída nele e fará o mesmo.

O segundo caso é tipicamente o número de kernels do Linux + ferramentas de terras de usuários instaladas. O Linux praticamente começa de novo em cada inicialização e não faz referência a nada em um sistema parecido com um registro como o Windows.

Eu serei honesto e o texto acima provavelmente está faltando alguns detalhes, porque eu mesmo não os conheço, mas essa é a essência básica disso. Algo que eu li é que o próprio kernel pode carregar módulos durante a inicialização, mas não tem certeza de como ou por quê.