Qual é o benefício de compilar seu próprio kernel do Linux?

96

Qual benefício eu vejo ao compilar um kernel do Linux? Existe alguma eficiência que você poderia criar personalizando-o em seu hardware?

    
por jjclarkson 20.08.2010 / 17:11

12 respostas

69

Na minha opinião, o único benefício que você realmente obtém ao compilar seu próprio kernel Linux é:

Você aprende a compilar seu próprio kernel linux.

Não é algo que você precise fazer por mais velocidade / memória / xxx. É uma coisa valiosa se esse é o estágio em que você se sente em seu desenvolvimento. Se você quer ter uma compreensão mais profunda do que é toda essa coisa de "código aberto", sobre como e quais são as diferentes partes do kernel, então você deve tentar. Se você está apenas olhando para acelerar o tempo de inicialização em 3 segundos, então ... o que é o ponto ... vai comprar um ssd. Se você está curioso, se você quer aprender, então compilar seu próprio kernel é uma ótima idéia e você provavelmente obterá muito disso.

Com isso dito, existem algumas razões específicas em que seria apropriado compilar seu próprio kernel (como várias pessoas apontaram nas outras respostas). Geralmente, elas surgem de uma necessidade específica que você tem para um resultado específico, por exemplo:

  • Eu preciso que o sistema inicialize / execute em hardware com recursos limitados
  • Eu preciso testar um patch e fornecer feedback para os desenvolvedores
  • Preciso desativar algo que esteja causando um conflito
  • Eu preciso desenvolver o kernel do Linux
  • Eu preciso ativar o suporte para meu hardware não suportado
  • Preciso melhorar o desempenho de x porque estou atingindo os limites atuais do sistema (e sei o que estou fazendo)

A questão está em pensar que há algum benefício intrínseco em compilar seu próprio kernel quando tudo já está funcionando como deveria, e eu não acho que existe. Embora você possa gastar inúmeras horas desabilitando coisas que você não precisa e ajustando as coisas que são ajustáveis, o fato é que o kernel do linux já está bem ajustado (pela sua distribuição) para as situações do usuário mais . / p>     

por 20.08.2010 / 17:59
34

A maioria dos usuários não precisa compilar seu próprio kernel, sua distribuição fez esse trabalho para eles. Normalmente, as distribuições incluirão um conjunto de patches para integração com certas partes da maneira como a distribuição funciona, backports de drivers de dispositivos e correções de versões mais novas, mas não lançadas, do kernel ou recursos que são pioneiros com seus usuários.

Quando você compila seu próprio kernel, você tem algumas opções, você pode compilar um kernel oficial do Linus Torvalds, isto não incluirá nenhum dos patches ou customizações que foram adicionados pela sua distribuição (o que pode ser bom ou ruim) ou você pode usar sua ferramenta de reconstrução de distribuição para construir seu próprio kernel.

Os motivos pelos quais você pode querer reconstruir seu kernel incluem:

  • Corrigindo bugs ou adicionando um recurso específico a um sistema de produção, onde você não pode realmente arriscar a atualização do kernel inteiro para uma única correção ou duas.
  • Para experimentar um determinado driver de dispositivo ou um novo recurso
  • Para estender o kernel, trabalhe nele
  • testando alguns dos módulos ou recursos "Alpha".

Muitos desenvolvedores o usam para criar também versões personalizadas do kernel para sistemas embarcados ou caixas de programação onde eles precisam de drivers de dispositivos especiais, ou eles querem remover a funcionalidade que eles não precisam.

    
por 20.08.2010 / 18:51
28

Compilar o kernel você mesmo permite incluir apenas as partes relevantes ao seu computador, o que o torna menor e potencialmente mais rápido, especialmente no momento da inicialização. Os kernels genéricos precisam incluir suporte para o máximo de hardware possível; na inicialização, eles detectam qual hardware está conectado ao seu computador e carregam os módulos apropriados, mas leva tempo para fazer tudo isso e eles precisam carregar módulos dinâmicos, em vez de ter o código ativado diretamente no kernel. Não há razão para o seu kernel suportar 400 CPUs diferentes quando há apenas um no seu computador, ou para suportar mouses bluetooth se você não tiver um, é todo o espaço desperdiçado que você pode liberar

    
por 20.08.2010 / 17:31
23

