Infelizmente não vou ver nada sobre isso na faculdade, pois o curso que estou fazendo é de tecnologia e não tem muito sobre softwares de sistema no currículo.

Vou ter que aprender sozinho.

De vez em quando, ao longo deste ano, eu faço uma pesquisa sobre os livros disponíveis. Qualquer aluno de computação sabe (ou deveria saber) que o livro do dragão é a referência sobre compiladores. Eu dei uma passada rápida em alguns capítulos e gostei do livro, o único problema é que eu gostaria de algo mais prático.

Eu achei o Crafting a Compiler with C. Este parece ter uma abordagem muito mais prática. Acho que vou começar com ele, quando quiser me aprofundar na teoria compro o livro do dragão.

O problema agora é tempo. Só vou ter tempo de mexer com isso quando terminar a faculdade. Se tudo ocorrer bem isso deve acontecer no final do primeiro semestre de 2009.

Para você ter uma idéia de como essa vontade me persegue: no começo do ano estava conversando sobre isso com o Paulo (aka pcpa, se você nunca ouviu falar nele basta dizer que ele é o autor do driver vesa do X, e já escreveu um interpretador LISP, é um dos hackers que conheço pessoalmente que mais admiro) ele disse que também tinha interesse no assunto e que estava escrevendo uma máquina virtual. A descrição da máquina dele me empolgou.

Nessa época eu estava lendo o Inside the Machine e bem no começo do livro o autor apresenta uma descrição de uma máquina extremamente simples que não tem nenhuma utilidade prática, a não ser ser discutida num livro de introdução a arquitetura de computadores.

Não teve jeito… Fiz o projetinho da máquina virtual e escrevi um assembler para ela ‘na loca’ (ie, sair escrevendo código sem pensar muito e sem ter embasamento teórico sobre o assunto). O código está aqui. Embora o assembler tenha funcionado eu nunca cheguei a implementar a maquininha virtual…

Eu dei o celular como morto logo de cara (não gosto de celulares). Alguém sugeriu usar um secador, mas não temos. Minha esposa abriu o celular todo, secou e limpou tudo o que foi possível. No domingo de manhã ela montou, ligou e o bicho renasceu. Um a zero para o celular.

O outro acontecimento interessante foi que o boto emprestou a máquina dele para usarmos no final de semana. Domingo à noite, minha esposa foi tentar apagar algumas fotos para abrir espaço e acabou apagando tudo. Ok, eu havia copiado as fotos de sábado, mas todos ficaram tristes achando que as fotos de domingo tinham ido para o céu dos bits.

Tentei googlar por algum programa para recuperar as fotos mas só encontrei para Windows (não tenho Windows em casa, e no wine não funcionou). Cansei de procurar. Pensei em escrever um programa para abrir o dispositivo do cartão de memória e dumpar tudo o que se parecesse com uma foto. Funcionou para grande parte das fotos (código aqui). Falei sobre isso com o pessoal do trabalho e o Caio sugeriu o Photorec, este recuperou 100%.

Pelo menos o programinha serviu para minha esposa ir dormir feliz, bom pra mim. :P

Toda vez que pego um programa para ler ou começo um novo projeto…

“Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowchart; it’ll be obvious.”

Tenho que lembrar que a parte fundamental…

“Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowchart; it’ll be obvious.”

De qualquer programa de computador são…

“Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowchart; it’ll be obvious.”

Os dados que esse programa manipula. Isso significa que se eu…

“Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowchart; it’ll be obvious.”

Focar nas estruturas de dados ao invés de…

“Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowchart; it’ll be obvious.”

Sair escrevendo ou lendo código…

“Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowchart; it’ll be obvious.”

Provavelmente terei mais sucesso, isto é…

“Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowchart; it’ll be obvious.”

Entenderei os programas de outras pessoas mais rapidamente e…

“Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowchart; it’ll be obvious.”

Meus programas terão mais qualidade!

O truque de scanf() permite ler strings com espaços. Por exemplo, se você fizer:

scanf("%s", line);

E digitar “foo bar”, scanf() vai ler apenas “foo” em line. Mas se você fizer:

scanf("%[^\n]s", line);

Aí sim, scanf() vai ler “foo bar” em line. Não sei se tem jeito mais fácil e estou com preguiça de ler toda documentação (ah, não esqueça que a maneira recomendada de ler strings é com fgets()).

O que me impressionou mais, no entanto, foi o truque de printf(): você pode passar a quantidade de caracteres a ser impresso por paramêtro, por exemplo:

printf("%.*s\n", 2, line);

Vai imprimir apenas os dois primeiros caracters de line, pois %.*s significa “pegue a quantidade de caracteres a ser impresso no próximo parâmetro”, que neste exemplo é 2.

Resta confirmar se tudo isso faz parte do padrão, mas pelo que diz a documentação creio que faz.

Se você respondeu sim pelo menos uma vez, recomendo fortemente ler este artigo.

Um dos materias que está disponível é do curso de engenharia de sistemas operacionais, do departamento de engenharia elétrica e ciência da computação.

A proposta é escrever um sistema operacional pequeno, baseado em exokernel, durante o semestre. O curso é dividido em seis laboratórios e aulas teóricas.

As aulas teóricas não são muito úteis para quem faz o curso a distância, o filé são as aulas de laboratório.

Funciona assim: cada aula de laboratório é composta de um arquivo pdf e código. O arquivo pdf tem um pouco de teoria, explica o que o código faz e tem exercícios. Em sua maioria os exercícios são de modificação e implementação das partes do sistema que estão faltando. As aulas são incrementais.

E não é só isso!

