FERRAMENTAS LINUX: Linus Torvalds mostra seu novo lado educado enquanto aponta código de kernel ruim

domingo, 28 de outubro de 2018

Linus Torvalds mostra seu novo lado educado enquanto aponta código de kernel ruim




Confira !!



Quando Linus Torvalds anunciou no mês passado que iria tirar uma licença temporária para trabalhar em sua empatia e habilidades interpessoais, bem como a adoção do Código de Conduta do kernel Linux , alguns comentaristas da Internet acharam que isso levaria Linus a ser menos rigoroso sobre qualidade do código e seus padrões para aceitar novos códigos na árvore principal. Felizmente, ele já mostrou para o novo ciclo do Linux 4.20 ~ 5.0 ele não está relaxando seus padrões, mas está se comunicando melhor quando se trata de trazer problemas de codificação.

Hoje ele discordou do pedido de retirada da HID e da introdução do driver do controle de jogo BigBen  que foi introduzido: o desenvolvedor habilitou esse novo driver por padrão. Linus Torvalds sempre desaprovou os novos drivers aleatórios que estão habilitados por padrão no driver de configuração do kernel. ele ainda expressou sua opinião sobre a configuração de configuração padrão "Y" deste driver, mas o fez de uma maneira mais profissional do que ele fez no passado:
Nós * não * ativamos novos drivers aleatórios por padrão. E nós definitivamente não o fazemos quando são estranhos que a maioria das pessoas nunca ouviu falar.

No entanto, o novo driver "BigBen Interactive" que foi adicionado a essa janela de mesclagem fez exatamente isso.

Apenas não faça isso.

Sim, sim, todo desenvolvedor sempre acha que seu driver é tão especial e tão magicamente importante que deve ser ativado por padrão. Mas não. Quando temos milhares de drivers, não escolhemos aleatoriamente um novo driver para ser habilitado por padrão apenas porque algum desenvolvedor acha que é especial. Não é.

Então o

padrão! EXPERT

estava completamente errado em commit 256a90ed9e46 ("HID: hid-bigbenff: driver para o gamepad BigBen Interactive PS3OFMINIPAD"). Por favor, não faça coisas assim.

Em comparação, aqui está sua postagem de novembro passado sobre um problema semelhante:
Você adiciona novos drivers e os padroniza para "on".

ISSO É COMPLETAMENTE INACEITÁVEL.

Não sei por que tenho que dizer isso em todas as janelas de mesclagem, mas vamos fazer isso mais uma vez:

como desenvolvedor, você acha que _seu_ driver ou recurso é a coisa mais importante de todas, e você tem o hardware.

E QUASE NINGUÉM SE IMPORTA.

Leia e chore. A menos que seu hardware seja completamente onipresente, não deve ser padrão usar a configuração de todos.
...
Mas algo como CONFIG_DELL_SMBIOS com certeza não merece ser padrão. Nem mesmo se você tiver habilitado o WMI.

CADA ÚNICO "padrão" linha que foi adicionado por este ramo estava errado.

Pare de fazer isso. É uma violação grave das expectativas das pessoas. Quando eu faço "oldconfig", não quero um novo suporte de hardware aleatório.

Havia também outra situação hoje testando a paciência de Torvalds quando se tratava de um kernel oops, com o reformado Torvalds escrevendo :

No meu laptop estou recebendo uma falha de página do kernel com a árvore git atual, e estou tentando culpar cometer

9ee3e06610fd ("HID: i2c-hid: substituir descritores HID para certos dispositivos"),

mas isso é simplesmente porque é a única coisa que parece tocar nessa área específica nessa janela de mesclagem.

Ooops parece com isso:
...
é por isso que eu suspeito que o novo código i2c_hid_get_dmi_hid_report_desc_override ().

Eu acho * que o problema é que o i2c_hid_dmi_desc_override_table [] não é terminado por uma entrada NULL, e eu testarei isso em seguida.

O que me deixa muito * * insatisfeito com isso é que, se estou certo, acho que significa que o código não foi literalmente testado por ninguém que não tenha uma das entradas dessa lista.

Isso é comparado a Linus anteriormente em tais incidentes chamando o código de "porcaria não testada" e muitas vezes mensagens enganosas .

Até agora, parece que o breve retiro de Linus está valendo a pena em resolver problemas de qualidade de código - e não aceitar descaradamente novos códigos no kernel, como alguns temiam -, mas ao fazê-lo de maneira profissional comparada à sua forma anterior de se exclamar mais de letras maiúsculas e palavrões que com o tempo o colocaram em desacordo com alguns na comunidade do kernel do Linux.



Até a  próxima !1

Nenhum comentário:

Postar um comentário