Atualizando o kernel do Linux, deixando o restante do sistema como está

Eu sou um usuário do OpenBSD. No FAQ do OpenBSD , diz:

O OpenBSD é um sistema completo, destinado a ser mantido em sincronia. Não é um kernel mais utilitários que podem ser atualizados separadamente um do outro.

Ao atualizar um sistema, você o faz de uma só vez; o kernel e o sistema base são substituídos. Então você atualiza seus pacotes de terceiros . Ao compilar a partir do código-fonte , você recompila o kernel e o inicializa. Em seguida, você reconstrói o sistema base e os pacotes que você instalou. Se tiverem passado mais de duas semanas / meses desde a última vez que você reconstruiu tudo, instale um instantâneo e reconstrua a partir daí (se estiver seguindo a ramificação CVS mais atual).

Ter um kernel fora de sincronia, um sistema básico e / ou pacotes de terceiros é uma fonte potencial de problemas e desqualifica mais ou menos você de obter qualquer ajuda séria das listas de discussão oficiais.

Eu estou bem com isso. De fato, esta é uma das razões pelas quais eu uso o OpenBSD. Torna o sistema uma unidade consistente e facilita a formação de uma visão geral mental dele.

Como é o Linux? A maioria dos Linux que eu conheço não possui um "sistema básico" no mesmo sentido que os BSDs, mas uma coleção de pacotes montados pelo provedor de distribuição. Um outro software é adicionado a isso por um administrador local de forma que a fronteira entre o que estava lá desde o início e o que foi adicionado mais tarde seja, na melhor das hipóteses, embaçada.

O Linux (em geral) não possui um núcleo forte para o acoplamento do espaço do usuário? O kernel é atualizado, tanto quanto eu sei, como qualquer outro pacote de software, e me confunde um pouco que isso seja possível. Adicione a isso o fato de que alguns compilam kernels customizados (o que é desencorajado no OpenBSD) e têm várias versões de kernel listadas em seus menus de inicialização.

Quem ou o que garante que os vários subsistemas de um sistema Linux possam cooperar entre si, mesmo sendo atualizados independentemente um do outro?

A razão pela qual estou perguntando é porque outro usuário deste site me perguntou se substituir o kernel em seu sistema Linux por uma versão mais recente "seria factível". Vindo do lado do OpenBSD, eu não poderia dizer que sim, isso garantiria que não quebraria o sistema.

Eu uso o "Linux" acima como uma abreviação de "distribuição Linux", kernel + utilitários.

Linus Torvalds tem uma opinião muito forte contra mudanças no kernel, resultando em regressões no espaço do usuário (consulte a pergunta " O kernel do Linux: quebrando o espaço do usuário " para obter detalhes).

A interface entre o espaço do usuário e o kernel é fornecida por chamadas do sistema. Os kernels mais recentes podem ter mais chamadas do sistema e alterações nas existentes quando essas alterações não quebram os aplicativos existentes. Quando uma interface de chamada do sistema possui um parâmetro flag, novos kernels geralmente expõem a nova funcionalidade com um novo sinalizador de bit. Dessa forma, o kernel mantém compatibilidade com versões anteriores dos aplicativos antigos.

Quando não foi possível alterar a interface existente sem interromper o espaço do usuário, foram adicionadas chamadas de sistema adicionais que fornecem a funcionalidade estendida. É por isso que existem três versões dupe duas versões da umountchamada do sistema.

A política de ter um espaço de usuário estável é a razão pela qual as atualizações do kernel raramente causam problemas nos aplicativos de espaço do usuário e geralmente você não espera problemas após a atualização do kernel.

No entanto, a mesma estabilidade da API não é garantida para interfaces do kernel e outros detalhes de implementação . Sysfs (on /sys) e procsfs (on /proc/) expõem detalhes da implementação do kernel na configuração de tempo de execução, hardware, rede, processos etc., que são usados ​​por aplicativos de baixo nível. É possível que essas interfaces mudem de maneira incompatível entre as versões do kernel, se houver um bom motivo. As alterações ainda tentam minimizar incompatibilidades, se possível, e existem regras sobre como os aplicativos podem usar as interfaces de uma maneira menos provável de causar problemas. O impacto também é limitado, porque aplicativos de nível inferior não devem usar essas interfaces.

