Bristot’s Blog

A culpa para eu não ter postado mais é uma só: é muita tecnologia para uma pessoa só!
Nessa vida de acadêmico, profissional e hobbista estou tendo que lidar com coisas tanto em baixíssimo quanto altíssimo nível;
A começar pela vida acadêmica, este trimestre a cadeira é de sistemas distribuídos, o contexto é:

• comunicação com utilização de mensagens;
• protocolos e semânticas;
• tratamentos de erros, correções, tolerância a falhas;
• tempo distribuído, ordens causais, exclusão mútua distribuída;

A linguagem de programação definida pelo professor (define:professor - Alguém que não é legal você contrariar) é JAVA. Sabe já fui xiita quanto a isto, mas para algumas coisas o Java realmente é uma mão na roda, por exemplo, faziam 4 anos desde a última vez que eu fiz um programa com janelinhas, e com Java consegui fazer um programa demo em menos de meia hora.

Outro ponto é: Objetos remotos. O Trabalho deste trimestre é fazer uma implementação utilizando Corba, e com Java isto é legal é muito simples compartilhar um objeto remoto utilizando Java, e eu sinceramente não sei porque este protocolo junto com o RMI (que é mais fácil ainda) não são utilizados em larga escala.

Saindo um pouco da vida acadêmica, caio na minha vida profissional, ai entramos em um outro extremo. Ai o contexto é outro:

• kernel Linux, uCLibc, arm-linux-*
• ARM, Atmel, TI
• C e asm
• NandFlash, Dataflash, EEPROM
• 32MB, 4KB, 99Mhz…

E esta é a minha praia, eu sinceramente, sem brincadeira, fico feliz com os problemas que me aparecem lá, os últimos que me vem a cabeça…

• fazer o suporte da INFERNO PACK para o u-boot mainline;
• um patch com os drivers do INFERNO PACK para o kernel mainline e resolver os pepinos da integração deste com o PREMPT_RT;
• resolver um problema da implementação de mutex na linuxthreads da uCLibc;
• por o 2.6.33.5-rt + buildroot-2010.05 + um monte de aplicação em 3.5MB de dataflash;
• provar para o pessoal do outro lado do barramento que a latência não é no Linux (eu adoro este);

Mas ultimamente um problema legal que tenho trabalhado é o fato do processador Atmel at91sam9g20 não conseguir ler a uma NAND Samsung de 512 mbit, faz mais de um mês que estou discutindo com a Atmel que o problema é a ROMBOOT do processador. O legal disto é que estou tendo bastante contato com o drivers/mtd/ e o código do bootstrap do processador.

Por fim, o lado hobbista… aaa, este é uma coisa só: kernel Linux/Tempo real. Pra quem não sabe, minha proposta de palestra para a LinuxCon foi aceita, em breve publicarei aqui o resumo dela e os slides. Mas bom, voltando ao assunto, ultimamente tenho lido bastante sobre tempo real, tanto teoricamente com o livro Real Time Systems quanto implementações no kernel Linux, como a implementação do HRT, DynTick, a proposta do escalonador EDF, alguns artigos sobre controle de admissão de processos de tempo real.

Enfim, como pode-se ver, meu tempo ultimamente tem passado desde registradores à objetos distribuídos… porém, pelo meu lado hobbista… tudo se resume na frase do Linus…

And yeah, I still think the hard-RT people are mostly crazy. — Linus;

#include 
#include 
#include 

/* based on code lighttpd:server.c source file */

void daemonize(void) {
        signal(SIGTTOU, SIG_IGN);
        signal(SIGTTIN, SIG_IGN);
        signal(SIGTSTP, SIG_IGN);
        if (0 != fork()) exit(0);

        if (-1 == setsid()) exit(0);

        signal(SIGHUP, SIG_IGN);

        if (0 != fork()) exit(0);

        if (0 != chdir("/")) exit(0);
}

int main(){

	int i;
        printf("Perhaps you want do something before go to background\n");
	scanf("%d", &i);

	daemonize();

	for (;;){
		sleep(10);
	}

}

Hoje fiquei realmente curioso ao ver o tópico cujo deu o nome a este post na página de desenvolvimento do kernel da LWN… Pensei, a canonical deve ter tomado vergonha na cara e posto alguém pra contribuir pro kernel… Bom, no primeiro paragrafo do texto:

“Canonical’s kernel manager, Pete Graner, spoke at UbuCon—held just prior to SCALE 8x—on the “Ubuntu Kernel Development Process”. In the talk, he looked at how Ubuntu decides what goes into the kernel and how that kernel gets built and tested. It provided an interesting look inside the process that results in a new kernel getting released for each new Ubuntu version, which comes along every six months.”

