Confira !!
Con Kolivas, desenvolvedor de kernel independente de longa data, conhecido por seu trabalho anteriormente no agendador BFS e agora no agendador MuQSS , bem como seu conjunto de patches "-ck" fora da árvore, está se tornando cada vez mais preocupado com o tamanho crescente da base de código do kernel e que, em última análise, poderia encerrar seu trabalho com foco em maior interatividade / desempenho de desktop.
Kolivas parou de contribuir com o kernel Linux principal há uma década, mas continuou mantendo o patch set "-ck" para cada nova versão do kernel, além de trabalhar em programas como Brain Fuck Scheduler e Multiple Queue Skiplist Scheduler. Geralmente ele tem sido bastante pontual ao refazer o trabalho de novos lançamentos de kernel, exceto quando o anestesista aposentado fez uma pausa no início deste ano para projetar equipamentos para a batalha COVID-19 . Mas agora sua última batalha é o tamanho crescente do kernel do Linux, que geralmente traz mudanças na infraestrutura central, em vez de apenas novos drivers.
Com o Linux 5.8 sendo um dos maiores lançamentos de todos os tempos , ele aproveitou a oportunidade para explicar por que seus patches MuQSS / CK ainda precisam ser refeitos. Kolivas observou, "É justo dizer que minha motivação para acompanhar o desenvolvimento do kernel do linux está diminuindo há algum tempo e a situação mundial atual não está ajudando. Ouvir as notícias exaltam as virtudes do linux-5.8 sendo o "maior lançamento de todos os tempos" não ajuda particularmente minha situação. Se fosse apenas uma queda massiva de novos drivers, eu poderia entender isso, mas geralmente significa apenas mais reescritas da infraestrutura principal dentro do kernel na busca de "torná-la melhor". Pessoalmente, não acho isso tão bom, mas é melhor deixar esse debate para outro lugar. "
Por enquanto, pelo menos, ele planeja continuar a basear seus patches de kernel em novas versões, embora não tenha certeza de nenhum cronograma. Ele também explicou suas maiores preocupações em todo o trabalho em seu código fora da árvore,Minha maior preocupação com a rotatividade massiva é que eu estrague algo de uma forma que deixe os usuários do meu código abertos a problemas de segurança ou corrupção fatal de dados em algum estágio, porque não fui cuidadoso o suficiente para me proteger contra isso. Por esta razão, eu sempre considerei abandonar o código inteiramente, mas alguns indivíduos de apoio declararam que encontram conforto na estabilidade relativa e na utilidade contínua do código do MuQSS no mundo cada vez mais volátil do churn do kernel, que é reconfortante e encorajador o suficiente para que eu pelo menos planeje para ficar em sincronia. "
Com a complexidade crescente e os novos recursos introduzidos, o MuQSS pode perder a relevância ou a viabilidade de mantê-lo."Conforme o tempo passa e mais e mais recursos são adicionados ao agendador que não têm nada a ver com o uso comum de desktop e plataforma móvel, em alguns estágios as distribuições serão tentadas a se tornar dependentes de um ou mais desses recursos e se eu não desenvolver MuQSS muito mais para incorporar minha própria versão desses recursos, ele se tornará redundante. Dada a arquitetura de agendador completamente diferente de MuQSS versus CFS, não posso simplesmente transportar o código na maior parte do tempo; Eu tenho que escrever minha própria versão equivalente de recursos completa e estes estão longe de ser triviais. O código de contabilidade é completamente diferente, a maioria dos recursos do CGROUP nem mesmo foram implementados e o agendamento de prazos não está disponível, por exemplo. Se mais desses aparecerem no futuro e eventualmente se tornarem empecilhos,"
Mais detalhes no blog do CK .
Fonte
Até a próxima !
Nenhum comentário:
Postar um comentário