Eu não posso acreditar que a resposta aceita aqui começa dizendo "Não é algo que você precisa fazer para mais velocidade / memória / xxx o que for."

Isso é totalmente falso. Costumo customizar meus Kernels para remover o código desnecessário e incluir código de aprimoramento de desempenho relacionado principalmente ao hardware. Por exemplo, eu corro alguns hardwares mais antigos e posso obter alguns ganhos de desempenho, habilitando drivers do Kernel raramente habilitados, como o suporte ao chipset HPT36x em alguns moBos mais antigos que possuem este built-in.

Outro exemplo, o BIG SMP sob o Slackware é o padrão e o Dell 2800, por exemplo, consome uma pegada considerável para rodar coisas como o GFSD (não como um módulo do kernel) que, também, consome tiques da CPU por algo que eu não preciso. Da mesma forma para o NFSD e outro catch-all para agradar a todas as mentalidades que é bom se você está apenas tentando obter um Linux em uma caixa e rodando, mas se você se importa com "velocidade / memória / xxx qualquer" então essas coisas importam e funcionam .

Todas as minhas caixas de produção são Kernels personalizados. Se eu estiver usando um hardware comum, como um hardware da série Dell (2800, 2850, 2900, etc ...), é simples copiar o arquivo .config do kernel para cada caixa e compilar o kernel e instalá-lo.

    
por 30.09.2010 / 16:50
13

Aqui estão algumas situações em que a compilação do seu próprio kernel irá beneficiá-lo:

  • Um kernel com carregamento de módulo desativado é mais seguro. Isso exigirá que você selecione os módulos que você sabe que precisa e inclua-os como parte do kernel, em vez de compilá-los como módulos.

  • Desabilitar o suporte para / dev / kmem ou desativá-lo com a opção de compilador apropriada é bom para a segurança. Acho que a maioria das distros faz isso por padrão agora.

  • Eu prefiro não usar o initrd quando possível. A personalização do seu kernel para o hardware que ele inicializa elimina o initrd.

  • Às vezes, uma versão posterior do kernel terá recursos de que você precisa, mas isso é muito raro hoje em dia. Eu me lembro quando comecei a usar o Debian, ele estava usando o kernel 2.4, mas eu precisava de um kernel 2.6 para suporte ao udev.

  • Desativar protocolos / opções de rede desnecessários pode acelerar o desempenho do TCP / IP.

  • Desativar as opções que você não precisa diminui o consumo de memória do kernel, o que é importante em ambientes com pouca memória RAM. Quando você está usando um sistema de 256MB de RAM como roteador, isso ajuda.

  • Eu acho todos os dispositivos "tty" em / dev irritantes em sistemas nos quais eu geralmente apenas efetuo login via serial ou ssh.

por 21.03.2011 / 05:40
7

A compilação do seu próprio kernel permite que você participe do processo de desenvolvimento do kernel, seja coisas simples, como fornecer IDs de dispositivos PCI / USB para um driver existente que possa fazer um dispositivo mais novo funcionar para você, briga do desenvolvimento do núcleo do núcleo.

Ele também permite que você teste kernels de desenvolvimento em seu hardware e forneça feedback caso perceba qualquer regressão. Isso pode ser particularmente útil para você e outros se você tiver um hardware incomum. Se você esperar por um kernel distro, pode levar algum tempo para correções de seus relatórios de problemas para filtrar em uma nova versão do kernel de distribuição.

Eu também pessoalmente gosto de compilar meus próprios kernels para incluir suporte apenas para o hardware que eu tenho. Quando você executa kernels de distribuição e olha a saída de lsmod(8) , você vê muitos módulos carregados para hardware que você não possui. Isso pode poluir a lista de módulos, / proc, / sys e seus logs, de modo que quando você estiver procurando por algo, ele possa ficar escondido entre o ruído; Você também não pode ter 100% de certeza de que esses módulos não estão contribuindo para um problema que você está tentando diagnosticar.

    
por 22.08.2010 / 11:03
6