A Canonical não desenvolve um Linux, a canonical Configura um Linux… o que põe, na minha lista, o Ubuntu na junto ao DengueLinux, I(l)Linux, InsignificantRemasterForOldPcsLinux e demais distribuições que reinventam a roda…

Ai vocês ainda me perguntam porque não gosto da canonical e do ubuntu…

O Lançamento já foi a semana passada, mas só consegui achar um tempinho hoje…

Primeiro, dica para quem não conhece, o Kernel Newbies sempre faz um Changelog Human Readable de um release do kernel, o do .33 pode ser acessado em: http://kernelnewbies.org/Linux_2_6_33

Bom, Os drivers Nouveau, que são a novidade para os desktopinianos não são tão novidade assim, quem ja descompactou um srpm do kernel do Fedora iria ver uma penca de patchs do Nouveau… Para mim isto era um encomodo (ter o nouveau como patchs) isto porque a cada novo lançamento do patch RT eu tinha que fazer um merge entre o kernel vanilla + drivers nouveau + patch RT…
Não é de se espantar que estes drivers em grande parte sejam contribuição das Red Hat, e isto reforça mais ainda a minha opnião contrária as distribuições que só fazem uso das tecnologias Open Source… como o Ubuntu. Sinceramente, eu acompanho notícias diárias sobre Open Source e raramente vejo a Canonical ajudando algum projeto além de sí própria #Canonical = #Anti-OpenSource.

O DRBD Faz parte do kernel!!!!! Esta sim é uma ótima notícia. Me lembro de ter usado o DRBD em um cluster de alto desempenho, no cluster era feita a replicação de um sistema de arquivos em dois servidores HP DL350G5, estes servidores serviam imagens de instalação do sistema operacional na linha de produção de uma conhecida fábrica de computadores brasileira. Detalhe: Cada servidor possuia 9 (isto mesmo NOVE) interfaces de rede para poder dar a vasão necessária para as diversas máquinas fazendo donwload de imagem em paralelo. Na época fiquei com um pouco de receio de usar o DRBD, principalmente porque ele não era parte do kernel e sobre este eu rodava o sistema de arquivos GFS… Acho que esta feature vai alegrar muitos administradores de redes pelo mundo a fora.

Eu já havia lido este artigo sobre os SynCookies, Resumidamente, a idéia do SynCookie é tentar minimizar o consumo de recursos (principalmente memória) que um servidor precisa para armazenar os estados das conexões de redes, por exemplo, um ataque “SynFlood” distribuído pode causar um DDoS justamente pela falta de recursos no sistema operacional para manter o estado de toda estas novas conexões. Se você é um hacker de redes, aconselho a ler o aritigo.

Como eu não tenho nem um nintendo nem um game cube, não faz diferença se o Linux roda lá ou não hehehe… brincadeira

Para o mundo dos embarcados as boas notícias vem do mm, primeiro as páginas compartilhadas do KSM agora podem ir para o Swap, mas você deve estar se perguntando, com a baixíssima velocidade das memórias flash e o seu tempo de vida limitado pela quantidade de escrita, quem usa Swap em embarcados?

Com o compchache eu utilizaria. o Compcacge é uma das novas features do .33, com ele é possível criar um disco swap em ram (an? um disco de swap em RAM?) isto, só que as páginas do swap em RAM são compactadas, assim, provendo uma maneira de compactar as páginas menos utilizadas do embarcado, assim economizando ainda mais memória:

Imagine só, 10 executáveis compartilhando uma página que quando não utilizada fica em uma RAM compactada! Vou experimentar isto em um embarcado e postarei os resultados por aqui…

Além disto, os perfs foram portados para o ARM e por fim…

“Android removed from the Linux kernel”
Bom, com os acontecimentos dos últimos meses, cada dia levo-me a crer que o futuro dos celulares é usando o Linux puro, como no caso do Maemo, celulares da Motorola, o projeto do Linux da samsung que não me lembro o nome…
O Google pode ter um e-mail muito bom, um serviço de MAPS mara, mas com esta mania de dominar o mundo fazendo fork de tudo (como os Chrome*) acaba reinventado a roda, e em alguns casos se puxando para baixo pelos seu próprios cadarços…

Enfim! Seja bem vindo 2.6.33:

[daniel@darwin toolchain]$ uname -r
2.6.33-rt4

