2012/2/16 Dr Infoblock <[email protected]>:
> Acho que deixei as informações um tanto vagas por isso resolvi explicar
> melhor o que ocorreu comigo e minhas atualizações do kernel.
Eu entendi que tu pegou o .txz da current, extraiu o conteúdo ou
instalou o pacote direto e tentou usar. Ai não passou da reinstalação
do LILO na MBR ou partição de boot. :)
> Primeiramente, eu sempre compilo o kernel de forma a deixá-lo o mais "exuto"
> possível, e sem módulos, tudo built-in.
Colocar algumas coisas como controladoras de disco, sistemas de
arquivos e o que precisar para iniciar o rootfs sem ter de criar e
carregar um ramdisk é uma coisa, mas sair tirando as coisas só p/
ficar menor não me parece muito produtivo:
- Se um módulo não funciona direito, tu pode descarregar o módulo e
carregar denovo. No kernel estátito tu pode tentar fazer o
unbinding/binding do dispositivo no sysfs, mas provavelmente tem de
reiniciar. Num roteador, isso é tolerável; num desktop, não acho tão
tolerável assim.
- Fica muito mais difícil de controlar os parâmetros: Como que faz
para desligar um parâmetro quando o driver é estático? Agora não tenho
nada estático por perto, mas tem como escrever no /sys/module/<NOME DO
MODULO>/parameters/* de drivers estáticos?
- O ganho de performance é subjetivo, eu diria que é quase um mito. De
fato, tu pode conseguir um desempenho melhor/mais funcionalidade
usando módulos e forçando o descarregamento das coisas que tu não usa.
Quando quero economizar bateria, por exemplo, eu descarrego o som, a
placa de rede ou a rede sem fio (depende de qual eu estou usando),
bluetooth e até o cdrom; tu não consegue fazer isso se todas estas
coisas forem compiladas estaticamente.[0]
- Se tu não acompanha de perto o desenvolvimento tu pode desligar uma
opção aparentemente inútil mas que pode ser o que faz toda a diferença
em alguns cenários (ex. control groups e a responsividade em algumas
cargas, como de um desktop comum).
- O que não é usado, não é carregado, a menos que seja explicitamente
carregado. Na melhor das hipóteses tu economiza tempo de compilação (e
se tu compila tantas versões estáveis assim, já deveria ter uma
estrutura com um ccache, no mínimo).
OBS: Não quero dizer que é totalmente inútil compilar um kernel todo
estático, mas que acho desnecessário na grande maiora dos casos e que
a principal justificativa (i.e. "fica mais rápido") não tem muito
fundamento. Só porque o sistema inicia mais rápido não significa que
ele seja mais rápido. :)
> Sei exatamente o modelo de cada hardware do meu PC e procuro criar um kernel
> específico para ele, nada a mais nem nada a menos.
Há algum tempo o kernel tem opções para detectar o teu hardware e
criar uma configuração toda estática ou [quase] toda modular. São
"make allyesconfig" e "make allmodconfig", respectivamente.
Mas elas não são perfeitas. O "allmodconfig", por exemplo, vai pegar
só os módulos carregados. Se tu inicia em um sistema "pelado", ele não
vai compilar um monte de coisas.
O "make help" mostra outras opções, tem até uma para gerar
configurações aleatórias.
> Quando compilei a versão 3.2.1, apesar de ter selecionado no "menuconfig" o
> meu adaptador de rede cabeada (AR8152 v2.0 F.E.) ele não era reconhecido,
> mas até aí tudo bem porque eu nunca nem utilizei a rede cabeada, só wireless
> (AR9287 PCI-E) que funcionava perfeitamente na versão 3.2.1.
Se não for algo faltando no teu .config, provavelmente é uma
regressão. Se for uma regressão, tu tem que reportar o bug [1], a
coisa não se arruma sozinha. :)
> Mas, a partir da versão 3.2.2, algo acontecia de errado em relação ao TCP/IP
> na wireless citada, a interface era reconhecida, associava ao AP mas não
> trafegava dados do protocolo na interface, eu até podia ver através do
> tcpdump o tráfego da rede entre outras máquinas e o AP, mas qualquer coisa
> que eu tentasse receber ou enviar (ICMP ECHO, TCP SYN) simplesmente não
> fluia através da interface.
Eu dei uma olhada rápida no git log (git log v3.2.1^..v3.2.2) e não vi
muita coisa. Tu pode fazer um git bisect [2] para determinar de onde
vem o problema, mas deve ter uma entrada posterior que corrige, quem
sabe se ver o log da 3.2.1 até hoje não mostra algo...
OBS: Eu realmente não prestei muita atenção no log, só sai pesquisando
por palavras iniciando em "ath".
> Ontem baixei a versão 3.2.6 e compilei da mesma forma como havia compilado
> todos os anteriores, o mais "exuto" possível e totalmente built-in, nada
> modularizado. Para minha surpresa está tudo funcionando perfeitamente, então
> por enquanto permanecerei nesse kernel.
>
> Sou do tipo que compila quase toda nova versão stable que é lançada, pensei
> que deveria ser mais detalhado na explicação do que comigo ocorreu então aí
> está.
Se tu ainda não faz, considera usar o linux-stable.git do kernel.org
ao invés de fazer o download dos tarballs.
Aqui o repositório tem mais ou menos 1.1GB depois de um "git gc" e com
o repositório tudo fica muito mais fácil: tu alterna entre versões de
forma rápida ("git checkout v3.2.2"), pode sair fazendo bisect para
achar problemas entre uma versão e outra e quem sabe até preparar
algum patch. :)
No e-mail anterior tem a URL p/ o repositório, tu pode achar os links
no http://git.kernel.org/ também.
> E outra, minha curiosidade a respeito do kernel 3.2.2 que está no
> repositório current é a respeito dele ser "huge" e ter muita carga de código
> interno, gostaria de testar para comparar com a minha compilação e
> reconhecer algum possível erro que eu tenha cometido, mas compilei aqui
> manualmente por mais de 3 vezes cada versão e só essa (3.2.6) foi a única
> que na primeira compilação deu tudo certo e estou usando perfeitamente.
> Baixei para ler o ".config" do kernel do repositório para ler, mas enfim,
> estou aqui com o 3.2.6 funcionando bem, recomendo-o pois foi o que não
> apresentou nenhum problema comigo.
Eu nunca entendi direito como que o Patrick trabalha com o kernel do
Slackware, então isso que vou falar é ~75% achismo[3]:
Acho que a função do kernel "-huge" é oferecer um kernel que não
precisa de um ramdisk para montar o rootfs e iniciar o sistema.
Não faria muito sentido oferecer um kernel totalmente estático que
funcione num grupo de computadores tão diversificado como x86/x86_64,
imagina o tamanho que seria a imagem? Deve ser divertido esperar o
boot loader carregar centenas de MBs... :)
> Mais uma vez obrigado pela atenção e resposta.
0 - Pode fazer unbinding no sysfs, mas eu realmente não sei se isso é
possível em um driver estático.
1 -
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=REPORTING-BUGS;hb=HEAD
2 - http://kerneltrap.org/node/11753
3 - 74.27% das estatísticas são feitas de números inventados aleatóriamente.
--
GUS-BR - Grupo de Usuários de Slackware Brasil
http://www.slackwarebrasil.org/
http://groups.google.com/group/slack-users-br
Antes de perguntar:
http://www.istf.com.br/perguntas/
Para sair da lista envie um e-mail para:
[email protected]
