Como é que se enviar um patch potencial para o kernel do Linux?

Question

Temos algum software que contou com determinado comportamento de outro aplicativo ( muito comumente usado) que agora mudou, tornando a nossa atual viável implementação, mas abaixo do ideal.

Acreditamos que esta mudança pode ter afetado um número de outras aplicações, particularmente no desempenho arena de monitoramento, e temos encontrado uma solução que acreditamos que irá melhorar uma série de outros problemas potenciais.

Infelizmente, a dita solução é uma mudança kernel (relativamente simples, mas de alto impacto se enchê-lo para cima) e não temos experiência na apresentação de patches do kernel para revisão.

Alguém no SO realmente apresentou um patch (enquanto eu aprecio todas as respostas, eu suspeito que as melhores virão daqueles que já passaram pelo processo, mesmo sem sucesso)? Você já tinha aceite (quais são as chances de que Alan Cox et al trava cerca de SO)?

O que é o processo correto a seguir? Eu não tenho nenhuma intenção de enviar fora de um email para Linus desde que eu sei que ele tem um quadro de protetores que você deveria passar antes de chegar a ele. Como faço para descobrir quem é responsável por uma determinada seção do kernel.

Pode ser que eu estou sendo excessivamente otimista em pensar que alguém mundo o kernel nunca ouviu falar de pode contribuir, mas eu estaria interessado em descobrir.

---

EDIT com mais detalhes:

A mudança não é realmente um bug desempenho, mas uma melhoria (na minha opinião) para o processo de contabilidade entradas (atualmente), escrito quando um processo termina.

Websphere App Server (ah, IBM, abençoe seus coraçõezinhos) mudou o que ele faz; JVMs usado para sair regularmente para que suas entradas foram escritos e poderíamos usar isso para estorno. Agora ele deixa JVMs em torno de mentir por meses, ou seja, os dados não está disponível em tempo hábil, a menos que a força estava para baixo regularmente. De alguma forma eu não acho Grupo de Software da IBM estão indo para fixar o seu software para nós :-). Em qualquer caso, eu acredito que ele pode ser um recurso útil para ter para outros processos de longa duração.

Atualmente tipo 3 registros processo de contabilidade são escritos quando um processo sai, o que estamos vendo é um mecanismo para gravação tipo-N registra periodicamente enquanto um processo ainda está ativo dando os números desde a última gravação (ou início do processo se esta é a primeira vez). Chargeback ou aplicações de monitorização de desempenho poderia optar por utilizar os registos de tipo-3 (totalmente inalteradas) ou os registos de tipo-N intercalares. A solução atual que temos é para monitorar / proc / PID / stat para processos específicos, mas isso é um truque horrível, uma vez que não se integra bem com o processo de contabilidade real.

Ele não precisa ser frequentemente (que ficaria feliz com 24 horas), mas pode haver um impacto no desempenho desde o trabalho que é feito atualmente apenas na saída do processo () terá que ser feito ocasionalmente em troca de contexto processo. Linus et al pode não gosto dessa idéia, pois pode ser uma área de alto impacto do código (mesmo verificar se houve 24 horas desde a última gravação pode ser muito lenta para eles).

Ainda assim, obrigado por todas as respostas até agora, eu vou ver como eu ir. Dê-me um par de dias e eu vou aceitar a melhor resposta.

Answer 1

Antes de mais nada: concentrando-se sobre o relatório de bug desempenho, e fazê-lo direito (com benchmarks repetíveis), pelo menos, ajudá-lo a levar as pessoas a se preocupar com o problema. Também enviar o patch após testá-lo, mas cuidado que o seu grande remendo pode usar a abordagem errada, e que eles podem escrever um melhor. Ou que simplesmente pode ser grande, mas pode precisar de correções para ser aceito, que mesmo acontece com uber-caras. E não pense que a e-mail de alguém em particular, mas referem-se a LKML ou para o subsistema apropriado ML.

Eu sugiro que você leia todas as outras respostas e todo o material aplicável, antes de contactar os desenvolvedores do kernel; e ler a bibliografia de SubmittingPatches também. Eles podem ser dura se você fizer isso errado. O bate-papo KernelNewbies IRC é um bom lugar para você começar, porque eles são com certeza boas-vindas, mesmo que às vezes o ambiente pode ser muito novato-like (não tenho certeza, eu não estive lá muito).

Pode ser que eu estou sendo excessivamente otimista em pensar que alguém mundo o kernel nunca ouviu falar de pode contribuir, mas eu estaria interessado em descobrir.

Não é excessivamente otimista; não em si mesmo, pelo menos. Abstraindo de você (desde que eu não sei suas habilidades), o que é mais provável é que seu patch será aceite sem modificações, ou que ele é escrito de acordo com as competências adequadas. Mas, na verdade, se o patch é dirigida a uma comunidade menor, pode ser muito mais fácil.

De alguém com alguma experiência (ou seja, eu), antes de considerar a apresentação remendo, descrever o problema e por isso afeta outras aplicações. Considerações como "isso melhora o nosso desempenho", especialmente se você se qualifica (vagamente) como um vendedor, não terá recurso em desenvolvedores do kernel.

Especialmente, omita tais declarações:

tornando nosso atual viável implementação, mas abaixo do ideal.