Para saber se as soluções dos exercícios estão corretas, cada laboratório disponibiliza um script que verifica a implementação. Além disso alguns laboratórios também tem o que poderíamos chamar de suite de testes (em modo kernel mesmo).

É um curso prático, que foca no que é importante. Não há como terminar o curso sem aprender o que foi proposto (eu agarântio!).

Fiz um pouco mais da metade – diga-se de passagem que a primeira metade é a mais importante e mais difícil – minha versão do SO está aqui:

http://repo.or.cz/w/mit-so-course.git

Para clonar faça:

$ git clone git://repo.or.cz/mit-so-course.git

Uma maneira simples é usar o fsfuzz.

Basicamente, é só construir o binário e executar ‘mkdir /media && ./fsfuzz’ como root. Mas você vai ter que conhecer um pouco sobre kernel para saber fazer o bug report corretamente e ATENÇÃO: você pode peder seus dados.

O fsfuzz é composto de um programa em C e três scripts em bash, ele funciona assim:

1. Um sistema de arquivos é criado em um arquivo
2. Esse arquivo é aberto e bytes randômicos são escritos de maneira aleatória
3. O arquivo (agora contendo um sistema de arquivos provavelmente corrompido) é montado no dispositivo de loop e alguns testes simples, como criação e remoção de arquivos, são executados

No pior caso o sistema de arquivos sendo testado vai explodir, mas outros erros não esperados são possíveis. Alguns bugs já descobertos podem ser encontrados aqui e aqui.

Se o script principal (fsfuzz) for executado sem argumentos, os testes rodarão para os sistemas de arquivos ext3, ext2, cramfs e swap (este último tem testes diferentes, claro) se as ferramentas para manipulação dos mesmos estiverem disponíveis em seu sistema. Mas você também pode especificar um sistema de arquivos na linha de comando. Leia o README para mais informações.

O principal componente do fsfuzz é um programinha em C, chamado mangle. Ele é o responsável por executar o passo número 2 na explicação acima e faz exatamente isto: abre um arquivo e espalha bytes randômicos nele.

Por padrão os bytes randômicos são escritos nos primeiros 1K bytes do arquivo (onde costumam residir cabeçalhos em arquivos binários) mas isso é configurável através de opções de linha de comando. Você pode até especificar um offset, que determina onde o mangle deve começar a escrever.

O mangle também pode ser usado em outras áreas do kernel. Por exemplo, você pode rodá-lo em um binário e depois tentar executá-lo (isso irá testar o código que carrega o binário).

E não é só isso!

Como você provavelmente já percebeu, o mangle pode ser usado em qualquer programa que aceite um arquivo como entrada. O mplayer por exemplo, rode o mangle em um arquivo mp3 ou avi e tente rodá-lo. Que tal o arquivo de configuração do Apache? E o interpretador Python?

As possibilidades são muitas, e para programas em user-level o comportamento esperado é que eles identifiquem o problema e tomem alguma ação, como imprimir uma mensagem de erro e sair. Se o programa travar, ganhar uma falha de segmentação ou qualquer outro comportamento bizarro, guarde o arquivo que você usou para reproduzir o problema e reporte o bug para o mantenedor do programa.

Note que todos esses testes não estão restritos ao Linux. O mangle deve compilar em qualquer Unix (se houver problemas com mmap() é fácil escrever uma versão com lseek() e write()) e você também pode rodar o mangle em arquivos do Windows no Linux e depois tentar usá-los no Windows (eg, arquivos .doc e binários).

Muito bom, não? :-)

void *realloc(void *ptr, size_t size);

Se a nova alocação é feita com sucesso, realloc() retorna um ponteiro para a nova área de memória (a qual contêm os mesmos dados da área anterior). Caso contrário a chamada retorna NULL, e a área anterior não é liberada.

A pegadinha acontece quando se acredita que realloc() nunca irá falhar, ou quando o programador simplesmente desconhece que em caso de falha a área anterior ainda é válida. Exemplo:

char *buf;
size_t size;

...

buf = malloc(size);

...

buf = realloc(buf, size*2);

Se realloc() falhar, ‘buf’ recebe NULL e você perde o ponteiro para a área anterior, a qual foi alocada com malloc() e ainda é válida. Ou seja, o resultado é um memory leak de ’size’ bytes. O código correto seria:

char *buf, *p;
size_t size;

...

buf = malloc(size);

...

p = realloc(buf, size*2);
if (!p) {
/* error handling */
...
free(buf);
return;
}
buf = p;

Há programadores que não se importam em consertar bugs como esse, eles argumentam que as funções da família alloc() raramente falham.

Não caia nesse conto, pois você não pode prever em quais máquinas e sob quais condições seu programa vai rodar.

Programas robustos costumam reagir bem a situações adversas, ou ao menos falham quando se espera que isso ocorra. Os mal escritos falham aleatoriamente em situações não esperadas, e apresetam bugs difíceis de reproduzir.

Sempre escreva código correto e robusto, você e seus usuários só tem a ganhar.

2. Não faça releases frequêntes

3. Quando fizer uma release, não faça changelog

4. Quando fizer uma release, não envie e-mails de anúncio

5. Crie uma lista de discussão moderada para desenvolvedores (sendo que apenas você pode aprovar mensagens)

6. Não use nenhum sistema de bugtracking

7. Ignore bug reports

8. Demore para dar qualquer tipo de feedback, principalmente aprovação das mensagens da lista moderada e patches submetidos

9. Perca alguns patches e esqueça quem os enviou

10. Desapareça de vez em quando, e desconsidere tudo o que aconteceu quando você estava fora