Um grande debate se estabeleceu entre os desenvolvedores do kernel Linux em relação ao suporte ao desligamento baseado em prioridade. A polêmica está na lista de discussão do kernel Linux neste fim de semana. São visões polarizadas sobre o assunto em torno de uma nova série de patches proposta de suporte de desligamento baseado em prioridade para drivers/hardware.
Oleksij Rempel, da empresa de consultoria Pengutronix em Linux embarcado, enviou uma série de patches na sexta-feira para adicionar suporte ao desligamento baseado em prioridade. O foco está em fornecer a capacidade do kernel Linux principal de priorizar o desligamento de dispositivos específicos primeiro, como em casos de perda de energia. Este suporte de desligamento baseado em prioridade parece motivado pela indústria automotiva de Linux, onde uma solução de software como essa é “crucial em cenários como perda de energia, onde podem ocorrer danos ao hardware se não forem tratados adequadamente”.
Todaaquestão envolve desligar corretamente dispositivos críticos durante eventos de desligamento inesperados/imediatos, como quedas de energia/tensão ou desligamento total. Como parte da série de patches também está definindo os dispositivos de armazenamento (e)MMC com uma prioridade mais alta durante a fase de desligamento para ajudar a garantir a integridade/corrupção dos dados.
Embora seja de alto nível, esse suporte ao desligamento baseado em prioridade parece adequado se houver um bom motivo para um dispositivo/driver querer preparar um dispositivo para desligar primeiro, como se isso evitasse a perda de dados ou uma vantagem significativa. Mas, na prática, é mais difícil conseguir isso quando pode haver vários drivers reivindicando “prioridade” no processo de desligamento e outros obstáculos para garantir que seja um projeto sólido e resolva adequadamente um problema real.
Desenvolvedores do kernel Linux debatem suporte ao desligamento baseado em prioridade
Greg Kroah-Hartman questionou rapidamente esse suporte ao desligamento baseado em prioridade. Greg comentou inicialmente:
“Ah, divertido, agora teremos drivers e subsistemas brigando por suas prioridades, com cada um insistindo que são os mais importantes! De qualquer forma, isso está maduro para problemas e questões no longo prazo, o que há de tão especial nisso hardware que ele não pode simplesmente desligar na ordem existente, que ele tem que ser o “primeiro” sobre todos os outros? O que exatamente isso impede e quais dispositivos estão exigindo isso? E o mais importante, o que mudou nos últimos 20 anos ou mais para de repente exigem essa nova funcionalidade e como qualquer outro sistema operacional lida com isso?”
Desde então, houve muitas respostas de ambos os lados e se o kernel principal do Linux deveria ter tal funcionalidade para solucionar efetivamente designs de hardware questionáveis. Acontece que algumas versões do kernel Linux fora da árvore para a indústria automotiva já possuem esse suporte de desligamento prioritário.
Notícias Relacionadas
Futuro incerto para o BcacheFS
Debates acalorados: a suspensão de Kent Overstreet e as reações da comunidade
A suspensão temporária de Kent Overstreet, criador do BcacheFS, provocou uma avalanche de reações na comunidade Linux. Com opiniões divididas, desenvolvedores e membros da comunidade discutem sobre o impacto de suas ações e as consequências para o futuro do projeto no kernel Linux. O desenvolvedor suspenso também comentou em seu blog como tudo aconteceu. Comentários […]
Kent Overstreet
Kent Overstreet comenta suspensão em seu blog
Kent Overstreet, desenvolvedor da inovadora sistema de arquivos BcacheFS, enfrenta um momento delicado em sua carreira como contribuidor do kernel Linux. Sua suspensão temporária pelo comitê de Código de Conduta (CoC) gerou controvérsias sobre a forma como conflitos são geridos dentro da comunidade e levantou questões sobre os processos culturais e técnicos que guiam o […]
A necessidade foi resumida por Oleksij Rempel como:
“Isso evita danos ao HW. Em um trabalho típico de subtensão automotiva, geralmente é possível reproduzir uma quantidade X de eMMCs ou NANDs bloqueados em uma quantidade Y de ciclos de subtensão (não tenho números exatos no momento). Mesmo que os números não tão alto nos testes de mão de obra (às vezes algo como um dispositivo brickado em um mês de testes), os retornos de campo são significativos o suficiente para se preocupar com a solução de software para este problema.
O mesmo problema foi visto não apenas em dispositivos automotivos, mas também em dispositivos industriais. ou agrícola. Em outras palavras, é importante o suficiente para trazer algum tipo de solução principal.”
Greg mais tarde brincou: “Então o hardware está tentando confiar no software para evitar a destruição do mesmo hardware? Certamente os designers de hardware não são tão loucos, certo? (pergunta retórica, eu sei…)”.
Também foi levantado porque tal funcionalidade não poderia ser implementada no espaço do usuário, entre outras ideias. Aqueles interessados ??em alguma leitura divertida da lista de discussão do kernel Linux no fim de semana podem ver este tópico da lista de discussão do kernel.
Até agora há opiniões muito divergentes sobre esta abordagem e resta saber nesta fase se pode ser concebida uma solução apropriada que seja aceitável para a linha principal, ao mesmo tempo que se adapta às necessidades do sector automóvel e, mais amplamente, do espaço incorporado/industrial.