O @PeterCordes apontou que, se uma alteração no procfs ou sysfs interromper um aplicativo usado pelos scripts init das suas distribuições, você poderá ter um problema.

Isso depende um pouco de como sua distribuição atualiza o kernel (suporte a longo prazo ou linha principal) e mesmo assim os problemas são relativamente raros, pois as distribuições geralmente enviam as ferramentas atualizadas ao mesmo tempo.

O @StephenKitt acrescentou que o espaço de usuário atualizado pode exigir uma versão mais recente do kernel; nesse caso, o sistema pode não conseguir inicializar com o kernel antigo e as notas de versão da distribuição mencionam isso quando apropriado.

O kernel do Linux e o espaço do usuário de uma distribuição Linux, que historicamente foi dominado pelas ferramentas de usuário desenvolvidas pelo projeto GNU, são pouco acopladas. Em parte, isso ocorre por design e, em parte, é por necessidade.

Diferente dos BSDs, onde o kernel e o espaço do usuário base são projetados e mantidos juntos, o kernel Linux e seu espaço do usuário foram desenvolvidos e mantidos por pessoas diferentes. Portanto, mantê-los fortemente acoplados seria difícil, mesmo que a comunidade desejasse, o que eu acho que não.

E o @sebasth também destaca que uma política importante do projeto do kernel Linux é que ele não deve quebrar o espaço do usuário. Qual, obviamente, é outro fator que impõe o acoplamento solto.

No entanto, ainda existe algum grau de acoplamento. Um kernel Linux suficientemente antigo não funcionará com distribuições modernas.

Meu entendimento é que o Linux é o kernel, e tudo o resto é auxiliar. Definitivamente, você pode atualizar o kernel independentemente de (muitos) pacotes instalados, pois eles geralmente estão vinculados às bibliotecas e não ao próprio kernel. Geralmente, você verá apenas esse acoplamento entre versões do kernel e drivers de hardware (por exemplo, drivers de GPU). Alguns softwares são compatíveis apenas com certas versões do kernel, mas isso deve ser especificado na documentação individual desses programas.

É bastante comum ter dois pacotes de pacotes do kernel instalados em um sistema - o pacote atualmente usado e o pacote instalado anteriormente. Ao atualizar, depois de garantir que a nova versão funcione corretamente, a mais antiga pode ser removida e você ainda possui um fallback seguro. A Red Hat (e seus primos), por exemplo, tem package-cleanup --oldkernels --count 2que fazer isso automaticamente.

Além de todos os bons argumentos aqui, posso acrescentar alguns pontos que ajudarão.

Já conhecemos a política da equipe do kernel e, como distribuições Linux, tentamos manter o código fonte do kernel o mais puro possível. Isso significa que, sempre que surge uma vulnerabilidade ou algo que precisa de um patch, informamos a equipe do kernel e tentamos ajudar com os patches, mas no final, a decisão final é da equipe do kernel.

Algumas distribuições adicionam patches extras mais do que outras, mas a idéia é mantê-lo como vem dos desenvolvedores de upstream. Obviamente, existem alguns programas que precisam de configuração especial do kernel, especialmente virtualização e drivers de terceiros e, geralmente, os dois são usados ​​para trabalhar com uma versão específica do kernel ou pelo menos uma versão não muito antiga ... o motivo é que eles tentam para trabalhar com os recursos mais recentes do kernel e, por isso, se você tentar executá-los com um kernel antigo, eles poderão não funcionar corretamente.

Um elemento extra a ser lembrado é que todas as distribuições Linux têm uma equipe de mantenedores, pessoas que garantem que todo o software seja compatível com o sistema. É por isso que quase toda distribuição tem uma versão estável e uma instável. Os desenvolvedores trabalham com software "instável" e, quando tudo é testado, eles o marcam como estáveis, somente depois que um usuário normal pode atualizar o pacote; portanto, se a pessoa que solicitou um usuário normal estiver 90% segura, o software será bem testado. .

Portanto, quem é a comunidade e qual deve ser a abordagem comum, precisamos de um software trabalhando juntos e não quebre o sistema, por isso tentamos seguir alguns padrões, como o padrão de hierarquia do sistema de arquivos .