Que benefício eu pude ver ao compilar um kernel do Linux? Existe alguma eficiência que você pode criar personalizando-a para o seu hardware?
Que benefício eu pude ver ao compilar um kernel do Linux? Existe alguma eficiência que você pode criar personalizando-a para o seu hardware?
Respostas:
Na minha opinião, o único benefício que você realmente obtém ao compilar seu próprio kernel Linux é:
Você aprende como compilar seu próprio kernel Linux.
Não é algo que você precise fazer para obter mais velocidade / memória / xxx. É uma coisa valiosa a se fazer se esse é o estágio em que você se sente em seu desenvolvimento. Se você deseja ter uma compreensão mais profunda do que é essa coisa toda de "código aberto", sobre como e quais são as diferentes partes do kernel, experimente. Se você está apenas procurando acelerar o tempo de inicialização em 3 segundos, então ... qual é o objetivo ... compre um SSD. Se você estiver curioso, se quiser aprender, compilar seu próprio kernel é uma ótima idéia e você provavelmente obterá muito disso.
Dito isso, há 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:
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 exista. Embora você possa passar inúmeras horas desativando coisas que você não precisa e ajustando as coisas que são ajustáveis, o fato é que o kernel do linux já está muito bem ajustado (pela sua distribuição) para a maioria das situações dos usuários.
A maioria dos usuários não precisa compilar seu próprio kernel, sua distribuição fez esse trabalho por eles. Geralmente, as distribuições incluem um conjunto de patches para integrar com certas partes do modo como a distribuição funciona, backports de drivers de dispositivo e correções de versões mais recentes, mas não lançadas, do kernel ou recursos que eles são pioneiros com seus usuários.
Quando você compila seu próprio kernel, você tem algumas opções, pode compilar um kernel oficial Linus Torvalds, isso não inclui nenhum dos patches ou personalizações adicionados por sua distribuição (que podem ser bons ou ruins) ou você pode use sua ferramenta de reconstrução de distribuição para criar seu próprio kernel.
Os motivos pelos quais você pode querer reconstruir seu kernel incluem:
Muitos desenvolvedores o usam para criar também versões personalizadas do kernel para sistemas embarcados ou caixas de configuração onde eles precisam de drivers de dispositivo especiais ou desejam remover a funcionalidade que não precisam.
bisecting para encontrar onde um bug foi introduzido ...
A compilação do kernel permite incluir apenas as partes relevantes para o 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; no momento da 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 inserido diretamente no kernel. Não há razão para o seu kernel suportar 400 CPUs diferentes quando existe apenas um no computador ou para suportar mouses bluetooth se você não tiver um, é todo o espaço desperdiçado que você pode liberar
Não acredito que a resposta aceita aqui comece dizendo "Não é algo que você precise fazer para obter mais velocidade / memória / xxx, o que for".
Isso é totalmente falso. Rotineiramente, construo meus Kernels de forma personalizada para remover códigos desnecessários e incluir códigos de aprimoramento de desempenho relacionados principalmente ao hardware. Por exemplo, eu executo um hardware mais antigo e posso obter alguns ganhos de desempenho ativando drivers do Kernel raramente ativados, como o suporte ao chipset HPT36x, em alguns MoBos mais antigos que possuem esse recurso.
Outro exemplo, o BIG SMP no Slackware é o padrão e em um Dell 2800, por exemplo, consumirá uma pegada considerável para executar coisas como GFSD (não como um módulo do kernel) que, a propósito, também consome ticks de CPU por algo que eu não precisa. Da mesma forma, o NFSD e outros benefícios para agradar a todas as mentalidades, o que é bom se você está apenas tentando colocar um Linux em uma caixa e funcionando, mas se você se preocupa com "velocidade / memória / xxx qualquer que seja", essas coisas são importantes 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.
Aqui estão algumas situações em que a compilação de seu próprio kernel o beneficiará:
Um kernel com carregamento de módulo desativado é mais seguro. Isso exigirá que você selecione os módulos que você sabe que precisa e os inclua como parte do kernel, em vez de compilá-los como módulos.
Desabilitar o suporte para / dev / kmem ou atrapalhá-lo com a opção de compilador apropriada é uma boa coisa para segurança. Acho que a maioria das distros faz isso por padrão agora.
Prefiro não usar o initrd, quando possível. A personalização do seu kernel para o hardware inicializado elimina o initrd.
Às vezes, uma versão posterior do kernel terá os recursos que você precisa, mas isso é muito raro hoje. Lembro-me de quando comecei a usar o Debian, ele estava usando 2.4 kernels, mas eu precisava de um kernel 2.6 para suporte ao udev.
Desativar protocolos / opções de rede que você não precisa pode acelerar o desempenho do TCP / IP.
Desativar opções que você não precisa reduz o espaço de memória do kernel, o que é importante em ambientes com pouca RAM. Quando você está usando um sistema de 256 MB de RAM como roteador, isso ajuda.
Eu acho todos os dispositivos "tty" em / dev irritantes em sistemas em que geralmente apenas logon via serial ou ssh.
A compilação do seu próprio kernel permite que você participe do processo de desenvolvimento do kernel, seja algo simples, como fornecer IDs de dispositivo PCI / USB para um driver existente que possa fazer um dispositivo mais novo funcionar para você, para se envolver profundamente na briga do núcleo desenvolvimento de kernel.
Também permite testar kernels de desenvolvimento no seu hardware e fornecer feedback se você notar alguma regressão. Isso pode ser particularmente útil para você e outras pessoas se você tiver um hardware incomum. Se você esperar um kernel de distribuição, pode levar algum tempo até que as correções dos relatórios de problemas sejam filtradas para uma nova versão do kernel de distribuição.
Pessoalmente, também gosto de compilar meus próprios kernels para incluir suporte apenas ao hardware que tenho. Quando você executa o distro kernels e analisa a saída de lsmod(8), vê muitos módulos carregados para o hardware que 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 oculto entre o barulho; 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.
Eu respondo a segunda resposta de gabe. (Meu comentário é muito longo, estou postando como resposta).
A menos que você tenha um objetivo 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 é feito. Ao revisar metodicamente as opções, ver como elas interagem entre si para criar o sistema é uma ótima maneira de entender como o sistema funciona. É incrível o que você descobre ao tentar remover componentes que parecem não ter nenhum objetivo para as tarefas que você está tentando realizar.
Entretanto, esteja avisado - por que pular pela toca do coelho é sem dúvida emocionante, vai sugar mais noites e fins de semana do que você pensava ser possível!
No trabalho, usamos kernels enrolados manualmente para aplicar patches fora da árvore, como vserver e unionfs.
Em casa, estou compilando kernels rolados à mão para descobrir qual commit introduziu um bug que estou enfrentando. Quando terminar isso, provavelmente vou me ater a um kernel rolado manualmente até que o bug seja corrigido em minha distribuição (Debian), quando eu voltaria a rever os kernels deles.
Este tópico é antigo e ainda é válido hoje como era quando a pergunta foi feita!
A resposta é: Você compila o kernel Linux de sua escolha, de acordo com suas necessidades e requisitos.
Muitos cenários são válidos:
Você é um engenheiro e exige que sua construção atenda aos requisitos / demandas de desempenho e segurança do seu sistema, recompile para atender e / ou superar os critérios especificados.
Você é um usuário normal e possui um sistema antigo que deseja continuar o máximo de tempo possível, recompila para adicionar / remover componentes para manter o sistema antigo otimizado.
Você é um usuário normal com o hardware mais rápido mais recente e possui memória / RAM mais que suficiente. Não há necessidade de recompilar, mas você ainda pode, se estiver interessado em aprender um pouco mais sobre o seu sistema.
Você só quer ser um usuário comum da Microsoft e / ou Mac, não recompile e apenas siga as atualizações da sua distribuição upstream.
Mantenha os cenários chegando :-)
Ao contrário dos usuários de Mac / Windows, o que o Linux fornece é a escolha. A opção de facilitar ou otimizar o sistema de acordo com seus requisitos.
Para a maioria dos usos, os kernels genéricos são bons para praticamente qualquer hardware. Além disso, eles geralmente contêm patches específicos da distribuição (ed), portanto, compilar seu próprio kernel pode (pode) causar problemas.
O reson para compilar seu próprio kernel é:
Se eu não estivesse usando a distribuição baseada na fonte, não compilaria o kernel.
Outro caso além dos muitos mencionados aqui para ter kernels compilados personalizados é configurar ambientes especializados de inicialização de rede, onde o carregamento do módulo não é viável e você deve distribuir kernels totalmente funcionais para máquinas específicas para tarefas específicas.
Estou surpreso que ninguém tenha mencionado esse motivo para compilar um kernel personalizado:
porque você deseja usar um compilador C / c ++ diferente. O GCC é muito bom para compilar o kernel do linux. Mas existem compiladores muito 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 de primitivas de desempenho e a ferramenta vtune, ambas indispensáveis na produção de um kernel Linux de alto desempenho. Você só pode ir tão longe 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 Intel e as bibliotecas de desempenho É um pouco grande - download de 1,5 GB, mas isso dá uma idéia do que está tudo contido em um bom compilador.
O compilador C / C ++ da Intel está disponível gratuitamente para uso não comercial. Mas é mais fácil pesquisar na página de download do compilador Intel c ++ da licença não comercial que pesquisar no site da Intel. Normalmente, não uso o 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 séria!
What are the pros and cons of compiling your own kernel?Contras = não é fácil, muitas situações sem valor agregado. Prós = segurança, desempenho, se você souber o que está fazendo, dispositivos NAS, por exemplo, usando o linux para fazer com que algum hardware funcione e tenha recursos gráficos e de rede.