Nestas duas últimas semanas tenho tido bons trabalhos, o primeiro foi uma experiencia com Flash NAND e sistemas de arquivos para Flash. Nesta brincadeira fiz um “BacaSoftware” para formatar, escrever, ler, comparar flash e arquivos escritos direto na flash… ta, eu já sei que o mtd-utils faz isto, mas sabe… foi tao divertido… poxa deixa-me ser criança e brincar um pouco.

Sobre os sistemas de arquivos utilizei o UBIFS, e após muitas lidas na FAQ e um Patch fiz ele funcionar… O que valeu a pena, obtive mais de 30% de compactação dos arquivos na FLASH, isto utilizando o modo de compactação mais “performático”. Além disto gracas ao sistema de cache do sistema de arquivos as velocidades de leitura e gravação são muito boas, espero em breve fazer um melhor artigo sobre isto.

Outra coisa legal é que o patch RT para o 2.6.31.6 e o RT1 do 2.6.38-rc8 estão congelado em um kit de desenvolvimento ARM que utilizo… Depurando pude ver que isto acontece depois do asm_do_IRQ da interrupção do console serial. Em uma conversa no #linux-rt@OFTC o tglx me deu a dica de ser o terminal compartilhando o IRQ com o rtc, batata, era isto mesmo, a saída 1 seria trocar o IRQ do console para um diferente do utilizado pelo rtc… porém a AIC (advanced Interrupt controller) do embarcado não suporta isto… Bom, como não é novidade: Gostei estou lendo todo o código de tratamento de IRQ do Linux, tanto normal quanto + rt… ainda a procura da solução…

Semana passada vi um artigo que falava sobre o formato de compactação do kernel disponível no kernel.org, isto porque com o relativamente novo LZMA pode-se obter uma considerável melhora na compressão do Kernel, em uma comparação dos formatos de compactação, o Kernel 3.6.32 obteve os seguintes tamanhos compactados:
GZ: 79MB
BZ2: 62MB
LZMA: 53MB

Claro que nem tudo é baunilha (estou no shopping e na minha frente tem um monte de televisores a venda, passando uma receita de como fazer um sorvete de baunilha, acho que isto eh uma mensagem subliminar da sorveteria)…

Devido a relativa pequena idade do LZMA, muitas distribuições mais antigas mas ainda utilizadas como o RHEL3 ainda não possuem ferramentas capazes de comprimir/descomprimir arquivos xz (extensão dos arquivos compactados com LZMA)… Para os embarcados: o Busybox já possui a um bom tempo o suporte a descompressão LZMA.

Acho que a melhor noticia recebi via twitter este ano foi na segunda de carnaval, onde a Sula exclamou:

“Intel and Nokia joining forces on software - Moblin + Maemo = MeeGo.com . Check it out!”

Bom, todo mundo já sabe o que eh isto, mas se me perguntarem o que eu acho disto…

Isto ameaçá o reinado da Red Hat…

Você deve estar dizendo: achei que ele ia falar do Android… e se perguntando: O que a Red Hat tem a ver com isto?

Semana passada saiu uma noticia com “Quem escreve o kernel”, e em um belo gráfico (exibido abaixo) mostra que a Red Hat reina a bastante tempo, porem juntas a Intel (2 colocada) e a Nokia (5 colocada … superando a Novell… você deve ter se impressionado) ultrapassam a Red Hat!!! Claro, esta é uma rivalidade boa (-: onde todos ganham… espero um dia poder ajudar a Red Hat a se manter no topo (-: #redhatmecontrata

Foi lançado uma nova versão do BusyBox (unstable): BusyBox 1.16.0. Esta nova versão trás um conjunto de novas ferramentas bastante interessantes como:

• lspci
• lsusb
• flashcp
• mkfs.reiser
• mkfs_ext2
• ntpd
• traceroute6
• tune2fs
• wall

Por exemplo, com isto duas das aplicações que compilava externamente caíram fora dos meus embarcados: usbutils (que provia o lsusb) e o ntpd… Boa notícia (-:

int
main (int argc, char **argv){

	union {
		short s;
		char c[sizeof(short)];
	} un;

	un.s = 0x0102;

	if (sizeof(short) == 2){
		if (un.c[0] == 1 && un.c[1] == 2)
			printf("big-endian\n");
		else if (un.c[0] == 2 && un.c[1] == 1)
			printf("little-endian\n");
		else
			printf("Eu não entendi o que ele falou \n");
	}
	else
		printf("sizeof(short)==%d\n",sizeof(short));
}

Queridos ouvintes do Eu não sou NERD! FM…

Ontem entreguei a última versão do meu TCC, e com isto, aqui publico o texto do meu trabalho, a apresentação e o artigo científico.

Passei