Eu respondo segundo gabe. (meu comentário é muito longo, então estou postando como resposta).

A menos que você tenha um propósito altamente especializado (por exemplo, máquinas embarcadas, perfil de segurança estrito), não vejo nenhum benefício prático em compilar seu próprio kernel além de ver como ele é feito. Ao revisar metodicamente as opções, ver como elas interagem umas com as outras para criar o sistema é uma ótima maneira de entender como o sistema funciona. É incrível o que você descobre quando tenta remover componentes que parecem não ter nenhum propósito para as tarefas que você está tentando realizar.

Esteja avisado, no entanto - por que saltar na toca do coelho é, sem dúvida, emocionante, ele vai sugar mais noites e fins de semana do que você pensou ser possível!

    
por 20.08.2010 / 18:17
3

No trabalho, usamos kernels enrolados à mão para aplicar patches fora da árvore, como vserver e unionfs.

Em casa, estou compilando kernels enrolados a mão para descobrir qual commit introduziu um bug que estou experimentando. Uma vez que eu terminei isso, eu provavelmente vou ficar com um kernel enrolado a mão até que o bug seja corrigido na minha distribuição (Debian), no qual eu voltaria para os seus kernels novamente.

    
por 25.09.2010 / 00:27
1

Para a maioria dos usos, os kernels genéricos são bons para virtualmente qualquer hardware. Além disso, eles geralmente contêm patches específicos de distribuição (ed), portanto, compilar seu próprio kernel pode (pode) causar problemas.

O reson para compilar seu próprio kernel é:

  • Você está usando a distribuição baseada em código-fonte para que não haja um kernel 'genérico'
  • Você é desenvolvedor do kernel e desenvolve o kernel
  • Você deve personalizar o kernel, por exemplo, para dispositivos incorporados com disco rígido muito limitado
  • Algum driver não é compilado em (caso muito raro)
  • Você deseja aplicar o patch ao AND você sabe o que está fazendo
  • Você quer aprender como compilar o kernel

Se eu não estivesse usando distro baseada em fonte, eu não iria compilar o kernel.

    
por 22.08.2010 / 14:35
1

Outro caso além dos muitos mencionados aqui para ter kernels compilados customizados é a configuração de ambientes de inicialização de rede especializados onde o carregamento de módulos não é viável e você tem que distribuir kernels totalmente funcionais para máquinas específicas para tarefas específicas.

    
por 17.06.2011 / 23:07
0

Estou surpreso que ninguém tenha mencionado esse motivo para compilar um kernel personalizado:

porque você quer usar um compilador C / c ++ diferente. O GCC é muito bom para compilar o kernel do Linux. Mas existem compiladores vastamente superiores por aí! As otimizações do GCC estão um pouco atrás do compilador C / C ++ da Intel. E a Intel fornece as bibliotecas primitivas de desempenho e a ferramenta vtune, ambas indispensáveis na produção de um kernel Linux de alto desempenho. Você só pode chegar até aqui com o GCC e o G ++. Praticamente, não importa o que você faça, o resultado será limitado pelo compilador. Então, eu uso o compilador da Intel e as bibliotecas de desempenho. É um pouco grande - o download de 1,5 GB, mas isso dá uma idéia do que está contido em um bom compilador.

O compilador C / C ++ da Intel está disponível gratuitamente para uso não comercial. Mas é mais fácil para o Google a licença não comercial Intel c + + página de download do compilador que para pesquisar no site da Intel. Eu não costumo usar GCC / G + + para nada. E você não precisa ser um programador. Você acabou de definir seu ambiente e alterar duas linhas no arquivo make para apontar para o compilador da Intel.

Então você pode obter uma velocidade muito grande!

    
por 22.08.2015 / 02:19
-1

Se você deseja instalar o Linux em um hardware muito específico, digamos, mais exótico do que um DS , você terá que cruzar -compile seu próprio kernel.

    
por 26.09.2010 / 21:11