porque isso irá comprar-lhe uma recomendação "corrigir o seu código" imediatamente pela maioria dos leitores.

Se o desempenho de um aplicativo existente (não escrito por você) é afetado, isso é diferente. Por exemplo, uma vez que Linus prontamente prestou atenção a fixação no desempenho do kernel para o código asneira, porque esse código era parte de marca, mesmo que ele estava orgulhoso do código que ele tinha escrito e do fato de que ele não precisa fazer essa correção exata. Ou seja, você precisa de uma aplicação que todo mundo se preocupa com, ou uma solução sem desvantagens. Então, coisas como:

comportamento de uma outra aplicação (muito utilizada)

é bom, desde que o seu uso desse aplicativo não é considerado razoável.

Finalmente, se você se refere ao código-fonte, eles provavelmente pedir para ver seção interessados ??- acho que para problemas de licença com o seu código, se é que existem, e resolver qualquer um deles de antemão se você quiser respondê-las rapidamente <. / p>

Aliás, este é um relato parcial da minha experiência lá: https://www.ohloh.net/accounts/Blaisorblade

Se você quiser, você pode contactar-me para ajudá-lo diretamente com a mail proposto, e me CC na discussão. Estou muito ocupado, mas eu poderia encontrar mais algum tempo: -).

Answer 2

Bem, você poderia tentar ler Documentação / SubmittingPatches na árvore fonte do kernel linux.

Answer 3

Em um projeto grande, a melhor maneira de obter um patch para a árvore principal é entrar em contato com a pessoa que está mantendo a parte específica do código. Então, olhar através do arquivo Linux MAINTAINERS para ver quem é formalmente o mantenedor do código' ve mudou e também no Linux kernel do SCM repositório para localizar os desenvolvedores que recentemente trabalharam na esse código. Para aumentar suas chances do patch ser aceita:

• garantir que o seu patch é fácil de entender e segue existente padrões de código e documentação,
• explicar claramente o que seus alcança remendo,
• enviar suas alterações, em formato apropriado (a saída de diff -up para Linux),
• Verifique se o patch pode ser limpa aplicada (e obras) sobre o mais recente software (Linux kernel) versão,
• incluem casos de testes que demonstram tanto o problema que você está dirigindo e como seu patch resolve-lo, e
• não incluem em troca o código irrelevantes (por exemplo, formatação).

Uma pequena correção para um bug conhecido é mais provável de ser incorporado em um projeto de grandes alterações no código que introduzem um novo recurso da utilidade marginal ou duvidosa. Em alguns casos, vale a pena para o primeiro arquivo de um relatório de bug através do banco de dados de rastreamento de problemas do projeto, e em seguida, enviar um patch que aborda a questão específica. Para decepção evitar, se você está pensando em fazer uma grande mudança, é melhor para discutir a mudança e sua implementação proposto com o mantenedor antes escrever o código.

Answer 4

Leia a documentação / SubmittingPatches, encontrar o MAINTAINER apropriado, e mais importante, descobrir onde toda a discussão é realmente acontecendo. Pode não estar na lista do kernel discussão em si, mas talvez em algum subsistema ML.

Em seguida, inscrever-se neste ML, e enviar o seu patch como RFC.

Eu não sei se seu patch é invasivo, mas tente dividi-lo em uma fila de mudança lógica, cada um com sua própria explicação.

Answer 5

Eu não tentei a apresentação de quaisquer patches de kernel mim mesmo, eo docs faltam neste área.

esta página parece que você pode apontar na direção certa.

Answer 6

No EDIT, a resposta poderia ser interessante como um exemplo de caso. Eu acho que sua exigência é totalmente razoável, mas você está certo de que mesmo um teste em troca de contexto pode ser muito caro. Mas desde que o kernel tem uma implementação timer, não vejo por que ele não pode ser usado para evitar isso. Então, na verdade, o que sugere um pedido de melhoria é a aposta mais segura. Eu estou surpreso que sugerindo para enviar um relatório de erro em vez de um patch foi tal um bom ajuste. Você também pode modificar o patch-se de usar temporizadores si mesmo se você gostaria de apresentá-lo, mas ainda estar pronto para discussão :-) Você pode até adicionar "temos uma correção local, mas ele adiciona alguns testes no contexto alternar caminho rápido, é por isso que o patch é anexado como referência, mas não deve ser aplicada". Girando para baixo o seu próprio código, se ele é conhecido por ser ruim, vai evitar comentários ásperos do patch.

A alternativa é executar alguns benchmarks e provar não há impacto, mas se temporizadores são viáveis ??que o código será rejeitada qualquer maneira, ou para tentar a solução temporizador-se (algo melhor pode existir). Encontre os benchmarks que eles usam para o programador do kernel; olhada nas "recentes" threads cerca de CFS Ingo (ou Kolivas'?) patch e levar os seus pontos de referência.

Sobre o suporte, os desenvolvedores do kernel vai se preocupam com "Websphere App Servidor" por si só, se ele faz coisas irracionais, nem mesmo os IBM-financiados. Mas, com meu conhecimento limitado das situações, fechando a JVM periodicamente não faz sentido, parece apenas uma forma de papel sobre algum vazamento de memória / instabilidade, de modo que o comportamento atual deve ser apoiada.