Planet ccppbrasil.org

Resenha: Embedded Software The Works

2010-09-01T11:00:05+00:00

Terminei recentemente a leitura do Livro “Embedded Software The Works”, escrito por Colin Walls, experiente engenheiro e um dos pioneiros da indústria de sistemas embarcados, que trabalha atualmente na Mentor Graphics. O livro é uma coletânea de vários artigos, separados por temas de interesse em 9 capítulos.

A linguagem utilizada é simples, e apesar de manter certa ordem de apresentação do conteúdo, você não precisa ler na ordem apresentada. Alguns artigos, que foram escritos na década de 90, estão um pouco defasados, mas no geral é um livro que vale a pena pelo menos dar uma olhada em alguns capítulos, que são bem interessantes.

O capítulo 1 apresenta uma introdução à sistemas embarcados e sua evolução durante os últimos 30 anos, falando sobre memória, arquitetura de CPUs e seu processo de seleção, além de dois artigos bem interessantes sobre a interface USB. O capítulo 2 é sobre design de sistemas embarcados, abrangendo tópicos como UML e Eclipse.

Os capítulos 3, 4 e 5 são inteiramente voltados ao desenvolvimento de software embarcado em C e C++, com algumas dicas valiosas principalmente para quem está começando na área. Os capítulos 6 e 7 também são bem interessantes, discutindo tópicos relacionados à sistemas de tempo real. Os dois últimos capítulos falam sobre protocolos de rede e FPGAs.

O site do livro é este aqui, e quem se interessar pode dar uma folheada no Google Books. Vale a pena também acompanhar o The Colin Walls Blog.

Um abraço!

Sergio Prado

Posts relacionados:

Por que goto é considerado prejudicial?

2010-08-30T15:37:19+00:00

Recentemente, o Fabiano Vasconcelos abriu uma discussão no Grupo de Usuários de C e C++:

De cara eu vi algo aqui um pouco estranho, se que o amigo Márcio me permite comentar: que muitos programadores, inclusive eu (se que posso ser rotulado como programador) foram instruídos com o princípio de NUNCA usar o goto, por ser considerado um mau estilo de programação.

Durante a discussão, o Eduardo Vieira puxou um artigo da KernelTrap sobre uma discussão similar ocorrida no grupo de desenvolvimento do Linux, onde Robert Wilken disse o seguinte:

In general, if you can structure your code properly, you should never need a goto, and if you don't need a goto you shouldn't use it. It's just "common sense" as I've always been taught. Unless you're intentionally trying to write code that's harder for others to read.

É preciso colocar a máxima "goto considered harmful" na perspectiva histórica adequada.

Acredito que praticamente todo programador treinado nos últimos vinte anos aprendeu a programar com if e while. Essas são as estruturas básicas de programas e aparecem rapidamente nos manuais e nos cursos de programação. Toda linguagem de programação moderna tem if e while, e variantes como switch, for etc.

Essas coisas são chamadas estruturas de controle porque fazem exatamente isso: controlam a execução do programa, às vezes indo para uma sequência de sentenças, às vezes indo para outra, de acordo com testes explícitos. Arranjar um programa com sequências de sentenças, if e while é fazer programação estruturada.

Agora, a não ser que algum curso maravilhoso e desconhecido por mim tenha história da programação no seu currículo, este programador provavelmente não percebe que if e while nem sempre existiram e que a programação estruturada foi inventada mais ou menos na década de 70.

Durante a discussão no grupo de desenvolvimento do Linux, Scott Robert Ladd disse o seguinte:

Your attitude against "goto" is perhaps based upon an excellent but dated article, "Goto Considered Harmful", written by Edsger W. Dijkstra, and published by the ACM in 1968. (A recent reprint can be found at http://www.acm.org/classics/oct95/.) As you can tell from the date, this article predates modern programming languages and idioms; it comes from a time when Fortran ruled, and before Fortran 77 provided significant tools for avoiding spaghetti code.

e mais o seguinte:

Used over short distances with well-documented labels, a "goto" can be more effective, faster, and cleaner than a series of complex flags or other constructs. The "goto" may also be safer and more intuitive than the alternative. A "break" is a goto; a "continue" is a "goto" -- these are statements that move the point of execution explicitly.

Dijkstra, e outros, iniciaram a pequena revolta estruturada e assim ocorreu que diversas linguagens de programação introduziram novidades como if e while. Mas como é possível programar sem if e while?

Considere este fragmento:

char * i = input;
while (*i != '\0')
if (*i == SPECIAL) goto exit;
else ++i;
:exit
return i;

Este fragmento _não_ é o objeto da objeção ao uso de goto. Este fragmento exibe honrada programação estruturada. goto está ali como bem poderia estar break. Tanto faz.

Agora, observe este fragmento:

char * i = input;
:loop
if (*i == '\0') goto exit;
if (*i == SPECIAL) goto exit;
++i;
goto loop;
:exit
return i;

Isto é o que você deve evitar.

O objetivo do combate ao goto era combater a programação não-estruturada, e esse combate foi vencido com a introdução das linguagens estruturadas. Tais linguagens levam o programador naturalmente ao caminho certo e proíbem os maiores absurdos.

Existem linguagens em que o último fragmento acima era _a única alternativa_. (Ou coisa pior.)

Em retrospectiva, sabemos que a programação não-estruturada dominante na época causava um modo de pensar não-estruturado sobre os programas, de modo que o "spagetthi code" clássico era um único fluxo de instruções com gotos arbitrários para cima e para baixo, algo muito pior que o último fragmento acima, o tipo de código que eu não saberia construir artificialmente.

Se você conhece e pratica a programação de acordo com os bons princípios da programação estruturada, não precisa temer o goto. Existem diversas situações excepcionais às quais as estruturas de controle do C não se adequam perfeitamente; aquela que me ocorre com mais frequência são switches dentro de for quando é preciso terminar o for dentro de um case.

for (char * i = input; *i != '\0'; ++i)
switch (state)
{
case FOO:
/* many things */
break;
case BAR:
if (*i == SPECIAL) goto exit;
/* many things */
break;
}
exit:

Sempre existe uma maneira de remover o goto; nem sempre essa maneira é desejável. O goto acima, cujo label está exatamente na saída do laço, me parece uma parte bastante adequada da estrutura de controle. Java, que não possui goto, permite dizer "break exit", com exatamente o mesmo significado.

Durante a discussão no grupo de desenvolvimento do Linux, Robert Love disse o seguinte sobre a substituição do goto por outras estruturas:

As a final argument, it does not let us cleanly do the usual stack-esque wind and unwind, i.e.

do A
if (error) goto out_a;
do B
if (error) goto out_b;
do C
if (error) goto out_c;
goto out;
out_c:
undo C
out_b:
undo B:
out_a:
undo A
out:
return ret;

Now stop this.

Mini2440 — Linux com U-Boot e Emdebian

2010-08-30T11:00:07+00:00

No último artigo vimos com mais detalhes a arquitetura do kit FriendlyARM mini2440 e o bootloader que vem instalado de fábrica. Quem ainda não leu este post, pode acessá-lo aqui.

Vamos agora colocar a mão na massa. Nosso objetivo aqui é carregar na flash NAND o bootloader U-Boot, bastante usado em sistemas embarcados, e depois fazê-lo carregar uma imagem do Emdebian, uma versão do Debian mais leve.

O único pré-requisito é um kit FriendlyARM mini2440 conectado à uma máquina Linux pela serial (para acessar a console), pela USB (para transferir a imagem do U-boot) e por um cabo de rede (para carregar as imagens do kernel e do rootfs do Emdebian).

Usei o binário do U-boot deste link aqui. O kernel eu baixei daqui, mas precisei customizá-lo para habilitar o suporte à sistema de arquivos JFFS2 e corrigir o mapeamento das partições da MTD no driver da Flash. O rootfs eu peguei aqui, mas também precisei "dar um tapa", e corrigir um problema que impedia de subir o terminal pela console RS232.

Para facilitar o trabalho daqueles que irão executar este passo-a-passo, criei um "pacote especial" com todas as ferramentas e imagens necessárias para dar vida ao Emdebian no mini2440. Este pacote pode ser baixado aqui. Descompacte-o para sua máquina e mãos à obra!

Bootloader U-Boot

O bootloader é uma aplicação que é carregada e executada assim que o hardware é ligado. No universo desktop, estamos familiarizados com o LILO ou o GRUB para carregar sistemas Unix-like, mas no universo embedded as coisas são um pouco mais complicadas. Um bootloader para sistemas embarcados possui 3 principais responsabilidades:

Inicializar o hardware.
Possibilitar a carga e gravação da aplicação na flash via alguma interface de I/O, como porta serial, USB ou interface de rede.
Carregar e executar aplicações da RAM.

Um bootloader bem conhecido no universo embedded é o Das U-Boot, também conhecido apenas como U-Boot, um bootloader multi-plataforma e open-source, com suporte à diversas arquiteturas como PowerPC, ARM, MIPS, Coldfire e x86. A página do projeto pode ser acessada aqui.

O U-Boot será o bootloader que utilizaremos para carregar o Emdebian pela NAND. O processo para carregar e gravar o U-Boot na flash é simples.

Primeiro iremos carregar a imagem do U-Boot na RAM. Para isso precisaremos da imagem do U-Boot ("u-boot-256M.bin" ou "u-boot-128M.bin", dependendo do seu kit), e da ferramenta "usbpush". Todos os arquivos encontram-se no link que passei no início deste post. Não esqueça também que a serial e a USB devem estar conectadas.

Inicie o kit pela NOR, no menu do supervivi selecione a opção "q" e prepare-o para receber a imagem do U-Boot e salvar em RAM:

[q] Goto shell of vivi
Enter your selection: q
Supervivi> load ram 0x31000000 242360 u

Obs: O parâmetro "242360" deve ser o tamanho em bytes da imagem do U-Boot ("u-boot-256M.bin" para a flash de 256M no meu caso).

Então, em um shell do Linux, digite o comando abaixo:

$ sudo ./usbpush u-boot-256M.bin

A console irá exibir uma mensagem indicando que a transferência foi realizada com sucesso.

Agora iremos executar o U-Boot da RAM mesmo, assim podemos formatar a NAND e depois copiar o U-Boot para lá.

Digite então na console do mini2440:

Supervivi> go 0x31000000

Após algumas mensagens, irá aparecer o shell do U-Boot. Agora vamos formatar a flash. A execução dos comandos abaixo podem demorar um pouco, portanto tenha paciência :)

MINI2440 # nand scrub
....
MINI2440 # nand createbbt
....

Depois é só escrever o U-Boot na flash Nand.

MINI2440 # nand write.e 0x31000000 0 242360

Obs: Não se esqueça de que novamente o parâmetro "242360" deve ser o tamanho em bytes da imagem do U-Boot.

Muito bem. Você acabou de instalar o U-Boot na sua flash NAND. Desligue a placa, mude a chave para bootar pela NAND para a console cair no shell do U-Boot.

Este bootloader tem bastante recursos. O comando "help" vai exibir uma lista. Podemos por exemplo listar informações da placa ou das partições da flash, conforme abaixo:

MINI2440 # bdinfo
arch_number = 0x000007CF
env_t       = 0x00000000
boot_params = 0x30000100
DRAM bank   = 0x00000000
-> start    = 0x30000000
-> size     = 0x04000000
ethaddr     = 08:08:11:18:12:27
ip_addr     = 10.0.0.111
baudrate    = 115200 bps
 
MINI2440 # mtdparts 
device nand0 <mini2440-nand>, # parts = 4
 #: name                size            offset          mask_flags
 0: u-boot              0x00040000      0x00000000      0
 1: env                 0x00020000      0x00040000      0
 2: kernel              0x00500000      0x00060000      0
 3: root                0x0faa0000      0x00560000      0
active partition: nand0,0 - (u-boot) 0x00040000 @ 0x00000000
</mini2440-nand>

Podemos carregar uma aplicação via serial com os comandos "loadb", "loads" e "loady", via NFS com o comando "nfs", via TFTP com o comando "tftpboot" ou via USB com o comando "usbboot". Podemos também testar a RAM com os comandos "mtest" e "mw".

Carregando o Emdebian

O Emdebian é uma versão do Debian para sistemas embarcados. Mantém as principais características do Debian, como sistema de gerenciamento de pacotes, sistema de licenças e portabilidade entre diversas plataformas. O sistema de build é customizado para trabalhar com pacotes pequenos e gerar distribuições bem mais leves. A página do projeto pode ser acessada aqui.

A carga do kernel ("uImage") e do rootfs ("emdebian-jffs2.img") é feita através de uma conexão de rede. Ligue seu PC com o mini2440 através de um cabo de rede, configure o endereço IP do seu PC com 10.0.0.1, e o do kit com 10.0.0.2. Configure o mini2440 através dos comandos abaixo na console do U-Boot:

MINI2440 # dynenv set 40000
MINI2440 # setenv ipaddr 10.0.0.2
MINI2440 # setenv serverip 10.0.0.1
MINI2440 # saveenv

Use o comando "ping 10.0.0.1" na console do U-Boot para verificar se a conexão com o PC está funcionando corretamente.

Vamos agora gravar o kernel. O processo consiste em carregar a imagem do kernel para a RAM, e então de lá gravar na flash:

MINI2440 # tftp 0x31000000 uImage
MINI2440 # nand erase kernel
MINI2440 # nand write.e 0x31000000 kernel 0x205f58

Para o rootfs, o processo é idêntico:

MINI2440 # tftp 0x31000000 emdebian-jffs2.img
MINI2440 # nand erase root 
MINI2440 # nand write.e 0x31000000 root 0x23e0000

Agora só falta setar as variáveis de ambiente do U-Boot para iniciar o kernel do Linux corretamente:

MINI2440 # setenv bootcmd nboot.e kernel ; bootm
MINI2440 # setenv bootargs root=/dev/mtdblock3 rootfstype=jffs2 console=ttySAC0,115200
MINI2440 # saveenv
MINI2440 # boot

Pronto! O Emdebian já está rodando no nosso kit mini2440:

Quando comecei a escrever este post, minha intenção original era carregar o Android, mas acabei "descobrindo" durante o processo que a quantidade de RAM do mini2440 (64M) não é suficiente para este SO. O que o pessoal acabou fazendo foi rodá-lo a partir de um cartão de memória SD usando um mecanismo de swap. Se isso funciona mesmo ou não, veremos no meu próximo post...:)

Um abraço!

Sergio Prado

Posts relacionados:

Leptoniando: Toda computação é sempre física

2010-08-25T17:46:11+00:00

Seja C, C++, Python, Java, Ruby ou Brainf*ck, independente de sua linguagem preferida, durante a análise léxica, sintática, semântica, geração do código executável ou em qualquer outra operação, na execução de programas, independente da arquitetura de run-time e dependência que ela tenha, seja instruções bare-metal ou dependente de algum sistema operacional, rodando na CPU de [...]

“Duvida basica de ponteiros de c”

2010-08-24T23:53:35+00:00

Então, essa é básica e ocorre aos montes quando estamos iniciando em C, segue abaixo uma discussão bem interessante entre os veteranos da cppbrasil. O bom da cppbrasil é que as respostas são ótimas, bem esclarecedoras. Eita comunidade pequena, mas organizada essa do C++. A dúvida abaixo é do “Diego Henrique Oliveira”: Galera, to com [...]

Beginner’s Guide to Linkers

2010-08-23T18:01:42+00:00

Beginner’s Guide to Linkers This article is intended to help C & C++ programmers understand the essentials of what the linker does. I’ve explained this to a number of colleagues over the years, so I decided it was time to write it down so that it’s more widely available (and so that I don’t have [...]

Mini2440 — Memory layout e bootloader

2010-08-17T16:13:13+00:00

Recentemente comprei o kit FriendlyARM Mini2440, e escrevi um post introdutório sobre ele aqui.

Minhas impressões iniciais são muito boas. Ele é possivelmente um dos melhores kits existentes (que conheço) para se aprender sobre Linux embarcado, por ser um hardware robusto, pelas ferramentas existentes e pela relação custo/benefício.

Vamos ver então com um pouco mais de detalhes a arquitetura da CPU, o layout de memória e o bootloader que vem instalado de fábrica.

CPU E O LAYOUT DE MEMÓRIA

O kit, com todas as suas interfaces de I/O e memória, pode ser visto na figura abaixo:

A CPU é um Samsung S3C2440 baseado no core ARM920T, RISC, arquitetura Harvard e voltado para aplicações de baixo consumo. O datasheet pode ser baixado aqui.

Tem capacidade de endereçamento de até 1GB, sendo 8 bancos de memória de 128M selecionáveis através de 8 chip select's (nGCS0...nGCS7).

A memória RAM de 64MB (2 x 32MB) está mapeada para o endereço físico 0x30000000 através do nGCS6.

Existem duas memórias de programa neste kit, o que acaba sendo um diferencial perante outros kits ARM voltados para aprendizado. O kit possui 2MB de memória flash do tipo NOR e 64MB de memória flash do tipo NAND.

Para quem não conhece, vale aqui uma explicação sobre as diferenças entre estes dois tipos de memória.

Ambas foram inventadas na década de 80 pela Toshiba. As primeiras memórias NOR foram vendidas pela Intel em 88. Com tempo de resposta para apagar e escrever muito grande, mas com a possibilidade de acesso à leitura em qualquer posição de memória, foi uma aplicação ideal para memórias do tipo ROM, para armazenar programas que dificilmente são alterados, como a BIOS de PCs e firmware de equipamentos eletrônicos.

Já as memórias do tipo NAND possui um tempo de escrita bem menor, e uma maior densidade, ou seja, mais MB de dados pelo mesmo espaço se comparados com as memórias NOR. Por outro lado, não é possível acesso de leitura à qualquer posição de memória. A leitura e gravação é feita por blocos de memória (4kB por exemplo). Isso dá a ela a aplicação ideal para armazenamento de dados. Quando usada como memória de programa, é necessário ter um bootloader que carrega seu conteúdo em memória RAM para ser executado.

O kit mini2440 consegue fazer o boot pelas duas memórias através de uma chave (NAND <-> NOR) no canto inferior direito da imagem acima.

Ao fazer o boot pela NAND, a CPU possui uma região especial chamada de "Boot internal SRAM", onde são carregados e executados os primeiros 4KB da NAND. Estes primeiros 4K de programa serão os responsáveis por carregar o resto do programa da NAND para a RAM, e rodar a aplicação a partir de lá.

Ao fazer o boot pela NOR, é carregado o bootloader Supervivi, que vêm instalado de fábrica. Ele é baseado no bootloader open source vivi da Samsung. Vamos dar uma olhada nele com mais detalhes.

BOOTLOADER SUPERVIVI

Para acessar o bootloader ligue os cabos RS323 e USB e deixe a chave de seleção de memória na posição NOR. Você pode usar qualquer aplicação para consoles como o HyperTerminal para Windows ou o minicom para Linux. Este é o menu inicial do bootloader Supervivi:

A opção "q" oferece um shell para o bootloader e as outras opções automatizam determinada tarefa.

Apesar da manipulação do bootloader ser pela console (porta serial), a transferência de arquivos é pela USB. Você vai precisar de uma aplicação adicional para transferir arquivos e imagens: DNW for Windows ou Usb-push for Linux. Nos nossos exemplos usaremos um PC com Linux, mas os procedimentos com Windows são similares, e mais informações podem ser encontradas no manual de usuário do kit aqui.

CARREGANDO UMA APLICAÇÃO STANDALONE

Para carregar uma aplicação standalone na flash NAND, basta usar a opção "a". Esta aplicação standalone pode ser qualquer binário pronto para execução. Pode ser uma simples aplicação para piscar leds ou uma aplicação mais completa com RTOS. Vamos carregar aqui o binário "myled.bin" na flash, que vem como exemplo junto com o kit:

Primeiro devemos preparar o bootloader para carregar o arquivo com a opção "a":

[a] Absolute User Application
Enter your selection: a
USB host is connected. Waiting a download.

Depois devemos disparar a transferência com a aplicação usb-push:

$ sudo ./usbpush /media/cdrom0/sample\ code\ without\ OS/myled.bin
csum = 0x83c6
send_file: addr = 0x30000000, len = 0x0000084c

O bootloader vai exibir o status da transferência:

Now, Downloading [ADDRESS:30000000h,TOTAL:2134]
RECEIVED FILE SIZE:    2134 (2KB/S, 1S)
Downloaded file at 0x30000000, size = 2124 bytes
Write to flash ok: skipped size = 0x0, size = 0x84c

Então é só mudar a chave para NAND e reiniciar o kit.

Vale aqui ressaltar um detalhe que já expliquei mais acima: como sua aplicação esta rodando pela NAND, o processador vai carregar os primeiros 4K para a SRAM interna e executar. Portanto, os primeiros 4K da sua aplicação deverá ter um código para copiar seu conteúdo para a RAM e então bootar a aplicação de lá.

CARREGANDO O LINUX

O bootloader divide a flash em 4 partições. Acesse o menu do bootloader com a opção "q" e digite o comando "part show"

Supervivi> part show
Number of partitions: 4
name            :       offset          size            flag
------------------------------------------------------------
vivi            :       0x00000000      0x00040000      0
param           :       0x00040000      0x00020000      0
kernel          :       0x00060000      0x00500000      0
root            :       0x00560000      0x3fa80000      0

Na primeira partição está o próprio bootloader da NAND, a segunda é uma região para armazenar parâmetros e variáveis usadas pelo bootloader, na terceira está o kernel e na quarta o rootfs.

Esta forma de trabalho facilita o desenvolvimento, porque você pode fazer alterações no rootfs sem ter que alterar o kernel, por exemplo.

Para então carregar o linux, o processo é bem parecido com a aplicação standalone explicada acima. A diferença é que você vai precisar executar separadamente os comandos "v" para o bootloader, "k" para o kernel e "y" para o rootfs.

O QUE MAIS POSSO FAZER COM ESTE BOOTLOADER

Você pode ainda carregar um WINDOWS CE (opções "n", "l", "w"), carregar uma aplicação diretamente para a memória e rodar de lá (opção "d"), formatar a flash (opção "f") e até fazer backup/restore da NAND (opções "u" e "r").

A regra aqui é usar o bootloader Supervivi na memória NOR para manipular a flash NAND, e assim não correr o risco de travar o kit. Se você apagar o conteúdo da NOR, só com um JTAG para você carregar novamente o bootloader.

Este bootloader, apesar de ajudar inicialmente, tem algumas deficiências, como suportar apenas sistemas de arquivo yaffs. No próximo post vamos carregar o u-boot, um bootloader bem mais flexivel, e brincar um pouco com o Android. Até lá!

Um abraço,

Sergio Prado

Posts relacionados:

Evento C++

2010-08-16T16:36:58+00:00

Esse fim-de-semana houve o tão falado evento C++, com a presença de dezenas de pessoas, algo que eu sinceramente não esperava. O bom desse evento foi saber que existem tantas pessoas interessadas em manter contato com quem gosta e pratica essa linguagem e também em saber que o nível técnico das palestras estão de alto para avançado.

Infelizmente em nenhuma das duas palestras práticas (minha e do Fernando) houve participação interativa, e ninguém que eu saiba abriu meu pacote-surpresa com os dumps a serem analisados. De qualquer forma, minha palestra ficou bagunçada pelo excesso de conteúdo e falta de tempo, o que me fez dar boas risadas ao ouvir no twitter que minha palestra foi mais um brainstorm. A intenção não era essa, claro, mas meu claro despreparo para muito conteúdo gerou essa impressão. Espero que do pouco que consegui explicar alguém tenha achado utilidade.

E, pelo jeito, futuramente irei aplicar essa mesma metodologia brainstorm em um videocast, que ainda não decidi como irei preparar. A ideia é analisarmos alguns dumps em conjunto e, para os que acompanharem online, a interatividade de perguntas & respostas.

Mas enquanto isso não acontece vamos dar uma olhada no que tínhamos no pacote-surpresa.

1. NotMyFaultEither.exe.mdmp - Stack Trash

0:000> kv
ChildEBP RetAddr  Args to Child
0012b200 7c90df3c 7c8025db 000000e8 00000000 ntdll!KiFastSystemCallRet
0012b204 7c8025db 000000e8 00000000 0012b238 ntdll!NtWaitForSingleObject+0xc
0012b268 7c802542 000000e8 000493e0 00000000 kernel32!WaitForSingleObjectEx+0xa8
0012b27c 6998ada6 000000e8 000493e0 003a0043 kernel32!WaitForSingleObject+0x12
0012bd70 6998aff1 000000c4 00000568 000000d0 faultrep!InternalGenerateMinidumpEx+0x335
0012bd9c 6998b50a 000000c4 00000568 0012c698 faultrep!InternalGenerateMinidump+0x75
0012c678 69986652 000000c4 00000568 0012c698 faultrep!InternalGenFullAndTriageMinidumps+0x8a
0012dea0 69987d3d 0012df18 0015c300 00000000 faultrep!ReportFaultDWM+0x4e5
0012e398 699882d8 0040a1dc 0012f1e0 ffffffff faultrep!StartManifestReportImmediate+0x268
0012f404 7c8643c6 0040a1dc ffffffff 0012fc24 faultrep!ReportFault+0x55a
Unable to load image C:\Documents and Settings\Administrador\Desktop\NotMyFaultEither.exe
*** WARNING: Unable to verify timestamp for NotMyFaultEither.exe
*** ERROR: Module load completed but symbols could not be loaded for NotMyFaultEither.exe
0012f678 004018aa 0040a1dc e280eec4 1d7f113b kernel32!UnhandledExceptionFilter+0x55b
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f9ac 00401357 dededede dededede dededede NotMyFaultEither+0x18aa
0012fbe8 dededede dededede dededede dededede NotMyFaultEither+0x1357
0012fbec dededede dededede dededede dededede 0xdededede
0012fbf4 dededede dededede dededede dededede 0xdededede
...

Como foi visto na palestra, uma pilha nesse estado demonstra claramente alguma variável que estourou e corrompeu o resto da pilha de chamadas. Na hora de voltar para a função chamadora, o endereço usado foi o endereço reescrito por lixo, e daí temos o "crash-pattern" Stack Trash.

2. NotMyFaultEither.mdmp - Dead Lock

0:000> kv
ChildEBP RetAddr  Args to Child
0012f900 7c90df3c 7c8025db 0000007c 00000000 ntdll!KiFastSystemCallRet
0012f904 7c8025db 0000007c 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
0012f968 7c802542 0000007c ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xa8
0012f97c 00401176 0000007c ffffffff 00000111 kernel32!WaitForSingleObject+0x12
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f9c0 7c910202 00000002 001506e8 00150000 NotMyFaultEither+0x1176
0012f9f8 7e3746d3 01010050 00000000 00000000 ntdll!RtlpAllocateFromHeapLookaside+0x42
0012fa5c 7e382672 01010050 01100068 7e3a4716 user32!DrawStateW+0x5cd
0012fae8 7e382c75 001563ac 01010050 00000003 user32!xxxBNDrawText+0x313
0012fb20 002d0036 00000000 00000020 0012fb3c user32!xxxDrawButton+0xbb
0012fb30 7e3799d8 0000800a 0012fbc8 7e375ba2 0x2d0036
0012fb3c 7e375ba2 0000800a 002d0036 fffffffc user32!NotifyWinEvent+0xd
0012fbc8 00000000 002d0036 004011b0 dcbaabcd user32!ButtonWndProcWorker+0x79b
0:000> !handle 0000007c
Handle 0000007c
  Type         	Thread
0:000> ~* kv

.  0  Id: 5e4.39c Suspend: 0 Teb: 7ffdd000 Unfrozen
ChildEBP RetAddr  Args to Child
0012f900 7c90df3c 7c8025db 0000007c 00000000 ntdll!KiFastSystemCallRet
0012f904 7c8025db 0000007c 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
0012f968 7c802542 0000007c ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xa8
0012f97c 00401176 0000007c ffffffff 00000111 kernel32!WaitForSingleObject+0x12
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f9c0 7c910202 00000002 001506e8 00150000 NotMyFaultEither+0x1176
0012f9f8 7e3746d3 01010050 00000000 00000000 ntdll!RtlpAllocateFromHeapLookaside+0x42
0012fa5c 7e382672 01010050 01100068 7e3a4716 user32!DrawStateW+0x5cd
0012fae8 7e382c75 001563ac 01010050 00000003 user32!xxxBNDrawText+0x313
0012fb20 002d0036 00000000 00000020 0012fb3c user32!xxxDrawButton+0xbb
0012fb30 7e3799d8 0000800a 0012fbc8 7e375ba2 0x2d0036
0012fb3c 7e375ba2 0000800a 002d0036 fffffffc user32!NotifyWinEvent+0xd
0012fbc8 00000000 002d0036 004011b0 dcbaabcd user32!ButtonWndProcWorker+0x79b

   1  Id: 5e4.6a4 Suspend: 0 Teb: 7ffdc000 Unfrozen
ChildEBP RetAddr  Args to Child
00b8ff10 7c90df3c 7c91b22b 00000080 00000000 ntdll!KiFastSystemCallRet
00b8ff14 7c91b22b 00000080 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
00b8ff9c 7c901046 0040e940 004010e0 0040e940 ntdll!RtlpWaitForCriticalSection+0x132
00b8ffa4 004010e0 0040e940 00000000 00000000 ntdll!RtlEnterCriticalSection+0x46
WARNING: Stack unwind information not available. Following frames may be wrong.
00b8ffec 00000000 004010c0 0012f99c 00000000 NotMyFaultEither+0x10e0
0:000> !cs 0040e940
-----------------------------------------
Critical section   = 0x0040e940 (NotMyFaultEither+0xE940)
DebugInfo          = 0x00154498
LOCKED
LockCount          = 0x1
OwningThread       = 0x0000039c
RecursionCount     = 0x1
LockSemaphore      = 0x80
SpinCount          = 0x00000000

A thread ativa no momento do dump aguardava por outra thread. Listando todas as threads do processo temos a primeira e a segunda, que tenta entrar em um critical section. Quando vemos que aquele CS estava sendo bloqueado pela primeira thread vemos claramente se tratar de um dead lock.

3. NotMyFaultEither_100808_172407.dmp - Access Violation

0:000> kv
ChildEBP RetAddr  Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f9cc 7e37f916 01010052 005a0049 0012f9f4 NotMyFaultEither+0x10a3
0012fa58 7e37f991 01010052 00000043 01100076 user32!ClientFrame+0xe0
0012fa7c 7e382909 01010052 0012fa98 00000000 user32!DrawFocusRect+0x40
0012fae8 7e382c75 00156304 01010052 00000003 user32!xxxBNDrawText+0x3e9
0012fb20 001100a0 00000000 00000020 0012fb3c user32!xxxDrawButton+0xbb
0012fb30 7e3799d8 0000800a 0012fbc8 7e375ba2 0x1100a0
0012fb3c 7e375ba2 0000800a 001100a0 fffffffc user32!NotifyWinEvent+0xd
0012fbc8 00000000 001100a0 004010f0 dcbaabcd user32!ButtonWndProcWorker+0x79b
0:000> ? eax+edx
Evaluate expression: 0 = 00000000
0:000> u
NotMyFaultEither+0x10a3:
004010a3 66890c02        mov     word ptr [edx+eax],cx
004010a7 83c002          add     eax,2
004010aa 6685c9          test    cx,cx

O disassemble da instrução inválida tenta escrever claramente em cima do endereço zerado (edx + eax). Dessa forma fica fácil saber que esse tipo de escrita não é permitido, constituindo nosso famosíssimo AV.

4. NotMyFaultEither_100808_175404.dmp - Exception not Handled

eax=00000000 ebx=00000111 ecx=7c91003d edx=00010000 esi=00330120 edi=7e374dfa
eip=7c90120e esp=0012f9a0 ebp=00000001 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
ntdll!DbgBreakPoint:
7c90120e cc              int     3
0:000> kv
ChildEBP RetAddr  Args to Child
0012f99c 004011ec 0012fc24 004010d0 0012fbe8 ntdll!DbgBreakPoint (FPO: [0,0,0])
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f9cc 7e37f916 01010054 005a0049 0012f9f4 NotMyFaultEither+0x11ec
0012fa58 7e37f991 01010054 00000043 01100076 user32!ClientFrame+0xe0

Esse foi meio de brinde. Uma exceção de breakpoint (int 3, ntdll!DbgBreakPoint) lançada sem um depurador atachado implica em derrubamento do processo, pois é uma exceção como outra qualquer. O programador deve ter esquecido um DebugBreak ou algo que o valha no código de produção, que acabou sendo executado.

5. ntdll_cliente.dll - Importação de símbolos

Essa foi a DLL encontrada no cliente quando ocorreu o problema relatado na imagem, também em anexo. Isso foi demonstrado na palestra com a ajuda do meu script que carrega DLLs, além de um pouco de sorte. Podemos analisar esse caso com mais calma em outro artigo. Acho que já falei demais por aqui.

Linuxcon 2010

2010-08-14T02:26:08+00:00

Esta semana, em Boston/EUA, a Linux Foundation organizou a Linuxcon 2010, reunindo desenvolvedores, administradores, usuários e executivos que trabalham com Linux.

Muita coisa aconteceu por lá, em áreas tão diversas como mobile, servidores e sistemas embarcados.

A Linux Foundation divulgou um programa, chamado de “Open Compliance Program”, cujo intuito é ajudar as empresas a disponibilizar os códigos-fonte utilizados sob licenças open-source, como a GPL. Segundo a Linux Foundation, muitas empresas não divulgam seu código-fonte por falta de conhecimento dos aspectos legais ou operacionais. A Linux Foundation irá disponibilizar ferramentas, manuais, cursos e modelos de documento para que as empresas evitem o desrespeito às licenças de software livre.

Sabendo da importância que o Linux vem assumindo nos últimos anos em sistemas embarcados e dispositivos móveis, a Qualcomm Inovation Center, uma subsidiária da Qualcomm, fabricante de chips para celulares, tornou-se um membro Platinum da Linux Foundation. Isso significa um melhor suporte e avanço do Linux no mercado mobile.

No keynote da Novell, no segundo dia do evento, falou-se bastante sobre a evolução da computação em nuvem, balanceamento de carga em servidores Linux e virtualização.

Foi divulgada também uma pesquisa realizada Forrester Research, sobre a utilização do Linux como host entre desenvolvedores de software, e o resultado mostrou um crescimento do Linux nos últimos 3 anos:

Falou-se também da plataforma Meego, junção dos projetos Moblin da Intel e Maemo da Nokia, baseado na arquitetura Atom da Intel.

Pelo que li em sites e blogs de tecnologia, o grande foco este ano foi a importância do software livre e aberto, e do crescimento da plataforma Linux no mercado mobile.

Nos dias 31/08 e 01/09, em São Paulo, vai acontecer a Linuxcon Brasil. Palestrantes de nome estarão por lá, como Linus Torvalds (criador do Linux), Jim Zelim (diretor da Linux Foundation) e Jane Silber (CEO da Canonical), além do inusitado Jon “maddog” Hall, que sempre esta em todos os eventos de Linux.

Eu estarei lá para ouvir o que o pessoal tem a dizer sobre o futuro do Linux, principalmente no mercado embedded. Se você quiser participar, a página do evento pode ser acessada aqui, e o ingresso para o evento pode ser comprado no site da Linux Magazine.

Um abraço,

Sergio Prado

Posts relacionados:

Meld 2.0 para desenvolvedores de linux embarcado

2010-08-12T22:34:01+00:00

A MontaVista, empresa líder no mercado de Linux Embarcado, liberou esta semana a nova versão do site da comunidade online para desenvolvidores de Linux embarcado, o Meld 2.0.

A primeira versão havia sido lançada em 2009, e sofreu várias alterações, principalmente na interface.

Apesar de ser patrocinado pela MontaVista, o site é voltado para qualquer tópico relacionado à sistemas embarcados com Linux, incluindo desenvolvimento com Android, customização do Linux, gerenciamento de memória e I/O, multi-core, etc.

Muito bom para solucionar problemas, ajudar outros desenvolvedores e fazer networking.

O novo site pode ser acessado em meld.org.

Um abraço,

Sergio Prado

Posts relacionados:

Renesas oferece kit de avaliação gratuitamente

2010-08-12T01:22:37+00:00

Por um tempo determinado a Renesas esta oferecendo gratuitamente seu kit de avaliação RX-Stick for RX610. A RX600 é uma série high-end da família RX de processadores, sucessora das famílias H8SX e R32C, arquiteturas de 32 bits da Renesas. Mais informações sobre a série RX600 podem ser lidas aqui.

O kit tem uma CPU de 32bits rodando a 100MHz, 2MB de Flash e 128KB de RAM, gravação e debugging pela USB, matriz de leds, potenciômetro, joystick de quatro direções, etc. A Renesas criou uma página no site de sua comunidade online para este kit com bastante documentação e software de exemplos para a utilização do kit, além de um vídeo demonstrando seu funcionamento:

~~Se você quiser participar e receber um kit gratuitamente, basta fazer um cadastro no site da Renesas aqui.~~

Atualização: Infelizmente a Renesas não pode atender toda a demanda, e a promoção está cancelada.

Um abraço,

Sergio Prado

Posts relacionados:

Kit de desenvolvimento FriendlyARM mini2440

2010-08-08T23:21:04+00:00

A pouco menos de 2 meses comprei no site do eBay o kit de desenvolvimento FriendlyARM mini2440. O produto foi importado da China e chegou este fim de semana. Fui ao estabelecimento dos Correios, paguei os impostos devidos e retirei o produto.

No total (valor do kit + frete + impostos) o kit saiu em torno de R$360,00. Valor bem mais barato do que se adquirisse por aqui, ou se comprasse um kit ARM similar.

E realmente este kit tem algumas caracteristicas interessantes. A começar pelo tamanho, de 10cm x 10cm. Veja uma foto com a placa do lado do meu Nokia E71:

Além da placa o kit acompanha um display touch screen de 3,5 polegadas e alguns cabos (serial, JTAG, USB, Ethernet), e vem pre-carregado com uma imagem rodando Linux e Qtopia. Veja abaixo o kit montado e rodando:

Suas configurações são impressionantes: CPU ARM9 da Samsung de 400MHz (S3C2440A), 64M de SDRAM, 64M de Nand Flash e 2M de NOR Flash, além de várias interfaces incluindo serial RS232, USB, Ethernet, Cartão SD e JTAG.

Já vem com um bootloader que possibilita carregar a aplicação via USB, e é compatível com os sistemas operacionais Windows CE, GNU/Linux e Android.

Este kit será, durante as próximas semanas, a plataforma que utilizarei para me aprofundar em ARM e linux embarcado, e especialmente no sistema operacional Android do Google.

Alguns posts interessantes sobre este kit estão por vir. Aguardem!

Um abraço,

Sergio Prado

Posts relacionados:

Kernel Linux 2.6.35

2010-08-05T02:17:31+00:00

No último dia 01/08 foi liberada a nova versão do kernel do Linux versão 2.6.35, que além de vários bug fixes, inclui também algumas alterações para sistemas multicore.

Uma das principais alterações é uma tecnologia desenvolvida pelo Google para o tratamento de pacotes de rede entre várias CPUs. Essa tecnologia é dividida em duas técnicas chamadas de RPS (Receive Packet Steering) e RFS (Receive Flow Steering), e consegue quase triplicar a performance da rede. Uma explicação sobre seu funcionamento pode ser lida aqui.

Esta nova versão também tem melhorias no sistema de arquivos Btrfs, considerado como o sucessor do Ext4, um frontend para o KDB (debugger do Kernel), um novo mecanismo de desfragmentação de memória e muitas outras alterações em drivers e correções de bugs.

Uma descrição mais completa das alterações pode ser lida aqui.

Um abraço,

Sergio Prado

Posts relacionados:

O Caos, a Moda e o Hacker

2010-07-31T20:57:45+00:00

O Caos

Nesta sexta feira aconteceu a última aula do curso de férias de 20hs que eu e alguns amigos ministramos na FEI sobre introdução ao Linux. Gostaria de registrar mais uma vez nosso agradecimento por todo o apoio que recebemos da instituição, representada pelo Professor Plínio.

O curso foi carinhosamente redefinido durante a semana como “Uma caótica e divertida introdução ao mundo Linux”, pois ao invés de nos focarmos em memorização de comandinhos, tentamos mostrar aos alunos como se virar sozinhos, habituando-os a usar o manual e deixando-os confortáveis o suficiente para experimentar.

A temática foi mais ou menos no estilo de “O que acontece se eu apertar esse botão vermelho?”, onde até mesmo os instrutores faziam coisas erradas para utilizar isso como gancho para o tópico seguinte.

No primeiro dia falamos para os alunos que eles não precisavam de um curso com especialistas para que pudessem explorar o sistema, então a frase mais usada foi “Não sei. Vamos procurar no man?”, seguida de uma ajudinha sobre como localizar e entender o manual corretamente.

Nesse formato, interagimos sobre manuais, comandos básicos, organização do sistema de arquivos, permissões, pipes, descritores de arquivos, redirecionamento de E/S, particioamento entre outros tópicos, sempre focando nas dúvidas dos alunos, ao invés de no programa do curso, mostrando que eles poderiam destrinchar um determinado assunto tão profundamente quanto quisessem.

Naturalmente, acabamos não tendo tempo de entrar em vários assuntos, mas os tópicos que não abordamos, ou os termos mais específicos eram deixados no quadro para que eles anotassem e pesquisassem por conta própria, sempre tomando o cuidado de dar uma direção, de forma que eles não ficassem perdidos ou com tudo mastigado.

Na quata feira, abordamos a instalação do Linux, tomando como exemplo o Ubuntu. Até mesmo um pendrive que corrompeu algumas ISOs serviu de gancho para falarmos de checksum. Em pouco tempo eles já estavam configurando o sistema sozinhos, atualizando e instalando pacotes sem que precisássemos interferir muito.

A quinta feira foi o dia mais audacioso para um curso introdutório. Focando nas necessidades dos alunos, abordamos ferramentas de desenvolvimento e debug. Demos uma visão geral das etapas de compilação, mostramos como as macros são pre-processadas, como é gerado código objeto e como os objetos são linkados. Falamos brevemente sobre cpp, gcc, ld, gdb, nm, objdump, e sobre como as bibliotecas são criadas, sem assustar com os comandos, focando nos conceitos por trás de tudo.

Embora esse seja um tópico razoavelmente avançado, mostramos para os alunos que eles tinham plenas condições de entender o que estava acontecendo e se aprofundarem no assunto caso quisessem. Mostramos que existe e deixamos por conta da curiosidade de cada um.

A moda

Na sexta feira trouxemos um questionamento sobre a humanidade das pessoas que operam as máquinas e sobre como a tecnologia pode ser prejudicial para elas. Tentamos fazer os alunos questionarem-se sobre o porquê de terem escolhido essa carreira.

A esse bate papo seguiu-se uma sessão de perguntas sobre mercado onde foi perguntado quais tecnologias deveriam ser aprendidas para se destacar no mercado. Foi levantada a questão do conhecimento motivado pelo produto, sendo que a visão do mercado é que devemos buscar o conhecimento somente se motivados por um problema ou criação de produtos.

Infelizmente, não tivemos tempo suficiente para uma discussão mais abrangente, mas neste ponto, a opinião dos instrutores diverge da opinião do mercado.

Todos sabemos que a necessidade motiva. Não discordamos disto. O que não aceitamos é que a busca pelo conhecimento seja podada pela existência ou não de uma determinada necessidade.

Quando estamos sujeitos às modas do mercado estamos sempre um passo atrás do que está acontecendo. Alguém determinou que a tecnologia X é o estado da arte da computação e só nos resta correr feito loucos para continuar fazendo parte do rebanho. Nós nos tornamos escravos. Seres passivos, reativos.

E sem liberdade de pensamento, sem sentimentos, sem criatividade, nós perdemos aquilo que nos faz humanos. Nós nos tornamos máquinas.

Querem um exemplo?

Na década de 90, a moda do mercado era Delphi. Toda vez que um aluno perguntava o que deveria aprender para entrar no mercado, a resposta era: Delphi. Porque Delphi era utilizado em muitas empresas, porque a maioria das vagas em aberto eram para programadores Delphi, etc. Assim, uma massa enorme de pessoas foi estimulada a aprender uma ferramenta, sem se preocupar com base algorítmica, lógica, estrutura ou estilo. Grande parte tornou-se mão de obra barata e dispensável.

Quando os ventos do mercado sopraram em uma outra direção, quem não estava realmente preparado foi varrido do mapa.

Depois vieram o Java, o .NET, o Ruby, entre outros.

Então você está dizendo que essas linguagens são ruins? Definitivamente não, e esse nem é o foco. A sacada é que mesmo nessas linguagens da moda, poucas pessoas estão realmente preparadas e bem posicionadas, enquanto a maioria é só mão de obra substituível e barata.

O que faz um profissional ser bem sucedido é sua capacidade de resolver problemas, e não quantas ferramentas ele sabe manipular.

É claro que quanto mais ferramentas à sua disposição, mais fácil tende a ser o seu trabalho, mas isso só é verdade se você possuir base o suficiente para escolher qual ferramenta se aplica e qual não se aplica. Essa talvez seja a melhor medida de competência.

Voltando ao questionamento anterior, se você só buscar o conhecimento quando houver uma necessidade, você provavelmente não terá à sua disposição conteúdo suficiente para fazer uma boa escolha quando precisar. Na verdade a escolha já terá sido feita por outra pessoa e só te restará a opção de acatar e seguir, depois é claro de correr atrás para aprender o que outra pessoa decidiu que é melhor para você.

Non Dvcor Dvco

Quando alguém me pergunta o que deve aprender para entrar no mercado de trabalho, em sempre me lembro da frase que está na bandeira da cidade de São Paulo: Não sou conduzido, conduzo.

Então eu digo que a pergunta está invertida. Está tudo errado e essa falácia é vendida com pompa e circunstância. Você não tem que aprender nada para agradar ao mercado, na verdade o que você tem que fazer é deixar o mercado querendo ter você, te desejando.

Se você fica sempre preocupado com o que os outros querem que você faça, você estará sempre um passo atrás, buscando algo que não é o que você deseja, e que assim que o vento mudar pode se tornar inútil.

Pergunte ao invés disso quais as características que você precisa desenvolver para se tornar um profissional desejado. A resposta é simples. Seja excelente. Escolha aquilo que mais lhe dá prazer e dedique-se com afinco. Prepare-se, busque embasamento, não se prenda a ferramentas e comandos, procure conhecer o que está em torno do que você está fazendo. Seja curioso, pergunte. Aprenda a ser um hacker no verdadeiro sentido da palavra.

Quando você parar de se preocupar com o que está na moda você vai perceber que há vagas que não conseguem ser preenchidas por empurradores de rato.

Busque sempre o conhecimento, mesmo que sem uma aplicação óbvia, pois as grandes invenções da humanidade só foram possíveis depois de integrar idéias muitas vezes não relacionadas. Há sempre mais de uma ciência por trás de tudo que você toca.

Explore com paixão o máximo de suas habilidades, que o sucesso será uma mera cosequência.

Apêndice

Especialmente mas não exclusivamente para os alunos do curso, deixo alguns links interessantes:

Qt – Password and encryption

2010-07-30T18:06:30+00:00

Warning: this is a mail about security, not about Qt, so skip it if you are not interested. On Friday 24 February 2006 16:27, ing. Federico Fuga wrote: > On Fri, 24 Feb 2006 08:25:47 -0600 > Andrew Vick wrote: > > Perhaps if you MD5 sum the password, that would be sufficient. > > [...]

Memory leak em linguagem C

2010-07-30T00:01:49+00:00

Dependendo do problema que queremos resolver, precisamos de uma quantidade variável de espaço para armazenar alguma informação. Isso pode acontecer, por exemplo, quando estamos trabalhando com protocolos de comunicação onde a quantidade de dados trafegados é variável. Ou então quando trabalhamos com estruturas de dados como listas ligadas, onde elementos desta lista são adicionados/removidos dinamicamente.

A biblioteca C padrão fornece as funções malloc() para alocar memória dinamicamente e free() para desalocar uma região de memória previamente alocada.

1 2	void malloc(size_t size); void free(void ptr);

Estas rotinas usam uma região de memória chamada de heap. É no heap que os bytes são alocados com malloc() e liberados com free(). O tamanho do heap é variável, dependendo de vários fatores como o tamanho da memória, capacidade de endereçamento da CPU, etc. Mas claramente é uma região de memória finita. A cada chamada a malloc(), uma pequena parte desta região de memória é consumida. E se não for liberada, corremos o risco de ficar sem memória.

O uso de malloc() e free() de maneira descontrolada pode causar dois principais problemas:

Fragmentação de memória: A cada malloc(), um pedaço de memória é alocado, e fica indisponível para a aplicação. Se o software abusar das chamadas a malloc(), a memória poderá ficar fragmentada em pequenos pedaços alocados para a aplicação. Depois as rotinas de alocação terão dificuldades de encontrar "pedaços" de memória que atendem às novas chamadas à malloc(). A forma como ocorre esta fragmentação é dependente da biblioteca ou do sistema operacional responsável pela alocação de memória.
Memory leak: Se você alocar regiões de memória com malloc(), mas depois do uso não liberar estas regiões com o free(), temos caracterizado o memory leak, um dos principais pesadelos do desenvolvedor de software embarcado. É um pesadelo porque a memoria começa a ser consumida aos poucos, e a aplicação pode ficar dias sem apresentar algum problema. Mas então num belo dia, quando toda a memória é consumida, coisas estranhas começam a acontecer. A performance da aplicação começa a se degradar, e travamentos ou reboot automaticos irão invariavelmente acontecer.

Nosso foco neste artigo é o memory leak. Vamos analisar então algumas técnicas para tratar e identificar este problema.

Técnica 0: Não usar malloc()

Usar alocação dinamica de memória em sistemas embarcados deve ser seu ultimo recurso. Padrões como o MISRA-C, que tratei em um artigo passado, proibem categoricamente seu uso. Portanto pensem bastante na solução. Depois pensem de novo. E de novo. Até ter certeza de que alocação dinâmica de memória é a única solução para seu problema.

Técnica 1: Code review

Então você usou alocação dinâmica de memória em seu código, e agora precisa garantir a ausência de memory leak na aplicação. E uma das primeiras técnicas a serem aplicadas é o Code Review, ou revisão de código.

A técnica de revisão de código deveria ser aplicada independentemente do uso de malloc(). Nós devemos revisar nossos códigos. E então devemos pedir para outras pessoas revisá-los. E depois revisar o código de outras pessoas. Uma boa parte dos bugs podem ser encontrados com esta técnica.

A idéia aqui é ler o código, identificar todas as chamadas à malloc(), e verificar se existe o free() correspondente. Dê uma olhada na função abaixo:

int txData(char *data)
{
    unsigned char *ptr = NULL, *buf = NULL;
    int size = strlen(data);
 
    /* allocate buffer */
    if ((ptr = buf = (unsigned char*)malloc(size + 3)) == NULL)
        return(-1);
 
    /* STX */
    *ptr++ = STX;
 
    /* data */
    strncpy(ptr, data, size);
    ptr += size;
 
    /* ETX */
    *ptr++ = ETX;
 
    /* send data */
    if (txSerial(buf, size + 3) == -1)
        return(-2);
 
    /* free buffer */
    free(buf);
 
    return 0;
}

Temos aqui um exemplo clássico de memory leak. Esta função recebe uma string, formata em um buffer, e envia pela serial. Como o tamanho da string é variável, o buffer de comunicação é alocado dinamicamente. Veja que na linha 7 o buffer é alocado, e na linha 25 o buffer é liberado. Porém, quando ocorre um erro ao enviar os dados (linha 21), a função retorna sem desalocar o buffer, caracterizando o memory leak. Este erro é muito comum. Quando usamos malloc() devemos nos certificar de que todos os pontos de retorno da função possuem uma chamada a free().

Esta técnica pode ser muito custosa para aplicações com milhares de linhas de código, e isso nos leva ao uso de ferramentas para automatizar esta verificação.

Técnica 2: Uso de ferramentas

Ferramentas são uma parte essencial do processo de desenvolvimento, e não será diferente quando nosso objetivo é analisar um problema de memory leak. Existem vários tipos de ferramentas, algumas que fazem análise estática de código (analisa diretamente o código-fonte) e outras que fazem verificação dinâmica (em tempo de execução).

Para testar algumas ferramentas, vamos complementar a função txData() com uma função main(), e forçar um memory leak. Nosso código final ficou assim:

/* leak.c */
#include "stdio.h"
#include "string.h"
#include "malloc.h"
 
#define STX 0x02
#define ETX 0x03
 
int txSerial(unsigned char *buffer, int size)
{
    return -1;
}
 
 
int txData(char *data)
{
    unsigned char *ptr = NULL, *buf = NULL;
    int size = strlen(data);
 
    /* allocate buffer */
    if ((ptr = buf = (unsigned char*)malloc(size + 3)) == NULL)
        return(-1);
 
    /* STX */
    *ptr++ = STX;
 
    /* data */
    strncpy(ptr, data, size);
    ptr += size;
 
    /* ETX */
    *ptr++ = ETX;
 
    /* send data */
    if (txSerial(buf, size + 3) == -1)
        return(-2);
 
    /* free buffer */
    free(buf);
 
    return 0;
}
 
void main()
{
    char *msg = "MemoryLeak";
 
    if (!txData(msg))
        printf("Mensagem enviada com sucesso!\n");
    else
        printf("Erro ao enviar mensagem!\n");
}

Primeiro vamos testar com uma ferramenta de analise estática de código, o SPLINT, já tratado anteriormente no meu artigo aqui.

$ splint leak.c
Splint 3.1.2 --- 03 May 2009
....
leak.c:37:20: Owned storage ptr not released before return
  A memory leak has been detected. Only-qualified storage is not released
  before the last reference to it is lost. (Use -mustfreeonly to inhibit
  warning)
   leak.c:22:10: Storage ptr becomes owned
....

Voilá! A ferramenta encontrou facilmente o memory leak que inserimos no código. O interessante de uma ferramenta de análise estática é que, como a analisa é feita nos fontes da aplicação, ela pode ser usada em qualquer código-fonte, independente da arquitetura ou do sistema operacional que estamos usando, desde que esteja no padrão ANSI C.

Já o uso de ferramentas de análise dinâmica podem pegar casos específicos que passariam despercebidos quando usamos ferramentas de análise estática. Por outro lado, estas ferramentas são dependentes de determinado sistema operacional, ou então exigem que você compile seu código com uma biblioteca específica. Isso porque estas ferramentas adicionam uma camada extra na sua aplicação, monitorando cada chamada a malloc() e free(), para depois gerar um relatório que pode indicar um memory leak quando a quantidade de chamadas a malloc() for diferente da quantidade de chamadas a free() por exemplo.

Uma destas ferramentas, muito utilizada para detectar memory leak em aplicações para sistemas Unix, é o Valgring. Esta ferramenta de debug, dentre outras funcionalidades, monitora o uso de memória pela aplicação em tempo de execução. Vamos testar o comportamento desta ferramenta com a nossa aplicação.

$ valgrind ./leak
==3811== Memcheck, a memory error detector
==3811== Copyright (C) 2002-2009, and GNU GPL, by Julian Seward et al.
==3811== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==3811== Command: ./leak
==3811== 
Erro ao enviar mensagem!
==3811== 
==3811== HEAP SUMMARY:
==3811==     in use at exit: 13 bytes in 1 blocks
==3811==   total heap usage: 1 allocs, 0 frees, 13 bytes allocated
==3811== 
==3811== LEAK SUMMARY:
==3811==    definitely lost: 13 bytes in 1 blocks
==3811==    indirectly lost: 0 bytes in 0 blocks
==3811==      possibly lost: 0 bytes in 0 blocks
==3811==    still reachable: 0 bytes in 0 blocks
==3811==         suppressed: 0 bytes in 0 blocks
==3811== Rerun with --leak-check=full to see details of leaked memory
==3811== 
==3811== For counts of detected and suppressed errors, rerun with: -v
==3811== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 8)

Veja que após executar a aplicação ela imprime um relatório do uso de memória, indicando a ocorrencia do memory leak.

Se você quiser, dê uma olhada também na biblioteca dmalloc. Ela adiciona uma camada adicional na sua aplicação, possibilitando o debug de alocação de memória em tempo de execução. Esta biblioteca foi escrita em ANSI C e pode ser facilmente portada para qualquer arquitetura.

Técnica 3: Desenvolva sua própria biblioteca

Se nenhuma solução disponível lhe servir, sempre existe a possibilidade de você colocar a mão na massa e desenvolver suas próprias rotinas de alocação de memória. Reinventar a roda é sempre mais trabalhoso e custoso, mas se você se sentir aventureiro, pode analisar esta possibilidade. Dê uma olhada neste artigo aqui.

Normalmente, só damos atenção a um problema quando o vivenciamos. Sempre achamos que não vai acontecer conosco. E quando acontece, temos que lidar com as consequencias e aprender com os erros. Mas melhor do que aprender com seus próprios erros, é aprender com os erros dos outros. Portanto, seja mais proativo. memory leak é igual a pressão alta, uma doença silenciosa, mas que quando apresenta os sintomas, estes provavelmente serão fatais!

Um abraço,

Sergio Prado

Posts relacionados:

Microsoft em novo acordo com a ARM

2010-07-27T01:21:36+00:00

No último dia 23 de julho a Microsoft anunciou um novo acordo de licenciamento com a ARM, dando a ela o acesso à arquitetura e à liberdade de produzir chips com a arquitetura ARM.

A Microsoft segue o mesmo caminho da Apple, que licenciou a arquitetura ARM para produzir seus chips A4 para o iPad e o iPhone4.

Muito têm-se especulado sobre qual o objetivo da Microsoft ao licenciar a arquitetura ARM. Podem ser produtos voltados ao mercado de consumo como smartphones, netbooks e tablets, usando aí seu novo SO, o Windows Phone 7.

Ou então especula-se também a utilização de chips ARM nos servidores que rodam o sistema de buscas da Microsoft, o Bing, principalmente porque ela divulgou recentemente uma posição aberta para um engenheiro de software com experiencia em ARM para atuar em seus Data Centers.

É esperar para ver.

O press release do acordo pode ser lido aqui.

Um abraço,

Sergio Prado

Posts relacionados:

Sétimo Encontro de Programadores C++

2010-07-26T02:44:31+00:00

Mais um fim-de-semana no ócio e na vadiagem. Tenho que manter minhas qualidades de bom programador que sou: preguiçoso, impaciente e pretensioso.

Mas nem por isso deixei de terminar uma primeira versão do aplicativo que irei usar como base na minha palestra do nosso próximo encontro C++: Crash Dump Analysis. Se alguém tiver dicas de quais os problemas mais difíceis do Universo para analisar em um dump de memória, comente a respeito e veremos o que dá pra fazer.

Enquanto isso, continuo descobrindo maravilhas do WinDbg. Essa semana fiquei brincando de colocar breakpoint em user-mode, mas depurando o kernel, como fizeram os rapazes do Ntdebugging. A conclusão é que ele vale para todos os aplicativos abertos. Tente com o MessageBox!

!process 0 0 notepad.exe
.reload /user
bp user32!MessageBoxW

Mas devaneio. Talvez outra boa qualidade de um bom programador.

Padrão ELF para arquivos-objeto

2010-07-24T23:13:51+00:00

O ELF (Executable and Linkable Format) é um padrão para arquivos executáveis, arquivos-objeto e bibliotecas. Foi usado inicialmente no System V Unix, sistema operacional comercial da AT&T na década de 80. Em 1993 o controle do padrão passou para um Comitê, o TIS (Tool Interface Standards) formado por um grupo de empresas como IBM, Intel e Borland. Em 1995 foi lançada a versão 1.2 do padrão, versão atual usada até hoje em muitos sabores UNIX, incluindo o GNU/Linux.

Mas porque precisamos de um padrão para arquivos-objeto? A resposta é portabilidade. Para que possamos linkar códigos gerados por diferentes compiladores, linkar nossa aplicação com bibliotecas de diferentes fornecedores, executar o código em diferentes sistemas operacionais, etc.

Na definição do padrão, existem 3 tipos principais de arquivos-objeto:

Arquivos relocáveis: são os arquivos-objeto propriamente ditos, por exemplo os arquivos “.o” gerados pelo gcc quando compilamos um módulo “.c”
Arquivos executáveis: são arquivos que podem ser executados pelo sistema operacional.
Arquivos-objeto compartilhados: são as bibliotecas, “.so” ou “.a” em sistemas GNU/Linux.

O padrão ELF tem a estrutura exibida na figura abaixo:

O Header descreve informações sobre o arquivo, como o tipo de arquivo (objeto, biblioteca ou executável), arquitetura (MIPS, x86 68K, etc), versão, endereços de memória, etc. Já o Section/Segment são os trechos de código compilados. O Program Header Table é usado pelo SO para carregar o programa executável em memória, e o Session Header Table possui informações sobre o Session (trechos) do programa.

Nosso programa de teste será o mais simples possível. Nosso objetivo aqui é apresentar ferramentas de análise do formato ELF presente em sistemas GNU/Linux.

#include "stdio.h"
 
int main(void)
{
    printf("Blog do Sergio Prado\n");
    return 0;
}

Compile com o gcc, usando os comandos abaixo:

$ gcc -c main.c
$ gcc main.o -o app

Foram gerados dois arquivos, o arquivo objeto “main.o” e o executável “app”.

O comando “file” irá exibir informações genéricas sobre os arquivos gerados:

$ file main.o
main.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
 
$ file app
app: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped

Com o comando “readelf”, podemos analisar todas as informações do arquivo gerado. Vamos olhar o header o arquivo objeto main.o:

$ readelf -h main.o
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2s complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          220 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         11
  Section header string table index: 8

Veja que o header é flexivel o suficiente para manter a portabilidade do formato entre diferentes arquiteturas.

Com o comando readelf você pode ler qualquer informação de um arquivo no formato ELF, mas existem alguns outros comandos que podem te ajudar a analisar um arquivo objeto:

O comando “nm” lista os simbolos do arquivo objeto:

$ nm app
08049f20 d _DYNAMIC
08049ff4 d _GLOBAL_OFFSET_TABLE_
080484bc R _IO_stdin_used
         w _Jv_RegisterClasses
08049f10 d __CTOR_END__
08049f0c d __CTOR_LIST__
08049f18 D __DTOR_END__
080482b8 T _init
08048330 T _start
0804a014 b completed.7021
0804a00c W data_start
0804a018 b dtor_idx.7023
080483c0 t frame_dummy
...........................
080483e4 T main
         U puts@@GLIBC_2.0

O comando “ldd” lista as dependencias de bibliotecas linkadas dinamicamente:

$ ldd app 
linux-gate.so.1 =>  (0x0088d000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00d1f000)
/lib/ld-linux.so.2 (0x0099f000)

Mas porque você precisa saber de tudo isso? Talvez porque você vai se aventurar no desenvolvimento de um compilador. Ou porque você encontrou algum problema ao tentar linkar arquivos-objeto ou bibliotecas geradas por diferentes toolchains. Ou porque você esta tendo alguma dificuldade ao tentar executar uma aplicação compilada em um ambiente diferente do ambiente de execução.

Recentemente trabalhei em um projeto onde uma aplicação compilada em uma máquina x86 não rodava em outra máquina de mesma arquitetura por incompatibilidade da versão da biblioteca GLIBC. Na minha máquina rodava a GLIBC_2.7 e na máquina destino rodava a GLIBC_2.6.

Tinhas duas opções, recompilar a aplicação em um ambiente com a versão da GLIBC correta, que poderia levar um certo tempo. Ou então deixar minha aplicação mais portável para rodar em qualquer versão de GLIBC, e encontrar qual a função que estava requisitando a GLIBC_2.7.

Com o comando “nm” descobri que a função “sscanf” estava requisitando a GLIBC_2.7.

$ nm app | grep 2.7
U sscanf@@GLIBC_2.7

Reescrevi o trecho da aplicação que usava a função sscanf, e o problema foi resolvido de forma bem rápida.

Vale a pena dar uma lida no padrão ELF e entender como todo o processo de linkagem de objetos, geração do executável, carga de bibliotecas dinâmicas e execução funciona. O padrão pode ser baixado aqui.

Para quem se interessar, existem ainda outros formatos além do ELF, como o a.out usado nos primórdios de sistemas UNIX, o COFF usado em alguns UNIX e adaptado para o Microsoft Windows e o Mach-O usado no MacOS X.

Um abraço,

Sergio Prado

Posts relacionados:

Sétimo Encontro de Programadores C++

2010-07-22T20:09:08+00:00

O grupo C & C++ Brasil (ccppbrasil) tem o imenso orgulho em anunciar (agora oficialmente) o nosso sétimo encontro. Detalhes:

Sétimo Encontro de Programadores C & C++
dia 14 de agosto de 2010, sábado
em São Paulo, SP. Rua Teixeira da Silva, 647 - Paraíso
As palestras de qualidade de sempre
O ótimo chopp/tubaína/networking de sempre após o evento
Mais detalhes na página do grupo

1 comentário(s)

Concepts e templates condicionais

2010-07-15T19:43:27+00:00

Concepts O comitê de padronização do C++ox decidiu excluir concepts da proposta de evolução corrente da linguagem. Dessa forma uma importante ferramenta foi deixada de lado. Na proposta discutida, concepts seria uma forma de garantir que determinado parâmetro de uma template implementa métodos específicos (obedecendo a um padrão) ou possui determinados tipos. Enfim, uma forma de garantir que [...]

Test Driven em C++ cross-compiled é possível

2010-07-06T23:07:36+00:00

afe!

Enquanto não rola um estudo retrospectivo maneiro, aqui vão minhas primeiras impressões.

por mais que pareça andar de ré, tenha um porting para o sistema do desenvolvedor, onde a compilação não é cruzada;
não exija frameworks xUnit e faça bilhões de programecos se necessário;
guarde no coração que não é preciso reflection nem mesmo shared objects para aplicar dependency injection;
não despreze a tediosa tarefa de testar parte a parte, pequena parte a pequena parte;
não tenha escrúpulos para satisfazer dependências aleatórias com stubs.

A maior revelação para mim nesse processo foram os pontos 2, 3 e 5 acima.

Após um longo tempo digerindo o problema, e após diversas discussões sobre que framework de testes usar, por fim completei a tarefa da forma mais tosca possível: cada teste é um programa executável individual. O projeto usa cmake para configurar a construção, e o ctest funciona legal com essa lista de programas de teste.

O maior esforço nesse processo foi refatorar o código o suficiente para conseguir testar uma unidade isolada realmente. A dificuldade percebida pela equipe desde o início era devido ao acoplamento entre as diversas unidades teóricas do sistema, e a quantidade de código de inicialização de coisas irrelevantes ao teste. Eventualmente tropecei na idéia de dependency injection. Apesar de ser algo que ocorre em super frameworks de componentes empresariais, o conceito é simples e se mostrou aplicável mesmo em um sistema ligado estaticamente, desde que as unidades fossem desacopladas o suficiente uma da outra. No nosso caso, isso se dá na forma de um Factory central para todo o sistema, pré-existente ao meu esforço.

Claro que esse desacoplamento "suficiente" é um graal e nunca ocorre, especialmente em um ambiente tão confortável quanto o da ligação estática -- onde tudo se junta no final numa grande sopa de elementos. Ocorreu que algumas funções que eram parte da unidade mas não eram exercitadas faziam referência a algum nome que acabava indefinido no programa final -- função ou variável extern. Eventualmente realizei que isso simplesmente não tem solução prática e aceitei a seguinte possibilidade: se uma unidade não compila sem uma função de outra unidade, e a função é irrelevante para o teste, vamos enfiar um stub na jogada e ponto final. De certa forma, isso pode ser considerado um Mock do mundo pré-componentização.

Acaba que, por fim, se não lindamente xUnit, meu objeto de manutenção agora possui uma suite de testes de unidade. Entre os vinte e trinta testes bem básicos que eu bolei pra começar, já descobri umas cinco funções implementadas diferente do que o meu projeto previa. O cmake suporta bem a lista de testes e gera um relatoriozinho bem legal.

- Depuração: Parte 1

2010-07-01T03:06:46+00:00

Seja Elegante

Talvez possa ser algo que passe despercebido por vários desenvolvedores, porém dúvido quem nunca tenha se deparado com mensagens de “log” vagas ou sem nenhum nexo ou bem pior, como mensagens idênticas replicadas por várias partes do código!
A algum tempo atrás estava trabalhando em um projeto em que um respectivo desenvolvedor da equipe possuia o costume de espalhar ou replicar centenas de printf() pelo código com mensagens tipo!

printf(“!!! FULANO – Aqui!!!”);

printf(“!!! FULANO – Arquivo.cpp: Aqui!!!\n”);

Precisa falar que isto e pessímo? Certo que e preciso um bom senso com o uso de mensagens de depuração pois dependendo ao invés de ajudar podem só atrapalhar. principalmente quando você necessita ter controle sobre tais mensagens, como por exemplo obter a localização da mensagem através do nome da função, arquivo e linha.

Lembrando que dependendo da situação e contexto eu sou a favor de utilizar o pragma no compilador ativando o “poison” desativando dentre várias funções o printf (), evitando de ter espalhada pelo sistema! Futuramente um post sobre o poison.

O pré-processador do GCC oferece (*) várias macros, as que irei utilizar em questão são:

__FILE__ : Substituída pelo nome do arquivo.
__PRETTY_FUNCTION__ : Substituídas pelo nome nome da função.
__LINE__ : Substituída pelo número da linha de código.

(*) Mais detalhes sobre as macros do GCC.

A utilização dessas macros irá facilitar a localização das mensagens de depuração, Abaixo um simples exemplo demonstrado em debug1.c.

/**
 * By Jorge Pereira <jpereiran@gmail.com>
 * Date: Tue Jun 29 02:51:44 BRT 2010
 */

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>

// Macro condicional
#ifdef DEBUG
#	warning "Debug is enabled"
#	define TRACE_DEBUG(fmt, ...) \
	fprintf(stderr, " ** DEBUG: %s:%d %s(): "fmt"\n", \
	__FILE__, __LINE__, __PRETTY_FUNCTION__, ##__VA_ARGS__)
#else
#	warning "Debug is disabled"
#	define TRACE_DEBUG(fmt, ...)
#endif

#define MAX_STRING 5 /* tamanho maximo de uma string */

// Função simples de exemplo...
void
show_name (const char* name,
		   size_t len)
{
	size_t offset = len;

	// Verificação qualquer...
	if (len > MAX_STRING)
	{
		// Abaixo mensagem de depuração, perceba que ela será ativada apenas
                // quando em tempo de compilação você ativar a macro "DEBUG"
		TRACE_DEBUG ("Ooops! Tamanho da string(%d) e excedeu o limite(%d)...",
			len, MAX_STRING);
		offset = MAX_STRING;
	}

	// Manipulação qualquer...
	write (STDOUT_FILENO, name, offset);
	write (STDOUT_FILENO, "\n", 1);
}

int
main (int argc, char* argv[])
{
	if (argc < 2)
	{
		printf ("Usage: %s <string>\n", argv[0]);
		exit (1);
	}

	show_name (argv[1], strlen (argv[1]));

	return 0;
}

Com este exemplo básico em mãos, vamos compilar e executar.

[jpereira@miracleworld Codes]$ gcc -Wall -o debug1 debug1.c
debug1.c:18:3: warning: #warning "Debug is disabled"
[jpereira@miracleworld Codes]$ ./debug1 "Jorge"
Jorge
[jpereira@miracleworld Codes]$ ./debug1 "Jorge Pereira"
Jorge
[jpereira@miracleworld Codes]$

Imagine que seu sistema possui inúmeros arquivos e você precisa em determinados pontos obter o máximo de informação sobre as mensagens de depuração, talvez seja interessante ter além de uma mensagem objetiva obter juntamente o nome da função, arquivo e linha de onde foi invocada tal mensagem.

[jpereira@miracleworld Codes]$ gcc -Wall -DDEBUG -o debug1 debug1.c
debug1.c:13:3: warning: #warning "Debug is enabled"
[jpereira@miracleworld Codes]$ ./debug1 "Jorge"
Jorge
[jpereira@miracleworld Codes]$ ./debug1 "Jorge Pereira"
 ** DEBUG: debug1.c:36 show_name(): Ooops! Tamanho da string(13) e excedeu o limite(5)...
Jorge
[jpereira@miracleworld Codes]$

Agora veja situação que você está trabalhando em um sistema com várias checagens complexas de cenários “nada convencionais” em que você não tem certeza se vai acontecer sempre ou não.
Sem falar que torna-se um atrativo a possibilidade de você poder ativar/desativar o simples mecanismo, como por exemplo poder criar macros para depuração de componentes específicos (ex.: relacionadas a sockets, I/O, sgdb, …), isto poderá facilitar a identificação e remoção de bugs.

Lembrando que este e o primeiro post entre vários que pretendo publicar relacionados a sugestões e técnicas de depuração. Fique de olho na segunda parte desta saga em que irei explicar uma mais dinâmica do mesmo assunto abordado neste post associando ao uso de variáveis de ambiente.
Dúvidas e Sugestões, são sempre bem vindas!

Autor: Jorge Pereira

- Adicionado ao Kernel o suporte nativo as teclas especiais do notebook “Sony Vaio VPC-EB15FB”

2010-06-27T07:02:49+00:00

Sempre tive preferência pelos produtos produzidos pela Sony, em especial os notebooks. O meu antigo VGN-FS750 começou a apresentar alguns problemas após eu ter dado um tombo nele, desde então nunca mais foi o mesmo.

Porém no mês passado resolvi comprar um novo notebook que fosse preferencialmente da Sony, e após várias buscas cheguei ao modelo VPC-EB15FB. Então fui ao shopping e comprei diretamente na loja da SonyStyle o brinquedinho abaixo.

Assim que cheguei em casa fiz o download do Ubuntu 9.10 e instalei, após o primeiro boot que iniciei a configuração e recuperação dos meus backups do notebook antigo percebi que algumas teclas de atalhos não funcionaram, estranho né? Abaixo imagem das teclas na qual estou me referindo.

Obviamente que não fiquei de braços cruzados, fiz checkout diretamente pelo GIT do Kernel o modulo “platform-drivers-x86” e após alguns ajustes já estava adicionado o suporte das novas teclas da série EB de notebooks da Sony ao Kernel do Linux.

Resumindo, suporte adicionado seguido de patch gerado e submetido ao Kernel. Agora e aguardar a próxima versão do Kernel para termos por padrão o suporte a tais teclas!

Patch gerado a partir do Kernel ??2.6.35-rc3

- Introdução aos Linux Device Drivers (ILDD)

2010-06-21T20:10:00+00:00

Olá,

Caso você tenha necessidade ou curiosidade em relação a Device Drivers no Linux, este com certeza será um bom material para iniciar-se na “brincadeira”.

Introdução aos Linux Device Drivers (ILDD) é um curso que tem por objectivo apresentar os princípios básicos do desenvolvimento de device drivers no Linux kernel. Pretende-se com este curso, que o leitor tenha contacto com várias ferramentas e sub-sistemas existentes no kernel, adquirindo assim as bases que lhe irão permitir desenvolver o suporte para a grande maioria dos dispositivos. Alguns dos temas introduzidos são: estrutura básica de um device driver, comunicação com o userspace, memória dinâmica, eventos assíncronos, primitivas de sincronização e comunicação com o hardware.

Este curso aborda o tema de uma perspectiva pedagógica, através da sistematização dos conceitos em conjunto com uma forte componente prática, na qual se convida o leitor à implementação gradual de um device driver que dará suporte a um dispositivo especificamente concebido para o efeito. O leitor poderá ainda consultar a literatura de referência, de onde se destacam os excelentes títulos: Linux Device Drivers, Understanding the Linux Kernel e Linux Kernel in a Nutshell.

O autor, com a ajuda dos seus revisores, investiu mais de um ano de trabalho na elaboração e preparação deste curso, no sentido de oferecer à comunidade, não só um manual de aprendizagem abrangente, mas também uma importante referência futura. Caso encontre alguns erros ou tenha sugestões que visam melhorar ou complementar este trabalho, não hesite em contactar o autor.

Download aqui

Qualidade de código

2010-06-19T21:59:09+00:00

Go to english version Recentemente tive a oportunidade de assitir uma palestra do Mark Shuttleworth na Linux Tag 2010. Naturalmente, foram abordados os assuntos de open-source de uma forma mais abrangente e do próprio Ubuntu. Não consegui acompanhar todos os detalhes pois não sou tão envolvido assim com Linux. Mas achei bem interessante quando ele [...]

- Imagens talvez jamais vistas?

2010-06-16T03:00:10+00:00

Para descontrair, abaixo segue algumas imagens que registrei durante o passar do tempo.

(*) Go Horse Process

- Por que as empresas teimam em contratar programadores mercenários?

2010-06-13T04:18:55+00:00

Recentemente li The Python Paradox, de Paul Graham, e sua tradução O Paradoxo Python no #!SouNerd.

O texto faz todo sentido: quem aprende a fazer qualquer coisa por gosto tende a fazer melhor do que quem aprende a fazer por dinheiro. É uma verdade.

Assim, quem aprende a programar porque gosta de programar tende a programar melhor do que quem aprende para ganhar dinheiro e a grande maioria de quem aprende a programar Java só o faz por dinheiro (claro que há lá suas exceções), enquanto quem aprende linguagens mais esóticas o faz por prazer.

Então por que as empresas teimam em contratar programadores mercenários?

Pensando sobre nisso e observando a comunidade, pensei em uma resposta…

Eu vejo três tipos de programadores, como três vértices de um triângulo cromático, e cada um está em uma região dessa área, mais próximo ou distante de cada vértice.

Esses três tipos são: amador, mercenário e empolgado (por falta de palavra melhor).

Mercenário

O mercenário é aquele que quer dinheiro e lucro é tudo o que o impulsiona. Geralmente não tem escrúpulos e faz tudo o que lhe mandam. Seu mantra é: «Pagando bem, que mal tem?»

Quem é 100% mercenário geralmente acaba largando a profissão por algo que dê mais dinheiro, mas basta estar um pentelésimo mais para o centro do triângulo que permanece na profissão.

Normalmente aprende uma linguagem que dê muitas opções de emprego – e que, por consequência, tenha de competir com muita gente –, como Java, C# ou PHP, e rejeita todas as demais. Quando as trata como inferiores, é apenas para tentar justificar a própria incompetência, resultante da falta de gosto pelo que faz.

Amador

O amador é aquele que gosta de verdade do que está fazendo, ele ama programar, daí amador.

Quem é 100% amador quase sempre se perde aprendendo coisas inúteis e não consegue ganhar dinheiro porque muitas vezes perde o foco do que precisa fazer, distraindo-se com besteiras.

Normalmente aprende linguagens bem diferentes, que poucos sabem, como Lisp, Smalltalk ou Fortran – talvez LOLCODE –, e não é incomum que aprenda uma penca de linguagens, nesse caso, também os hypes, como Python e Ruby.

Empolgado

O empolgado é aquele que vai atrás de algum hype, linguagem da moda. Há uns anos eram de Java, mas os empolgados da atualidade querem Python e/ou Ruby.

Quem é 100% empolgado sabe tudo que acontece na comunidade, mas quase nada de programação. Conhece todas as metodologias em alta, sabe todos os macetes e design patterns de sua linguagem que precisa para impressionar os iniciantes, mas não é lá muito eficiente. É tão preocupado com a auto-imagem e o que acontece na comunidade que se esquece que há todo um background a ser aprendido por trás da Computação.

Felizmente (quase) ninguém é 100% alguma coisa.

Depois de toda esta dissertação, por que diabos as empresas mais engessadas preferem os mercenários?

Por causa de seu mantra! Basta pagar o que o mercenário acha muito – o que muitas vezes é quase nada pra empresa – e ele faz qualquer coisa que mandarem, torna-se um cão bem adestrado. Essas empresas não querem eficiência, querem obediência.

O que as empresas não veem é que esses cães não são tão ágeis quanto os gatos que pulam pelos telhados: aqueles que, apesar de em nenhum extremo, se encontram mais próximos do vértice do amador.

Na verdade as metodologias ágeis não são práticas de trabalho, mas técnias sociais para atrair programadores que, apesar de ainda um pouco mercenários, sejam muito mais amadores – ser um pouco empolgado também ajuda, já que as linguagens hype facilitam pela grande mobilidade da comunidade. As empresas mais espertas e as start-up viram isso e usam as metodologias ágeis para criar equipes enxutas e mais eficientes do que qualquer equipe de mercenários jamais conseguirá ser.

Fonte

- Conhecendo e utilizando a LD_PRELOAD

2010-06-11T06:55:59+00:00

Muitas pessoas utilizam, utilizaram ou vão utilizar a variável LD_PRELOAD, e por sua vez nem sempre sabem para que ela serve! Caso este seja o seu problema, problema este não mais será!!

O que acontece basicamente e que o linker dinâmico do Linux (assim como em tantos outros sistemas operacionais) utiliza diversas formas, alguma delas sendo através de variáveis de ambiente para controlar seu comportamento. Sendo que neste caso a variável LD_PRELOAD informa ao linker dinâmico que carregue as bibliotecas listadas nela antes de carregar quaisquer outras bibliotecas necessárias, enquando LD_LIBRARY_PATH especifica um caminho alternativo para usar ao procurar bibliotecas que serão carregadas.

Partindo deste principio podemos fazer com que um programa a ser executado seja “hijacked” por outro programa, ou seja. Podemos fazer por exemplo que a função hehe() previamente chamada pelo programa “A” tenha seu comportamento alterado sem precisar fazer quaisquer alteração no programa “A”. Um pouco complexo? talvez! Mais vamos por a mão na massa! hands on!

Digamos que você tem o programa “main” conforme o código de exemplo abaixo, perceba que o código e super simples. apenas declaro um ponteiro de caracteres, aloco memória e em seguida copio uma sequência de caracteres para o ponteiro previamente alocado. Simples, certo?

1) Abaixo código de exemplo de nosso “main.c” ou clique aqui para download.

/*
 *  Filename: hijack_main.c
 *  Created: Wed Jun  9 22:11:12 BRT 2010
 *  Author: Jorge Pereira <jpereiran@gmail.com>
 */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int
main (int argc,
      char* argv[])
{
  char* nome = (char*)malloc (100);

  strcpy (nome, "Jorge Pereira");
  printf ("NOME: %s\n", nome);

  free (nome);
  return 0;
}

# Vamos compilar e executar o nosso exemplo “main.c”

$ gcc -Wall -o main main.c
$ ./main
NOME: Jorge Pereira
$

Até aqui tudo bem, porém imagine você em uma determinada situação em que precisa saber quantos bytes está sendo alocado por um determinado programa? e você por alguns instantes imagina sobre a possibilidade de poder fazer algum tipo de “overload” de uma determinada função na qual você conhece sua assinatura. (Digamos, você sabe a assinatura do método, quantidade e tipos dos parâmetros, …).

Pois bem, neste exemplo que irei demonstrar será para sobrecarregar todas as chamadas feitas pelo meu programa “main” às funções malloc() e free() e em seguida exibir uma mensagem no caso do malloc() imprimindo seu parâmetro que e o tamanho de bytes alocados, e na função free() exibindo os ponteiros que foram liberados.

Neste caso, iremos criar uma biblioteca chamada “libhijack_hehe.so” que será carregada através da variável mágica LD_PRELOAD em parceria com nosso querido linker dinâmico.

2) Abaixo código de exemplo de “hijack_hehe.c“, ou clique aqui para download.

/*
 *  Filename: hijack_hehe.c
 *  Created: Wed Jun  9 22:11:12 BRT 2010
 *  Author: Jorge Pereira <jpereiran@gmail.com>
 */
#define _GNU_SOURCE
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdarg.h>

#include <dlfcn.h>

#define HIJACK_DEBUG(fmt, ...) \
	fprintf(stderr, " ** DEBUG: %s:%d %s(): "fmt"\n", \
	__FILE__, __LINE__, __PRETTY_FUNCTION__, ##__VA_ARGS__)

static void* (*hack_malloc)(size_t size) = NULL;
static void  (*hack_free)(void *p) = NULL;

static void* rest_malloc = NULL;

void*
malloc (size_t size)
{
  if (hack_malloc == NULL)
  {
    hack_malloc = (void *(*)(size_t)) dlsym (RTLD_NEXT, "malloc");
    rest_malloc = NULL;
  }

  if (rest_malloc == NULL)
  {
    rest_malloc = hack_malloc (size);
    HIJACK_DEBUG ("Alocando (%d) bytes, chunck(%p)", size, (void*)rest_malloc);
    return rest_malloc;
  }

  hack_malloc = NULL;
  return rest_malloc;
}

void
free (void *p)
{
	HIJACK_DEBUG ("Desalocando (%p)", p);

  if (hack_free == NULL)
  {
    hack_free = (void (*)(void *)) dlsym(RTLD_NEXT, "free");
  }

  hack_free (p);
}

Agora vamos compilar, executar e analisar o comportamento.

$ gcc -Wall -shared -ldl -o libhijack_hehe.so hijack_hehe.c
$ LD_PRELOAD=./libhijack_hehe.so ./main
 ** DEBUG: hijack_hehe.c:35 malloc(): Alocando (100) bytes, chunck(0x9273008)
NOME: Jorge Pereira
 ** DEBUG: hijack_hehe.c:46 free(): Desalocando (0x9273008)
$

Percebeu algo diferente na execução com a LD_PRELOAD passando como parâmetro a nossa libhijack_hehe.so? pois bem, todas as chamadas às funções malloc() e free() foram sobrecarregadas e passaram a se comportar conforme as versões que escrevi em hijack_hehe.c. Caso tenha ficado curioso, e so re-escrever tais exemplos com outras funções que você deseja sobrecarregar e ver o comportamento. Lembrando que basta utilizar a criatividade e perceberá na quantidade de coisas que podem ser feita com tal técnica.

Exemplo: Nas funções que fazem checagem com strcmp(), uso da crypt(), … entre outras.

Referências

man 8 ld.so

Autor: Jorge Pereira
Data: Wed Jun 9 23:42:26 BRT 2010

- Que poeira danada!

2010-06-09T23:56:01+00:00

Caso tenho alguém por aqui ainda, saiba que ao contrário deste blog estou vivo, embora muita coisa tenha mudado nestes meses que me ausentei do blog. Confesso que inúmeros problemas desde de uma cirurgia para retirada de um pequeno tumor entre o esôfago e pulmão, notebook quebrou, muito e muito trabalho na empresa, outros problemas de saúde até tantos outros imprevistos e inconvenientes que surgiram ao decorrer do tempo!

Pois bem, parece que foi ontem! E já se passaram mais de um ano que estou morando e trabalhando aqui no Rio de Janeiro. E confesso que está sendo muito difícil ter tempo livre para quaisquer tipo de atividade que costumava ter, uma delas era o fato de “blogar”. Mais as coisas se acertaram e agora e a hora da reviravolta. move on!

E antes de mais nada, e preciso passar uma vassoura por aqui pois está muito empoeirado. Por esses meses que se passaram desde o meu último post em 23 de outubro, eu estarei mudando a cara do Blog para marcar a minha volta a comunidade OpenSource e principalmente aos projetos pessoais e em especial as contribuições com o GNOME (Pois é, estou em falta com muita coisa!), inclusive sobre um patch que fiz para o kernel recentemente adicionando suporte ao novo modelo de notebook da Sony VPCEB15FB que tem algumas funcionalidades diferente antes não suportada no Kernel. Estarei comentando mais sobre o assunto brevemente!

E isto, só tenho a agradecer aos amigos que acompanharam os problemas que surgiram e agora e bola pra frente e correr atrás do tempo perdido!!

De volta a comunidade, Happy hacking!

<obs>A Imagem foi copiada do blog do meu parceiro Larry.Jr, thanks! =)</obs>

typenames e templates

2010-06-07T13:24:24+00:00

Manipulação de tipos em C++ Há uma certa dificuldade para os programadores iniciantes na área de templates que se aventuram a manipular tipos. A primeira delas é quanto ao uso da palavra reservada typename. Essa palavra deve ser utilizada para informar ao compilador que o nome que vem em seguida é um tipo, e não um [...]

Const e Volatile

2010-06-04T17:26:33+00:00

Padrão C (ISO/IEC 9899:1990)

6.5.3 type-qualifier
 const
 volatile

Padrão C++ (ISO/IEC 14882:1998)

cv-qualifier
 const
 volatile

Qualificadores de tipo

Chamamos de qualificador de tipo as palavrinhas mágicas const e volatile. Na prática elas definem como uma determinada variável será usada e se comportará durante a vida do programa.

Const

Uma variável const não pode ser alterada pelo programa durante sua execução, apenas durante sua inicialização:

const float pi = 3.14; // até onde sabemos, pi não irá mudar neste Universo

No exemplo acima, o valor de pi não pode mais ser alterado. Só que repare que ele foi, em determinado momento, alterado com um valor constante: na sua inicialização. Isso quer dizer que:

pi é uma variável no programa representada por um local na memória endereçável pelo programa
pi não é um define do pré-processador que irá virar uma constante literal (3.14, por exemplo)

// eu posso endereçar uma constante,
// desde que qualifique corretamente meu ponteiro
const float* ppi = & pi;

Teoricamente a região da memória que contiver uma variável const pode ser qualificada pelo sistema operacional como somente-leitura, mas isso não é uma obrigação. É obrigação do compilador avisar sobre tentativas de alteração da variável no meio do programa, mas nem sempre é possível enxergar que a memória não é alterável. Dessa forma, resultados imprevisíveis podem ocorrer.

Uso prático

Eu costumo usar variáveis const no lugar de defines. Além de ganhar na tipagem as constantes não precisam ser necessariamente globais, nem acessíveis por outros módulos. Um outro uso muito comum é criar variáveis locais que você sabe que não devem ser alteráveis por ninguém, como o tamanho de matrizes primitivas.

namespace Math
{
	const float Pi = 3.14;
}
 
//...
 
int func1(int x)
{
	float calc = x * Math::Pi;
	return calc;
}
 
//...
 
int func2(int y)
{
	const size_t PathSize = MAX_PATH * 2;
	//...
	//...
	char path[PathSize];
	//...
}

Volatile

O significado do volatile teoricamente muda de implementação para implementação, mas na prática é uma forma de definir uma variável que está sendo acessada por outros programas/threads/entidades espíritas que podem alterar o seu valor sem seu programa notar quando.

O exemplo clássico da API Win32 é o InterlockedIncrement, que realiza operações atômicas em valores inteiros. Para fazer isso é necessário usar um recurso interno disponível pelo processador que irá modificar a memória sem intrusão de outras threads/processadores.

Uso prático

Variáveis volatile geralmente interagem de alguma forma com o sistema em que rodam, e são representadas por ponteiros para memória retornada por esse sistema ou documentada como sendo de uso específico.

Const e Volatile

É possível que exista uma variável que não pode ser modificada pelo seu programa, mas é modificada pelo sistema, de forma que ela é uma mutante!

/// endereça o relógio do sistema, atualizado a cada 1/100 milissegundos
const volatile int* g_systemClock = (const volatile int*) 0x7689B9D4;

A definição de *g_systemClock é de uma memória que não pode ser alterada; só que ela é, pelo sistema. Então a variável também é volatile. No entanto, independente de ser const ou volatile, o tipo nunca será alterado, apenas qualificado. São duas coisas diferentes na linguagem.

C: como passar estrutura pra função usando ponteiros

2010-06-03T15:17:00+00:00

Abaixo, um exemplo, sobre como passar uma estrutura de dados para uma função. Ao receber a estrutura a função f() faz modificações nessa estrutura. #include <stdio.h> #include <string.h> #include <stdlib.h> // a estrutura. *d vai guardar somente o endereço do bloco de letras, // não as letras, as letras vão tá na memória em algum [...]

Enum

2010-05-31T17:11:09+00:00

Padrão C (ISO/IEC 9899:1990)

6.5.2.2 enum-specifier
 enum

Padrão C++ (ISO/IEC 14882:1998)

type-specifier
 enum-specifier

enum-specifier
 enum

Uma enumeração faz duas coisas: define um novo tipo, parecido com um inteiro, e cria uma lista de constantes com nomes significativos. A definição técnica do tipo de um enum é mais complicada, mas basicamente ele é um novo int.

Como funciona: definimos uma lista com cada elemento tendo um valor inteiro, geralmente único. Todos os nomes usados na lista passam a fazer parte do espaço de nomes atual e funcionam como constantes com o seu valor definido no início.

enum FileType // criamos o novo tipo inteiro FileType
{
   Binary = 1, // Binary é uma constante com valor igual a 1
   Text = 2, // Text é uma constante com seu sizeof igual a sizeof(FileType)
   Mixed = 3 // Todas as constantes da enumeração são do mesmo tipo
};

Obs.: Os elementos que não possuem valor definido são definidos automaticamente como o valor do elemento anterior acrescidos de um. Se for o primeiro elemento, seu valor padrão é zero.

enum Numbers
{
   zero,  // igual a zero
   one,   // igual a um
   two,   // igual a dois
   three  // igual a tres
};
 
 
enum Hexa
{
   JulioCesar = 1,
   Lucio = 3,
   Juan,                // Juan = 3 + 1 = 4
   Gilberto Silva = 6,
   Felipe Melo          // 6 + 1 = 7
};

Detalhe bizarro: você sabia que, apesar da vírgula ser usada para separar valores de enumeração, ela pode também terminar uma listagem? Por algum motivo exdrúxulo (se alguém quiser explicar), um valor de enumeração foi definido de tal forma que sempre poderá existir uma vírgula terminando ele:

enum VirgulaSafada { 
   um = 1, 
   dois, 
   tres, // o que essa vírgula no final tá fazendo aqui?
};

Uso prático

Geralmente usamos enumerações para definir valores únicos (tag) em um argumento de função, ou, mais moderno, como substituto daqueles antigos defines em C para mapas de bits. Nesse último caso não usamos o tipo da enumeração, pois ele pode conter apenas um valor único definido, e não um conjunto deles:

enum ModoDeServir
{
   assado,
   cozido,
   frito,
   cru
};
 
 
void Cook(Prato p, ModoDeServir ms);
 
main()
{
   Cook(frango, cozido);
}
 
 
enum FileOpenMode
{
   fomRead   = 0x0001,
   fomWrite  = 0x0002,
   fomOver   = 0x0004,
   fomDel    = 0x0008,
};
 
void OpenFile(DWORD fileOpenMode);
 
main()
{
   OpenFile(fomRead | fomWrite);
}

Note que usamos uma enumeração nesse último caso para termos um nome significativo para uma flag, além desse nome fazer de fato parte dos nomes do programa, e não um define que, para o compilador, não existe.

Boas práticas

Como os tipos da enumeração passam a pertencer ao namespace atual, eles podem se misturar facilmente com todos os nomes daquele namespace. Dessa forma, é útil e bem organizado definir um prefixo para os nomes, que pode ser formado pelas iniciais do nome da enumeração, como no exemplo acima (fom = FileOpenMode).

O surgimento do enum veio como evolução de uma prática já consagrada pelo uso na linguagem C, que eram as listas de valores constantes criados através de defines com algum prefixo em comum (FILE_SHARE_*, SW_SHOW_*, etc). Portanto, sempre que se encontrar em uma situação para criar esse tipo de lista, a enumeração é o caminho atualmente ideal.

// A listagem abaixo pode virar um enum...
#define FOM_READ   0x0001
#define FOM_WRITE  0x0002
#define FOM_OVER   0x0004
#define FOM_DEL    0x0008
 
// ... como este aqui!
enum FileOpenMode
{
   FOM_READ   = 0x0001,
   FOM_WRITE  = 0x0002,
   FOM_OVER   = 0x0004,
   FOM_DEL    = 0x0008,
};
 
 
// esse pedaço de código abaixo...
int main()
{
   OpenFile(path, FOM_WRITE);
}
 
// ... vira isso após ser pré-processado...
int main()
{
   OpenFile(path, 0x0002);
}
 
// ... mas isso se fossem usados enums...
int main()
{
   OpenFile(path, FOM_WRITE); // FOM_WRITE faz parte da linguagem
}

Atualização: e qual a diferença?

Perguntado por um leitor sobre qual a diferença prática do último exemplo, onde temos praticamente o mesmo resultado entre usar defines e enumerações, imaginei que a mesma dúvida pode ter surgido para várias pessoas, porque é uma boa dúvida. Dá a entender que o autor deste artigo está se atentando a preciosismos da linguagem (e está mesmo!), mas à vezes as aparências enganam.

Para ilustrar melhor fiz um mais elaborado. Aqui, estamos lendo pedaços de dados que tiveram que ser alinhados com alguma "gordura".

// alinhamento obrigatório pelo leiaute dos dados
#define CHUNKSZ_BASE 0x5000
 
#define CHUNKSZ_TINY   0x1000 + CHUNKSZ_BASE
#define CHUNKSZ_SMALL  0x2000 + CHUNKSZ_BASE
#define CHUNKSZ_MEDIUM 0x4000 + CHUNKSZ_BASE
#define CHUNKSZ_HUGE   0x8000 + CHUNKSZ_BASE
 
 
// alinhamento obrigatório pelo leiaute dos dados
static const int chunkSizeBase = 0x5000;
 
enum ChunkSize
{
   chunkszTiny   = 0x1000 + chunkSizeBase,
   chunkszSmall  = 0x2000 + chunkSizeBase,
   chunkszMedium = 0x4000 + chunkSizeBase,
   chunkszHuge   = 0x8000 + chunkSizeBase,
};
 
 
// Fonte original
int main()
{
	// lendo quadro pedaços de dados (tamanho médio)
   ReadChunkFromFile(file, CHUNKSZ_MEDIUM * 4);
 
	// lendo quadro pedaços de dados (tamanho médio)
   ReadChunkFromFile(file, chunkszMedium * 4);
}
 
 
// Pós-processado
int main()
{
	// lendo sei lá o que (perde alinhamento)
   ReadChunkFromFile(file, 0x4000 + CHUNKSZ_BASE * 4);
 
	// lendo quadro pedaços de dados (tamanho médio)
   ReadChunkFromFile(file, chunkszMedium * 4);
}

Aviso para os programadores mais calejados, eu omiti propositalmente os parênteses obrigatórios para qualquer define que tenha cálculos matemáticos, para ilustrar que muitas vezes o que vemos antes não é o que aparece depois.

An introduction to libvirt’s LXC (LinuX Container) support

2010-05-30T14:16:55+00:00

This is a short^H^H^H^H^H long mail to introduce / walk-through some recent developments in libvirt to support native Linux hosted container virtualization using the kernel capabilities the people on this list have been adding in recent releases. We've been working on this for a few months now, but not really publicised it before now, and [...]

Modificadores e qualificadores de tipo

2010-05-28T12:06:29+00:00

@caloni poderia pensar em fazer um artigo sobre os modificadores de tipo em c? os mais complexo, acho eu: volatile, enum, union, extern, etc

Uma coisa de cada vez: existem modificadores (ou qualificadores) de tipo e especificadores de tipo. Volatile e extern se encaixam na primeira categoria, enum e union na segunda. Veremos um pouco desses dois lados da linguagem em doses paliativas.

Padrão C (ISO/IEC 9899:1990)

6.5.2.2 enum-specifier
 enum

6.5.3 type-qualifier
 const
 volatile

6.5.2.1 struct-or-union
 struct
 union

6.5.1 storage-class-specifier
 typedef
 extern
 static
 auto
 register

Padrão C++ (ISO/IEC 14882:1998)

type-specifier
 enum-specifier

enum-specifier
 enum

cv-qualifier
 const
 volatile

class-key
 class
 struct
 union

storage-class-specifier
 auto
 register
 static
 extern
 mutable

decl-specifier
 storage-class-specifier
 typedef

Modificadores de tipo

Um modificador de tipo é opcional na definição de um tipo e deve estar sempre relacionado com a declaração de alguma variável. Ele determina, em termos gerais, qual será a função dessa variável. Ela pode ser modificada? Onde ela se encontra no programa? Como ela será modificada?

Como exemplo rápido, temos abaixo uma variável que é atualizada pelo clock do processador e uma variável que não pode ser alterada após sua primeira atribuição:

volatile int* clockSecs = <algum-endereço-do-sistema>;

const float pi = 3.14;

Fica meio óbvio que a primeira variável possui seu valor volátil, ou seja, muda conforme o tempo passa, e não depende do próprio código (pode mudar sem sua permissão). A segunda variável também tem um uso explícito, uma vez que o valor de pi nunca será alterado (não nesse Universo).

Especificadores de tipo

Os especificadores de tipo possuem cada um sua peculiaridade. Os mais peculiares, que veremos nos próximos artigos, serão as enumerações e as construções bizarras de structs e unions.

enum Contador { um = 1, dois, tres, };

union Atoms { struct { int part1; int part2; } parts; int64 total; };

Aqui não é um compêndio teórico sobre a linguagem. Vamos falar particularmente da programação Windows, mas esteja livre para dar seus pitacos com respeito a outros sistemas operacionais e suas implementações igualmente exdrúxulas =)

Spiral Fill Puzzle

2010-05-26T03:57:03+00:00

At the Algorithms (O) Group in LinkedIn, there is a puzzle to fill a matrix N x M using a spiral form.

An example of 3 x 3 matrix:

1 2 3

8 9 4

7 6 5

You can encounter the original post here.

My suggestion, written in C++, was:

#include <cstdio>

template<int TROWS, int TCOLUMNS>
struct matrix
{
    static const int ROWS = TROWS, COLUMNS = TCOLUMNS;
    int get( int row, int col ) const { return v[row][col]; }
    void set( int row, int col, int value ) { v[row][col] = value; }
private:
    int v[TROWS][TCOLUMNS];
};

template<int ROWS, int COLUMNS>
void spiral_fill( matrix<ROWS, COLUMNS>& m, int rows = ROWS, int cols = COLUMNS, int top_left = 0, int seed = 0 )
{
    int n = seed;
    const int cols_minus_2 = cols - 2, rows_minus_2 = rows - 2;
    const int top_left_plus_rows = top_left + rows, top_left_plus_cols = top_left + cols;
    const int top_left_plus_1 = top_left + 1;

    for( int i = top_left; i < top_left_plus_cols; ++i ) //top
        m.set( top_left, i, ++n );

    for( int i = top_left_plus_1; i < top_left_plus_rows - 1; ++i ) //right
        m.set( i, top_left_plus_cols - 1, ++n );

    if( rows > 1 )
        for( int i = top_left_plus_cols - 1; i >= top_left; --i ) //bottom
            m.set( top_left_plus_rows - 1, i, ++n );

    if( cols > 1 )
        for( int i = top_left_plus_rows - 2; i > top_left; --i ) //left
            m.set( i, top_left, ++n );

    if( rows > 2 && cols > 2 )
    {
        //int new_seed = seed + rows * cols - rows_minus_2 * cols_minus_2;
        int new_seed = seed + 2 * rows + 2 * cols - 4; //expression simplification pointed by Eldar Musayev (check the original post link at the top)
        spiral_fill( m, rows_minus_2, cols_minus_2, top_left_plus_1, new_seed );

}
}

template<int ROWS, int COLUMNS>
void display( const matrix<ROWS, COLUMNS>& m )
{
using std::printf;

    for( int i = 0; i < m.ROWS; ++i )
    {
        for( int j = 0; j < m.COLUMNS; ++j )
            printf( "%03d ", m.get(i, j) );
        printf( "\n" );
    }
    printf( "\n" );
}

template<int ROWS, int COLUMNS>
void fill_and_display_matrix(){ matrix<ROWS, COLUMNS> m; spiral_fill( m ); display( m ); }

int main()
{
    fill_and_display_matrix<1, 1>();
    fill_and_display_matrix<1, 2>();
    fill_and_display_matrix<1, 9>();
    fill_and_display_matrix<9, 1>();
    fill_and_display_matrix<9, 2>();
    fill_and_display_matrix<2, 1>();
    fill_and_display_matrix<2, 2>();
    fill_and_display_matrix<3, 3>();
    fill_and_display_matrix<4, 4>();
    fill_and_display_matrix<5, 5>();
    fill_and_display_matrix<10, 10>();
    fill_and_display_matrix<15, 10>();
}

The results:

I hope to know if this could be considered a beautiful code (search for beautiful code) - "...it is clear, concise, explains the intent of the programmer, and expands the understanding that one can gain by simply looking at the code." - Wikipedia.

This version can be parallelized too. It's not a perfect parallelization (ok, I can see some false sharing here and there), but works... Maybe I'll write a CUDA or DirectCompute (or both) version of this puzzle

To parallelize using PPL, only these adds:

#include <ppl.h>

using namespace Concurrency;
structured_task_group g_Tasks;

...

auto task = make_task( [&]{ spiral_fill( m, rows_minus_2, cols_minus_2, top_left_plus_1, new_seed ); } );
g_Tasks.run_and_wait( task );

Mais Tio

2010-05-15T21:29:11+00:00

Aos que foram à palestra e lançamento do Tio no nosqlbr, algumas coisas que eu esqueci de falar:

O Tio funciona com 3 campos: key, value e metadata. Esses campos podem ter o tipo string, int, double e raw (blob).
As chaves dos maps só podem ser strings. Mas você pode acessar por índice numérico para ler o n-ésimo item do map
Todo container tem suporte à propriedades. Por exemplo, você pode criar uma propriedade "schema" em um container para saber como serializar ou desserializar o que está no campo value
Para fazer um upsert, é só fazer algo como "my_map['rodrigo'] = 'strauss'"
Eu quebrei o build do Linux... Quem for testar hoje, tem que compilar em Release e usar somente os containers em memória (volatile/list, volatile/list, etc). Corrijo isso essa semana :-)

Quase tudo que eu falei está na documentação do projeto. Quem tiver mais dúvidas, o melhor canal para perguntar são as duas listas de discussão (inglês e português).

A apresentação está em http://docs.google.com/present/view?id=dg9kbfzn_73m4c7qvc6

0 comentário(s)

C++0x vai mudar sua vida: listas de inicialização

2010-05-15T20:27:49+00:00

Com a nova sintaxe para listas de inicialização, é como se agora houvesse uma notação para o valor literal de praticamente qualquer estrutura de dados.

Observe meu teste de unidade construindo um "attribute template" PKCS #11 com std::vector direto na inicialização:

std::vector attributes
{
CK_ATTRIBUTE { CKA_CLASS, &object_class, sizeof(object_class) },
CK_ATTRIBUTE { CKA_TOKEN, &on_token, sizeof(on_token) },
CK_ATTRIBUTE { CKA_LABEL, &label, sizeof(label) },
CK_ATTRIBUTE { CKA_APPLICATION, &application, sizeof(application) },
CK_ATTRIBUTE { CKA_VALUE, &data, sizeof(data) }
};

O segredo da notação está nessa pseudo-gramática:

type-name identifier { initializer-list };

que é análoga em significado a:

type-name identifier ( argument-list );

ou:

type-name identifier = type-name ( argument-list );

vim + minibufexpl + vtreeexplorer + mswin + mouse=a + screen = VIM IDE

2010-05-14T17:46:56+00:00

Então, o QT Creator é ótimo, mas, muitas vezes é preciso trabalhar dentro de uma VM ou remotamente, fazendo algum serviço que irá fornecer dados para a interface em Qt. Sendo assim, trabalhar com o VIM cru, fica dificil, pra editar, compilar e depurar o código. Abaixo, meu .vimrc que tornar o VIM praticamente uma [...]

vim + qt + autocomplete

2010-05-14T13:14:57+00:00

Baseado no post Code completion in VIM for C/C++/Java/Python, segue dicas rápidas para adicionar suporte ao autocomplete do Qt4 ao VIM (Unbutu). ~/.vimrc source $VIMRUNTIME/mswin.vim syntax enable se nu set tabstop=4 set shiftwidth=4 set expandtab filetype on filetype plugin on set nocp autocmd FileType python set omnifunc=pythoncomplete#Complete autocmd FileType javascript set omnifunc=javascriptcomplete#CompleteJS autocmd FileType html [...]

Apresentação do Tio dia 15 de maio no nosqlbr

2010-05-11T13:11:31+00:00

Esse sábado acontecerá o primeiro evento brasileiro sobre nosql, organizado pelo @porcelli do OpenSpotlight. Eu farei a palestra "Tio: um nosql Made in Brasil". Tio? Ãh?

Eu ando parindo um nosql já faz mais de um ano, depois de passar mais de um ano pensando no conceito. Aproveitando esse evento e a modinha do nosql, acho que agora é a hora de publicar os fontes e divulgar. Os fontes e a documentação estão em http://code.google.com/p/tio (apesar da insistência do @porcelli para que eu colocasse no github :-))

Para o pessoal de C++, o Tio nada mais é do que containers STL em um servidor remoto, mas tudo construído sobre um base publish/subscribe. Olha como fica simples construir alguns softwares server side com esse conceito:

Servidor de filas: criar uma lista, o producer manda as coisas fazendo push_back na lista e o consumer usa pop_front. Ou o commando wnp_next, que facilitar a contrução de clusters computacionais.
Servidor de chat: criar uma lista de mensagem para cada usuário. O usuário assina as modificações da própria lista e quem quiser mandar uma mensagem pra ele faz um push_back na lista. Você pode criar um map com os IDs dos usuários, onde o valor é o nome da lista de mensagens. Se você assinar esse mapa, ainda será notificado automagicamente sobre todos os usuários criados ou apagados

Minha idéia é: todo software server mantém estado e notifica clientes das modificações nesses estados. Eu faço isso bastante usando C++, e é sempre isso. Um monte de containers STL para controlar o estado da aplicação, e código para enviar notificações via TCP para os interessados. O Tio faz quase todo esse serviço sozinho. Muitos protótipos de aplicação podem ser feito com zero linhas de código server.

Os fontes e a documentação estão lá no site do projeto Tio. Para compilar no Windows, tem um projeto do Visual Studio 2008 (não testei no Express, mas deve funcionar). No Linux, você vai precisa do CMake ("cmake . && make" faz o serviço). Você vai precisar do Boost devidamente instalado, compilado e configurado, o Tio é feito usando Boost Asio. O fonte é bem simples e direto, deve ser um bom ponto de aprendizado para quem está estudando Boost Asio.

Criei duas listas de discussão: uma em inglês, e uma em português. Note que o site do Tio é todo em inglês (e os comentários do Wiki devem ser em inglês). Está nos planos ter documentação em português também. Mas eu sou um só :-)

Nos fontes você vai achar um client para C++ e um client Python. Por falta de tempo, o client Python está mais refinado do que o client C++. Em C++ tudo é feito usando algo como

shared_ptr<TioContainer>

container->PushBack(TIONULL, "abcdef")

Em Python você usa um container remoto como se fosse local, com coisas tipo

container["rodrigostrauss"] = "messages/rodrigostrauss"

Para maiores explicações e o chopp/happyhour/networking de sempre, nos encontramos no evento de nosql esse sábado. Traga suas perguntas e comparações com outros nosql.

1 comentário(s)

Último post pelo Blogger

2010-04-28T21:26:37+00:00

Olá cambada! Puts, eu já estava com saudade de postar alguma coisa. Pena este ser mais um daqueles chatos posts Off-Topic. O que posso fazer? É o que temos para o momento.

Hoje pela manhã recebi um mais um e-mail de aviso do Blogger dizendo que o suporte à publicação via FTP estão com os dias contatos. Como este recurso é utilizado por menos de 5% dos seus usuários, resolveram dar fim à ele. Mas essa não foi a principal razão pela qual eu decidi deixar de postar pelo Blogger para usar o WordPress. Eu já vinha ensaiando essa transição há pelo menos dois anos. A faculdade e outras desculpinhas esfarrapadas não me deixavam pôr essa idéia em prática. Alguns leitores já vinham reclamando da falta de um índice geral e da separação dos posts em categorias, coisas que o WordPress faz com uma mão nas costas.

Como um web designer, eu sou um excelente desenvolvedor de drivers, e eu já tinha ouvido falar que o WordPress usava PHP e MySQL, assuntos os quais eu não tenho a menor intimidade. Inicialmente contei com a ajuda do meu irmão que já possuia um blog pelo WordPress, mas assim como eu, ele também tinha faculdade e outras prioridades. Por um tempo eu contratei os serviços de um web designer que colocava em prática as minhas ídéias com relação ao novo layout, mas por fim ele se envolveu com algo maior e fiquei na mão novamente.

A idéia de migrar o blog persistia, mas a preguiça, a falta de tempo e de domínio de HTML e CSS me fizeram ir empurrando esse problema com a barriga. Cheguei até a ler o guia o oficial da famosa série "Preciso aprender isso de qualquer jeito", o livro "WordPress for Dummies". Pra quem está acostumado a ler livros de assuntos um tanto mais cabeludos, as mais de 380 páginas do livro foram como um passeio no parque. O mais surpreendente pra mim foi descobrir que o WordPress é uma ferramenta que não requer prática nem tampouco habilidade, e isso incluia as habilidades de PHP e MySQL que eu não tenho. Uma ferramenta poderosa, flexível e simples. A parte desagradável dessa história é que tudo que o livro falou sobre HTML e CSS é que ele não falava a respeito.

Até aqui excelente. Os 67 posts poderiam ser migrados mas o layout ainda foi o meu carma. Outras tentativas de encontrar alguém disposto a fazer o design pra mim me mostrou que estou no emprego errado. Esse negócio de desenvolver drivers não está com nada. Pra ganhar dinheiro mesmo o negócio é fazer Web Design.

Há uns três meses, quando recebi o primeiro aviso do Blogger sobre o fim do suporte ao FTP foi o momento "Agora ou nunca". Minha faculdade não me servia mais de desculpa e aos poucos fui colocando a mão na massa. Depois de muito trabalho manual de migrar cada post e cada comentário, veio o layout. Graças ao site W3Schools, às aulas particulares de Photohop do meu irmão e à ajuda de alguns amigos, essa semana consegui publicar o novo blog. Ainda faltam muitas coisas. A página "About Me" ainda não tem nada about me. A página de treinamentos, que vai falar sobre os cursos que ofereço ainda fala exatamente isso: "Essa página vai falar sobre os cursos que ofereço". Ainda estou instalando alguns plug-ins que vão ajudar em uma coisa aqui e outra ali. Mas o fato é que há dois dias do prazo final do suporte ao FTP, o novo blog já está no ar.

Esse post foi o último a ser contruído no Blogger com o objetivo principal de avisar àqueles que seguem o RSS original de que o endereço agora mudou. O novo RSS será provido em um novo endereço.

Eu não poderia terminar esse blog sem agraceder às pessoas que tiveram a paciência de me aturar com testes e dúvidas sobre HTML, CSS e sei-lá mais o que. Um muito obrigado aos meus amigos Lesma, Thiago Oliveira, Thiago Brito, meu irmão Kabloc, Willam, Francisco, à minha esposa Magda que migrou todos os comentários e a todos os outros que não me lembro agora (eu perturbei muita gente).

Se você não conhecia o blog antigo, aqui estão as páginas do velho aposentado.
Valeu!

C/C++: NULL vs 0

2010-04-22T01:49:11+00:00

Mais um assunto bacana que foi discutido na lista CPPBRASIL. O André fez algumas observações sobre o uso de NULL ou 0 e o Hugo complementou com informações bem interessantes. Essa informação é bem bacana para os novatos como eu que está tentando aprender essa complexa e poderosa linguagem que é o C++. Segue abaixo [...]

Concurrency Double Coverage

2010-04-21T22:13:56+00:00

This post is equivalent to 2 of them.

Here I'm pointing the materials for 2 talks I'd given about Concurrency:

Paralelismo com .NET Framework 4.0 - MSDN Brazil WebCast

Download Samples & Slides from this talk

Introduction to Visual C++ 10 Concurrency Runtime - 6. Encontro C&C++ Brasil

Download Samples & Slides from this talk

Both talks covered concurrency/parallel programming, of course.

The first one was about .NET Framework 4.0 and the new features including: Task Parallel Library, PLINQ, Concurrency Collections, and a lot of managed code and concurrency stuff. The samples was written in C#. During the Q&A section someone asked about the use of those features with UI. I put an extra sample covering this issue!

The second one was about C++, my number one favorite programming language, and concurrency. In fact, was about a Introduction to ConcRT, a concurrency runtime shipped with Visual C++ 10.

If you want to try these samples and amazing features for free, you can download the Visual C++ 10 Express and the other Visual Studio 10 tools.

Every post has a code. Thus, it isn't different:

Find Files (sequential and parallel) in C#:

using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using System.Collections.Concurrent;

namespace DotNet4_ParallelSamples
{
using dir = System.IO.Directory;

abstract class FileFinder
{
    public IEnumerable<string> FindFiles(string dir_path, string filenameHint)
    {
        Action<string> addItem;
        var filesFound = CreateResultBuffer(out addItem);
        FindFilesCore(dir_path, filenameHint, addItem);
        return filesFound;
    }

    protected string[] GetFiles(string dir_path)
    {
        var files = new string[0];
        try
        {
            files = dir.GetFiles(dir_path);
        }
        /* ignore */
        catch (UnauthorizedAccessException) { }
        catch (System.IO.IOException) { }
        /* ignore */

        return files;
    }

    protected string[] GetDirectories(string dir_path)
    {
        var directories = new string[0];
        try
        {
            directories = dir.GetDirectories(dir_path);
        }
        /* ignore */
        catch (UnauthorizedAccessException) { }
        catch (System.IO.IOException) { }
        /* ignore */

        return directories;
    }

    protected abstract IEnumerable<string> CreateResultBuffer(out Action<string> addFunc);

    protected abstract void FindFilesCore(string dir_path, string filenameHint, Action<string> addToResult);
}

class SequentialFileFinder : FileFinder
{
    protected override IEnumerable<string> CreateResultBuffer(out Action<string> addFunc)
    {
        var buffer = new List<string>();
        addFunc = buffer.Add;

        return buffer;
    }

    protected override void FindFilesCore(string dir_path, string filenameHint, Action<string> addToResult)
    {
        foreach (var file in GetFiles(dir_path))
        {
            if (file.Contains(filenameHint))
            {
                addToResult(file);
            }
        }

        foreach (var directory in GetDirectories(dir_path))
        {
            FindFilesCore(directory, filenameHint, addToResult);
        }
    }
}

class ParallelFileFinder : FileFinder
{
    protected override void FindFilesCore(string dir_path, string filenameHint, Action<string> addToResult)
    {
        Parallel.ForEach(GetFiles(dir_path), (file) =>
        {
            if (file.Contains(filenameHint))
            {
                addToResult(file);
            }
        });

        Parallel.ForEach(GetDirectories(dir_path), (directory) =>
        {
            FindFilesCore(directory, filenameHint, addToResult);
        });
    }

    protected override IEnumerable<string> CreateResultBuffer(out Action<string> addFunc)
    {
        var buffer = new ConcurrentBag<string>();
        addFunc = buffer.Add;

        return buffer;
    }
}
}

Find Files (sequential and parallel) in C++:

#include <windows.h>
#include <ppl.h>

using namespace Concurrency;

#include <list>
#include <string>
#include <algorithm>
#include <iostream>

using namespace std;

#include "_helper.hpp"

struct Directory
{
    static void GetDirectories( __in const wchar_t* path, __out list<wstring>& directories )
    {
        EnumIOItems( path, [&]( __in const WIN32_FIND_DATA& ffd )
        {
            if ( ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY && L'.' != ffd.cFileName[0] )
                directories.push_back( wstring( path ).append( ffd.cFileName ).append( L"\\" ) );
        });
    }

    static void GetFiles( __in const wchar_t* path, __out list<wstring>& files )
    {
        EnumIOItems( path, [&]( __in const WIN32_FIND_DATA& ffd )
        {
            if ( !(ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) )
                files.push_back( wstring( path ).append( ffd.cFileName ) );
        });
    }

private:
    template<class Function>
    static void EnumIOItems( __in const wchar_t* path, __in Function _Func )
    {
        WIN32_FIND_DATA ffd = { NULL };
        HANDLE hFind = FindFirstFile( wstring( path ).append(L"*").c_str(), &ffd );
        if ( INVALID_HANDLE_VALUE != hFind )
        {
            do _Func( ffd ); while( 0 != FindNextFile( hFind, &ffd ) );
            FindClose( hFind );
        }
    }
};

class FileFinder
{
public:
    typedef list<wstring> result_type;
    typedef result_type& result_type_ref;

    FileFinder(){}
    virtual ~FileFinder(){}

    void FindFiles( __in const wchar_t* path, __in const wchar_t* filenameHint, __out result_type_ref filesFound )
    {
        FindFilesCore( path, filenameHint, filesFound );
    }

protected:
    void GetFiles( __in const wchar_t* path, __out result_type_ref files ) const
    {
        Directory::GetFiles( path, files );
    }

    void GetDirectories( __in const wchar_t* path, __out result_type_ref directories ) const
    {
        Directory::GetDirectories( path, directories );
    }

    template<class Container, class Item> void add( Container& c, const Item& i ) const { c.push_back( i ); }

    virtual void FindFilesCore( __in const wchar_t* path, __in const wchar_t* filenameHint, __out result_type_ref filesFound ) const = 0;
};

class SequentialFileFinder : public FileFinder
{
protected:
    virtual void FindFilesCore( __in const wchar_t* path, __in const wchar_t* filenameHint, __out result_type_ref filesFound ) const
    {
        list<wstring> files;
        GetFiles( path, files );
        for_each( files.begin(), files.end(), [&]( __in const wstring& file )
        {
            if( wstring::npos != file.find( filenameHint ) )
                add( filesFound, file );
        } );

        list<wstring> directories;
        GetDirectories( path, directories );
        for_each( directories.begin(), directories.end(), [&]( __in const wstring& dir )
        {
            FindFilesCore( dir.c_str(), filenameHint, filesFound );
        } );
    }
};

class ParallelFileFinder : public FileFinder
{
protected:
    virtual void FindFilesCore( __in const wchar_t* path, __in const wchar_t* filenameHint, __out result_type_ref filesFound ) const
    {
        combinable<result_type> filesFound_partial;

        list<wstring> files;

        GetFiles( path, files );
        parallel_for_each( files.begin(), files.end(), [&]( __in const wstring& file )
        {
            if( wstring::npos != file.find( filenameHint ) )
                add( filesFound_partial.local(), file ); //<-
        } );

        join( filesFound_partial, filesFound ); //<-

        list<wstring> directories;
        GetDirectories( path, directories );
        parallel_for_each( directories.begin(), directories.end(), [&]( __in const wstring& dir )
        {
            FindFilesCore( dir.c_str(), filenameHint, filesFound );
        } );
    }

private:
    void join( __in combinable<result_type>& filesFound_partial, __out result_type_ref filesFound ) const
    {
        filesFound_partial.combine_each( [&](result_type_ref local)
        {
            copy( local.begin(), local.end(), back_insert_iterator<result_type>( filesFound ) );
            local.clear();
        } );
    }
};

Typedef arcaico

2010-04-20T12:26:03+00:00

A API do Windows geralmente prima pela excelência em maus exemplos. A Notação Húngara e o Typedef Arcaico são duas técnicas que, por motivos históricos, são usados a torto e a direito pelos códigos de exemplo.

Já foi escrito muita coisa sobre os prós e contras da notação húngara. Já o typedef arcaico, esse pedacinho imprestável de código, ficou esquecido, e hoje em dia traz mais dúvidas na cabeça dos principiantes em C++ do que deveria. Para tentar desobscurecer os mitos e fatos, vamos tentar explicar o que significa essa construção tão atípica, mas comum no dia-a-dia.

Vejamos um exemplo típico desse pequeno Frankenstein semântico:

typedef struct _MINHASTRUCT {
   int x;
   int y;
}
MINHASTRUCT, *LPMINHASTRUCT;

Bom, eu nem sei por onde começar. Talvez pelo conceito de typedef.

Typedefs

Um typedef, basicamente, é um apelido. Você informa um tipo e define "outro tipo".

typedef <tipo> apelido;

O <tipo> é tudo que fica entre o typedef e o novo nome, que deve ser um identificador válido na linguagem. Por exemplo, a empresa onde trabalho fez um typedef informal do meu nome:

typedef Wanderley Caloni Wandeco;

Se, futuramente, eu sair da empresa e entrar outro "Wanderley alguma-coisa", será possível usar o apelido novamente, bastando alterar o typedef:

typedef Wanderley Cardoso Wandeco;

Bom, "outro tipo" é forma de dizer. Isso é uma descrição errônea em muitos livros. De fato, o compilador enxerga o mesmo tipo com outro nome, daí chamarmos o typedef de apelido, mesmo.

/** @file dois_apelidos.cpp */
#include <iostream>
 
using namespace std;
 
struct Struct
{
   int x;
   int y;
};
 
typedef Struct Struct1;
typedef Struct Struct2;
 
int main()
{
   Struct1 s1;
   Struct2 s2;
 
   cout << typeid(s1).name() << endl;
   cout << typeid(s2).name() << endl;
}

C:\Tests>cl /EHsc dois_apelidos.cpp
...
/out:dois_apelidos.exe
dois_apelidos.obj

C:\Tests>dois_apelidos.exe
struct Struct
struct Struct

Granularidade dos tipos

Tipos simples são fáceis de entender porque possuem seus símbolos no mesmo lugar:

int x;
char c;
long p;

Já os tipos um pouco mais complicados permite alguma mudança aqui e acolá:

int* x;
char *y;
long * p;

Essa liberdade da linguagem, mesmo sendo um recurso útil, pode ser bem nocivo dependendo de quem olha o código:

int x, y; // dois inteiros
int * x, y; // um ponteiro para inteiro e um inteiro
int x, *y; // um inteiro e um ponteiro para inteiro
int *x, y; // um ponteiro para inteiro e um inteiro

Em algumas formas da sintaxe, além de ser inevitável, gera bastante desconfiança:

// Um ponteiro para função que recebe dois inteiros e não retorna nada.
typedef void (*FP)(int, int);

// Um ponteiro para função que recebe dois inteiros e não retorna nada.
void (*)(int, int);

// Um cast para ponteiro para função que recebe dois inteiros e não retorna nada.
( ( void (*)(int, int) ) pf )(x, y);

#include <iostream>
 
void func(int x, int y)
{
   std::cout << x << '-' << y << '\n';
}
 
int main()
{
   void* pf = func;
   ( ( void (*)(int, int) ) pf )(3, 14);
}

Structs em C++

Antigamente, as structs eram construções em C que definiam um agregado de tipos primitivos (ou outras structs) e que poderiam gerar variáveis desse tipo em qualquer lugar, desde que informado seu nome e que se tratasse de uma struct:

/** @file structs.cpp */
struct MyStruct { int x, y; };
 
void func1()
{
   struct MyStruct ms;
   //...
}
 
void func2(struct MyStruct msa)
{
   //...
}
 
int main()
{
   struct MyStruct ms;
   func2(ms);
}

Para evitar toda essa digitação, os programadores usavam um pequeno truque criando um apelido para a estrutura, e usavam o apelido no lugar da struct (apesar de ambas representarem a mesma coisa).

struct MyStruct { int x, y; };
typedef struct MyStruct MS;

typedef struct MyStruct { int x, y; } MS;
struct MyStruct ms1; // ainda prolixo
MS ms2; // mais simples

Com a definição da linguagem C++ padrão, e mais moderna, essa antiguidade foi removida, apesar de ainda suportada. Era possível usar apenas o nome do struct como seu tipo:

/** @file structs.cpp */
struct MyStruct { int x, y; };
 
void func1()
{
   /*struct*/ MyStruct ms;
   //...
}
 
void func2(/*struct*/ MyStruct msa)
{
   //...
}
 
int main()
{
   /*struct*/ MyStruct ms;
   func2(ms);
}

Porém, isso vai um pouco além de quando a Microsoft começou a fazer código para seu sistema operacional. Naquela época, o padrão ainda estava se formando e existia mais ou menos um consenso de como seria a linguagem C++ (sem muitas alterações do que de fato a linguagem C já era). De qualquer forma, a linguagem C imperava bem mais que C++. Dessa forma, já era bem formada a ideia de como declarar uma struct: a forma antiga.

typedef struct _MINHASTRUCT {
   int x;
   int y;
}
MINHASTRUCT, *LPMINHASTRUCT;

Além do uso controverso do _sublinhado para nomear entidades (que no padrão foi recomendado que se reservasse aos nomes internos da biblioteca-padrão) e do uso de MAÍUSCULAS_NO_NOME (historicamente atribuído a nomes definidos no pré-processador), o uso do typedef atracado a um struct era muito difundido. E ficou ainda mais depois que a API do Windows foi publicada com essas definições.

Como fazer,então?

Ora, do mesmo jeito que é feito há vinte anos: sem typedefs. O próprio paradigma da linguagem, independente de padrões de APIs, de sistemas operacionais ou de projetos específicos já orienta o programador para entender o que o espera na leitura de um código-fonte qualquer. Qualquer pessoa que aprendeu o básico do básico sobre ponteiros e structs consegue ler o código abaixo:

// Papai, o que que é isso?
// Ora, filho, apenas uma definição de estrutura!
//
struct MinhaStruct {
   int x;
   int y;
};
 
// muitas linhas abaixo...
 
void func(MinhaStruct* ms)
{
   // asterisco significa ponteiro para MinhaStruct!
}
 
int main()
{
   MinhaStruct ms;
   func(&ms);
}

Agora, para entender a forma antiga, ou você se baseou no copy&paste dos modelos Microsoftianos, ou seja, decoreba, ou você é PhD em Linguagem C/C++ e padrões históricos de linguagens legadas. Se não é, deveria começar o curso agora.

// Papai, o que que é isso?
// Ora, filho, apenas uma definição de sinônimo da struct
// _MINHASTRUCT, cujo nome não é usado, para dois nomes
// em maiúsculas, apesar se não serem defines, com uma
// nomenclatura de ponteiro que eu nunca vi na vida (obs: 
// papai programa em um sistema não-Windows).
//
typedef struct _MINHASTRUCT {
   int x;
   int y;
}
MINHASTRUCT, *LPMINHASTRUCT;
 
// muitas linhas abaixo...
 
void func(LPMINHASTRUCT ms)
{
   // o que diabos é um LP, mesmo?
}
 
int main()
{
   MINHASTRUCT ms;
   func(&ms);
}

Da mesma forma, o uso de uma estrutura simples de tipos mantém a lista de nomes do seu projeto limpa e clara. Compare o visualizador de classes em projetos Windows com algo mais C++ para ter uma ideia.

É claro, essa é apenas uma sugestão. Existem vantagens em sua utilização. Existe alguma vantagem no modo antigo? Existe: a Microsoft usa, e talvez mais pessoas usem. Basta a você decidir qual deve ser o melhor caminho.

Atualização

De acordo com o leitor Adriano dos Santos Fernandes, a obrigatoriedade do nome struct após seu nome continua valendo para a linguagem C padrão, assim como no compilador GCC ocorre um erro ao tentar omiti-la. Apenas na linguagem C++ essa obrigatoriedade não existe mais.

Eu não fiz meus testes, mas confio no diagnóstico de nosso amigo. A maior falha do artigo, no entanto, é usar a linguagem C como base, quando na verdade ele deveria falar sobre o uso desses typedefs em C++. Esse erro também foi corrigido no original.

0xc0de

2010-04-05T18:54:24+00:00

Recentemente resolvi fazer alguns testes relacionados a inicialização de objetos em C++ em diferentes ambientes. Tive algumas surpresas…

O padrão C++ define três tipos de inicialização:

zero-initialization – Neste texto traduzido como inicialização por zeros.
default-initialization – Traduzido como inicialização padrão.
value-initialization – Traduzido como inicialização por valor

O significado de cada um é explicado detalhadamente [§8.5.5]. Mas a linguagem e formalismo utilizados em documentos técnicos normalmente não são os mais triviais possíveis. Portanto, não é raro aparecerem algumas dúvidas.

O caso em que estava interessado é relativamente simples e abrange apenas um sub-conjunto das regras de inicialização. Colocando em termos práticos, queria analisar qual seria o valor de um membro inteiro de um struct em situações distintas.

Além de coisas mais simples e conhecidas como chamadas convencionais a construtores, as informações do padrão que considerei pertinentes para o seguinte trecho de código são as seguintes:

Um objeto construído através de um par vazio de parêntesis deve passar por uma inicialização por valor [§ 8.5.7]. Note que isso se aplica a uma inicialização do tipo T * t = new T(); [§ 5.3.4] ou até mesmo do tipo T();[§ 5.2.3].
Quando um objeto de tipo não-POD (Plain Old Data) não tem nenhum inicializador ele deve passar por uma inicialização padrão. Esse é o caso, por exemplo, de uma expressão como T * t = new T; ou T t;. No entanto, se o objeto for de tipo POD ele e seus sub-objetos não passam por inicialização alguma e, consequentemente, têm valor indeterminado [§ 8.5.9].
Uma inicialização padrão de um objeto tipo POD como int (não para arrays) resulta em uma inicialização por zeros [§ 8.5.5].
Uma inicialização por valor de um objeto de um tipo classe (excluindo union) promove uma inicialização por valor de seus membros não-estáticos e classes bases.

struct PlainOldData //POD
{
  int id_;
};

struct NonPOD_CompilerCtor
{
  int id() const { return id_; }

private:
  int id_;
};

struct NonPOD_UserCtor
{
  NonPOD_UserCtor() : id_() {}
  int id() const { return id_; }

private:
  int id_;
};

O programinha que escrevi apenas cria objetos dos tipos definidos acima com duas sintaxes diferentes. Em seguinda, inspeciono os valores do membro id_.

int main()
{
  PlainOldData * a = new PlainOldData;
  NonPOD_CompilerCtor * b = new NonPOD_CompilerCtor;
  NonPOD_UserCtor * c = new NonPOD_UserCtor;

  //...

  PlainOldData * d = new PlainOldData();
  NonPOD_CompilerCtor * e = new NonPOD_CompilerCtor();
  NonPOD_UserCtor * f = new NonPOD_UserCtor();

  //...
}

Os valores que esperava para o membro id_ são os seguintes:

a – O objeto é criado sem parêntesis e o tipo é POD. Logo, não há inicialização e o valor de id_ é indeterminado.
b – O objeto é criado sem parêntesis e o tipo é não-POD. Logo, a inicialização é padrão. No entanto, o construtor é o gerado pelo compilador, o qual não faz inicialização de nenhum membro. Portanto, o valor de id_ é indeterminado.
c – O objeto é criado sem parêntesis e o tipo é não-POD. Novamente, temos inicialização padrão. Agora, com a diferença de que existe um construtor definido pelo usuário que inicializa explicitamente id_. Este, então, sofre inicialização por valor, a qual resulta em inicialização por zeros devido ao fato de int ser POD.
d – O objeto é criado com parêntesis vazios e, assim como nos outros dois casos abaixo, a inicialização é por valor. Este caso se trata de um POD. Logo, a inicialização por valor resulta diretamente em inicialização por zeros.
e – Como dito acima, o objeto sofre inicialização por valor, já que foi criado com parêntesis vazios. O membro id_ também sofre inicialização por valor que, devido ao fato de se tratar de um POD, resulta em inicialização por zeros.
f – Novamente, inicialização por valor. Naturalmente, o construtor definido pelo usuário é invocado. Este inicializa por valor o membro id_, que por ser um POD sofre inicialização por zeros.

Testando com compiladores diferentes obtive os seguintes resultados.

Compilador	a	b	c	d	e	f
G++ 4.2.4	0	0	0	0	0	0
Mingw – G++ 4.4.0	Indeterm.	Indeterm.	0	0	0	0
VC++ 2008 Express	Indeterm.	Indeterm.	0	0	0	0
Digital Mars 8.5.1	0	0	0	Indeterm.	0	0

Para completar a avaliação também resolvi utilizar sintaxes correspondentes às usadas acima só que com alocação na pilha.

int main()
{
  PlainOldData aa;
  NonPOD_CompilerCtor bb;
  NonPOD_UserCtor cc;

  //...

  PlainOldData const& dd = PlainOldData();
  NonPOD_CompilerCtor const& ee = NonPOD_CompilerCtor();
  NonPOD_UserCtor const& ff = NonPOD_UserCtor();

  //...
}

Já que nesses casos o fator determinante na inicialização é a presença ou não dos parêntesis, esperava obter exatamente os mesmos resultados do código anterior. Apenas uma observação: As referências para const dos últimos três casos são apenas uma estratégia artificial para testar a inicialização através da expressão X(), já que X x(); é na verdade a declaração de uma função que não recebe parâmetros e retorna X.

Desta vez os resultados foram os seguintes:

Compilador	aa	bb	cc	dd	ee	ff
G++ 4.2.4	Indeterm.	Indeterm.	0	0	0	0
Mingw – G++ 4.4.0	Indeterm.	Indeterm.	0	0	0	0
VC++ 2008 Express	Indeterm.	Indeterm.	0	0	Indeterm.	0
Digital Mars 8.5.1	Indeterm.	Indeterm.	0	Indeterm.	0	0

Bom, como pode ser visto encontrei muitas variações de comportamento entre os compiladores. Espero não ter cometido alguma interpretação errônea pelos meandros do padrão, mas os únicos compiladores que foram conformantes na primeira leva de testes foram o G++ 4.4.0 (Mingw) e o Visual C++ 2008. Já para a segunda parte, na qual esperava exatamente os mesmos resultados, apenas o G++ 4.4.0.

mysql.c (conectando ao MySQL via C)

2010-03-30T03:39:24+00:00

Abaixo um programinha simples de exemplo, sobre como acessar o MySQL via C. A idéia é bem simpls, mas, bem útil se você estiver aprendendo, um dos piores problemas será como colocar os dados recebidos do MySQL em uma estrutura de dados (array) para usar posteriormente, essa é a parte difícil, que fiz, usando “ponteiro [...]

Entrevista com o criador do C++ em 1998 (Bjarne Stroustrup)

2010-03-30T02:03:08+00:00

Em 1 de Janeiro de 1998, Bjarne Strustrup (criador do C++) deu essa entrevista. Lembrando que, em 1998 ainda não tinha sido implementado os “templates” do C++ que foram incluídos somente em 2001. Original do texto abaixo encontra-se aqui. I would like to find the proper credit for the material below. Please mail me if [...]

Sistemas de Tempo Real – Part 1

2010-03-16T02:33:38+00:00

Neste post vou falar um pouco sobre Sistemas de Tempo Real, as principais motivações para sua utilização, sua arquitetura básica e alguns critérios para a escolha de um RTOS disponível no mercado.

Sexto Encontro de Programadores C/C++

2010-03-10T11:55:35+00:00

Começo de ano é sempre a mesma correria. Depois que a gente começa a se acostumar com a idéia de que o feriadão de Natal e Ano Novo acabaram, logo vem o carnaval e desanda tudo. Aproveitei este início de ano para tirar merecidas férias, já que finalmente meu curso de Engenharia da Computação terminou. Como um belo start para minha reintegração à sociedade, nada melhor que uma viajem ao nordeste brasileiro. Semanas antes desta viajem fiquei sabendo do novo encontro da comunidade de programadores C/C++. Por causa da viagem eu perderia o evento.

Um mês se passou e semana passada vi que o evento foi adiado para o próximo dia seis de março. Muito boa notícia já que além de poder participar do evento também vou falar um pouquinho. Já participei de outro encontro de programadores e fiquei muito feliz de poder falar para tantas pessoas sobre esse assunto tão misterioso para muitos, que é o desenvolvimento de drivers para Windows.

Sob meu ponto de vista os resultados foram muito bons. A palestra deu uma introdução ao assunto de desenvolvimento de drivers e obviamente os 60 minutos de palestra não foram suficientes para explicar o assunto com detalhes, mas foi interessante mostrar a ponta do iceberg e poder responder a algumas perguntas dos presentes. Eu escrevi um post que comenta sobre o encontro, mas recomendo o post do meu amigo Lesma que ficou muito bom.

Lidando com Memória Virtual em Drivers

Bem, neste novo encontro não vou dar novamente uma introdução ao assunto, mas vou comentar sobre algumas carasterísticas e curiosidades sobre Memória Virtual no desenvolvimento de drivers. Entenda que não vou fazer um resumo do capítulo 9 do Windows Internals, "Memory Management" que fala sobre Page Table Entries e Working Sets, mas sim demonstrar que, diferentes de uma aplicação User-Mode, drivers precisam estar cientes dos conceitos fundamentais de memória virtual e paginação, controlando paginação de objetos e atendendo à requisítos de paginação de memória e espaço de endereçamento.

Os tópicos a serem discutidos na palestra serão os seguintes:

Overview de Memória Virtual e Paginação.
Operações de I/O e manipulação de Buffers.
Prioridade de thread e acesso à memória.
Pools de alocação, Tags e Quotas.
Evitando Fragmentação.
Drivers no caminho da paginação.
Controlando paginação de funções.
Obtendo endereços reais de memória.
Dispositivos de acesso direto à memória (DMA).
Recursos do Driver Verifier.
Hands on: Operações de memórias por drivers no WinDbg.
Dúvidas.

Esta é a página oficial do evento e as inscrições estão abertas. Até lá!

Download dos slides

techberto

2010-03-08T00:48:15+00:00

Em 2007 dois pesquisadores britânicos teorizaram um dispositivo que eles chamaram de ”alçapão de arco-íris”, sendo um dispositivo composto por uma lenteque seria responsável pela reflexão, dispersão e refração de um feixe de luz para o interior do artefato que teria uma placa com várias camadas de espelhos de metamateriais que poderia capturar o feixe de luz, não permitindo sua dispersão:

Stopping light in metamaterials: the trapped rainbow

Na época vários grupos ao redor do mundo, acreditando na teoria trabalharam alucinadamente tentando criar um protótipo funcional deste dispositivo e no final de 2009 um grupo de pesquisadores americanos conseguiu obter sucesso e com um aparato muito simples provaram o conceito da “armadilha de arco-íris”, demonstrando que os físicos britânicos estavam certos:

Rainbow trapped for the first time

Quando comentei este feito com um colega pela primeira vez, logo que via a notícia na semana que ela foi publicada na New Scientist, ele fez aquele clássico comentário: este pessoal não tem nada mais importante para fazer?

Bem, esta técnica poderá ser útil para armazenar informações de forma puramente ótica, algo que irá revolucionar a computação (e talvez a vida) no futuro, eliminando a necessidade de conversões de sinais óticos em eletrônicos, facilitando o processo de manipulação de fótons e proporcionando a criação de meios de armazenamento de informações revolucionário. E considerando que em 2009 também surgiu o primeiro processador quântico fotônico autêntico podemos elucubrar que parte do futuro da computação está na fotônica e esta nova descoberta é certamento um grande marco.

Quer algo mais útil do que isto?

Ruminando e divagando sobre este assunto com um amigo este final de semana, ele lembrou do filme Minority Report e de um cartão de armazenamento que parecia que as imagens estavam armazenadas de modo fotônico, visto que elas podiam ser parcialmente vistas sem mesmo estar no seu respectivo driver de leitura.

Com a evolução das pesquisas do grafeno, dos metamateriais e outros daqui a alguns anos silício será coisa do passado, se bobear armazenamento magnético também e por consequencias do entrelaçamento quântico a velocidade da luz irá parecer velocidade tartarugal, imaginou como será a computação e o futuro das telecomunicações?

No final de 2008, escrevi um post onde eu brincava que em 2050 “telepatia sintética” seria coisa do passado, bom, o DARPA tem financiado pesquisas nesta área e isto da tem a ver com ESP, visto que a tecnologia é puramente baseada em neurociência e telecomunicações, sendo-se que o artefato que possibilitará tal feito é puramente um dispositivo de neuroengenharia, área que tende a evoluir muito no futuro e aposto que vários dos “neuroengenheiros” serão nascerão a partir do fascínio pelos brinquedos Mindflex e o Star Wars Force Trainer.

Mas o quê a armadilha de arco-íris e a q-telepatia tem em comum? A resposta é: computação quântica. A neuroengenharia continuará presente, porém o processador quântico será peça fundamental.

E breve, os neurohackers já não serão mais atores da ficção cyberpunk e sim do novo contexto neurotecnológico do balaio de gato que será o admirável mundo novo da computação, fico imaginando a segunda (ou será terceira?) geração que será os q-neurohackers.

PS3 e o bug do ano bissexto

2010-03-05T02:12:34+00:00

Como profissional da área de tecnologia, sou um leitor assíduo de notícias da área. Gosto em especial de dois sites, o Gizmodo [1] e o Engadget [2]. Na segunda pela manhã uma notícia me chamou a atenção, milhões de videogames PlayStation 3 da Sony haviam parado de funcionar da noite para o dia. No decorrer do dia, descobriu-se que o problema estava no relógio interno do aparelho, que identificou 2010 como um ano bissexto, e passou do dia 28/02 para 29/02 ao invés de 01/03. Como diversas funções do videogame dependiam do valor correto da data do sistema para funcionar, o aparelho começou a apresentar vários problemas.

Namespaces: colocando cada coisa em seu lugar

2010-03-02T23:22:55+00:00

Evitando conflitos de nomes namespace é uma palavra reservada do C++ que implementa um mecanismo capaz de expressar agrupamento lógico. Em outras palavras, se um conjunto de declarações estão logicamente associadas de acordo com algum critério, elas podem ser colocadas juntas no mesmo namespace para expressar este fato. Um namespace também pode ser chamado de um [...]

Escrevendo Filtros

2010-02-22T16:38:45+00:00

Vamos brincar de algo mais interessante agora. Obviamente ainda vamos dar passos pequenos para não nos perder com tantos detalhes. Hoje falarei sobre filtros de drivers. O IoManager do Windows nos permite adicionar funcionalidade a determinados drivers sem que tenhamos que substituí-lo. Um exemplo clássico seria um driver de criptografia de arquivos. Você não precisa escrever um novo driver de file system para que se tenha tal funcionalidade. Você pode simplesmente escrever um filtro que ficaria entre o driver de file system e o restante do sistema.

Na figura abaixo podemos observar o fluxo de IRPs que vão do IoManager para um certo driver, um filtro é instalado sobre o driver existente e passa a receber as IRPs no lugar do driver original. Com isso o filtro tem a oportunidade de alterar os parâmetros das IRPs recebidas, ou logar a atividade do driver original, ou duplicar solicitações do sistema para esse driver, ou mesmo negar serviço do driver original.

Numa operação de escrita, um filtro poderia criptografar os dados antes de enviá-los ao driver original, e de maneira similar, numa operação de leitura o filtro poderia decriptografar dados antes de entregá-los ao sistema.

Ainda não vai ser desta vez que construiremos um filtro de criptografia de file system. Filtros de criptografia de arquivos em tempo real estão entre os drivers mais complexos a serem escritos. Vamos escolher um driver mais simples, pra não dizer um bem besta, para aplicar os conceitos básicos demonstrados aqui.

Por falar em driver besta, vamos utilizar o driver deste post que já foi visto aqui. Este driver simplesmente armazena uma lista de strings enviadas por uma aplicação em operações de escrita. Tais strings são retornadas à aplicação em operações de leituras.

Escrevendo a DriverEntry

Como vimos neste outro post, uma das das coisas que a função DriverEntry() faz num driver comum é setar as Dispatch Routines que o driver vai atender para certo dispositivo. Para isso deve-se preencher o array de Major Functions que fica na estrutura DRIVER_OBJECT.

    //-f--> Seta as dispatch routines do driver.
    pDriverObj->MajorFunction[IRP_MJ_CREATE] = OnCreate;
    pDriverObj->MajorFunction[IRP_MJ_CLEANUP] = OnCleanup;
    pDriverObj->MajorFunction[IRP_MJ_CLOSE] = OnClose;
    pDriverObj->MajorFunction[IRP_MJ_READ] = OnRead;
    pDriverObj->MajorFunction[IRP_MJ_WRITE] = OnWrite;

No caso do nosso filtro de exemplo, queremos apenas monitorar a atividade do driver ao qual estamos atachados, dessa forma teremos sempre que encaminhar quaisquer IRPs recebidas ao driver de baixo. Uma forma simples e comum de fazer isso é setar todas dispath routines para uma única função. Essa função se encarrega de simplesmente logar a solicitação recebida e passá-la a diante.

Se dermos uma olhada na definicão de IRP_MJ_CREATE e seus amigos, veremos o seguinte trecho do arquivo wdm.h.

//
// Define the major function codes for IRPs.
//
 
 
#define IRP_MJ_CREATE                   0x00
#define IRP_MJ_CREATE_NAMED_PIPE        0x01
#define IRP_MJ_CLOSE                    0x02
#define IRP_MJ_READ                     0x03
#define IRP_MJ_WRITE                    0x04
#define IRP_MJ_QUERY_INFORMATION        0x05
#define IRP_MJ_SET_INFORMATION          0x06
#define IRP_MJ_QUERY_EA                 0x07
#define IRP_MJ_SET_EA                   0x08
#define IRP_MJ_FLUSH_BUFFERS            0x09
#define IRP_MJ_QUERY_VOLUME_INFORMATION 0x0a
#define IRP_MJ_SET_VOLUME_INFORMATION   0x0b
#define IRP_MJ_DIRECTORY_CONTROL        0x0c
#define IRP_MJ_FILE_SYSTEM_CONTROL      0x0d
#define IRP_MJ_DEVICE_CONTROL           0x0e
#define IRP_MJ_INTERNAL_DEVICE_CONTROL  0x0f
#define IRP_MJ_SHUTDOWN                 0x10
#define IRP_MJ_LOCK_CONTROL             0x11
#define IRP_MJ_CLEANUP                  0x12
#define IRP_MJ_CREATE_MAILSLOT          0x13
#define IRP_MJ_QUERY_SECURITY           0x14
#define IRP_MJ_SET_SECURITY             0x15
#define IRP_MJ_POWER                    0x16
#define IRP_MJ_SYSTEM_CONTROL           0x17
#define IRP_MJ_DEVICE_CHANGE            0x18
#define IRP_MJ_QUERY_QUOTA              0x19
#define IRP_MJ_SET_QUOTA                0x1a
#define IRP_MJ_PNP                      0x1b
#define IRP_MJ_PNP_POWER                IRP_MJ_PNP      // Obsolete....
#define IRP_MJ_MAXIMUM_FUNCTION         0x1b

Note que existe uma definição especial, a IRP_MJ_MAXIMUM_FUNCTION, que indica o índice máximo da tabela de dispatch rotines. Utilizaremos um loop simples para fazer com que todas rotinas em nossa tabela aponte para uma única rotina que daremos o nome de OnForwardDispatch.

    //-f--> Seta todas as dispatch routines do driver para
    //      uma que encaminhe a IRP para o driver original.
    for (i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++)
        pDriverObj->MajorFunction[i] = OnForwardDispatch;

Veremos a implementação dessa rotina mais tarde. O próximo passo que daremos aqui é localizar o device ao qual vamos nos atachar. Para fazer isso, usaremos a rotina IoGetDeviceObjectPointer(). Ela basicamente recebe o nome do device e nos retorna uma referência para ele.

NTSTATUS 
  IoGetDeviceObjectPointer(
    IN PUNICODE_STRING  ObjectName,
    IN ACCESS_MASK  DesiredAccess,
    OUT PFILE_OBJECT  *FileObject,
    OUT PDEVICE_OBJECT  *DeviceObject
    );

Observe que são dois os parâmetros de saída dessa rotina. Além do ponteiro para o device object ainda recebemos um ponteiro para um file object. Já ví algumas pessoas fazerem confusão com estes dois parâmetros, então vou dar alguma ênfase nisso.

O ponteiro para o file object representa uma conexão criada entre seu driver e o device que você abriu. Como vimos neste post, um file object é criado para respresentar conexões entre aplicações user mode e seu driver. Aplicações usam esse file object através do handle obtido na chamada à rotina CreateFile(). Aqui temos algo similar, mas apenas o Kernel foi envolvido. Isso significa que se você quizesse, você poderia lançar IRPs para o device solicitando operações como uma aplicação faria, mas não veremos isso hoje, ainda temos um filtro para terminar.

A grande confusão referente a estes dois parâmetros é com relação às referências entre os objetos. Na documentação vemos que o chamador desta rotina deverá liberar a referência que ganhou quando o device não for mais utilizado. Fazemos isso simplesmente usando a rotina ObDereferenceObject().

VOID 
  ObDereferenceObject(
    IN PVOID  Object
    );

"Já sei! Como estamos obtendo uma referência para um device object, então devo passar o ponteiro do device object. Certo?"

Er... Na verdade não. O file object é uma referência indireta ao device object. Conforme a figura abaixo, se imaginarmos que os contadores de referência apenas dizem respeito às nossas referências, quando chamarmos ObDereferenceObject() para o file object, seu contador de referência cairia para zero e uma nova chamada para ObDeferenceObject() seria feita indiretamente para o device object, fazendo com que seu contador de referência também caisse para zero destruindo o objeto.

Depois de obter o ponteiro para o device destino, teremos que criar nosso próprio device, o qual receberá as IRPs no lugar do device original. Para isso ainda usaremos a rotina IoCreateDevice() como faziamos com drivers, mas com algumas diferenças.

A primeira diferença é que seu device normalmente não tem nome. É possível criar filtros com nomes, mas isso pode gerar uma falha de segurança. Isso acontece pois quando um nome é consultado no Object Manager, suas regras de segurança são avaliadas. Quando criamos um filtro com nome, criamos a possibilidade de o mesmo objeto ser obtido por um nome diferente e que pode ter regras menos restritivas de segurança. Mas esse é outro assunto.

Quando criamos um device, precisamos informar o tamanho do device extension.

"O que vem a ser um device extension?"

Device extension é simplesmente um espaço de memória que está associada ao device object. Tal espaço normalmente mantém informações que dizem respeito ao device. O endereço do device ao qual estamos atachados normalmente fica no device extension. Desta forma, podemos definir que nosso device extension deve conter a seguinte estrutura.

//-f--> Nosso device externsion conterá apenas o endereço
//      do device ao qual estamos atachados.
typedef struct _DEVICE_EXTENSION
{
    PDEVICE_OBJECT  pNextDeviceObj;
 
} DEVICE_EXTENSION, *PDEVICE_EXTENSION;

Depois de criar nosso device object, configuramos o método de I/O copiando os bits DO_BUFFERED_IO e DO_DIRECT_IO. Se você não se lembra destes bits, dê uma olhada neste post. O filtro deve propagar a escolha do driver original e o driver tem o compromisso de não mudar método durante seu tempo de vida.

Agora estamos prontos para nos atachar ao device escolhido, e faremos isso utilizando a rotina IoAttachDeviceToDeviceStackSafe() para fazer nosso device entrar na pilha de dispositivos.

NTSTATUS
  IoAttachDeviceToDeviceStackSafe(
    IN PDEVICE_OBJECT  SourceDevice,
    IN PDEVICE_OBJECT  TargetDevice,
    IN OUT PDEVICE_OBJECT  *AttachedToDeviceObject 
    );

Com esta chamada obteremos o ponteiro do device ao qual estaremos atachados, esse device será o próximo device que receberá a IRP depois que você a passar a diante.

"Mas Fernando, nós já não temos o ponteiro do device de destino?"

Muito bem, quando você obtém o ponteiro para um device, você teoricamente não sabe se existem filtros já atachados sobre ele. O ponteiro que você recebe nesta rotina pode não ser o ponteiro para o device de destino. Na figura abaixo podemos entender como essa relação acontece.

"Fernando, existe uma versão unsafe desta rotina?"

Na verdade existe, a IoAttachDeviceToDeviceStack().

PDEVICE_OBJECT 
  IoAttachDeviceToDeviceStack(
    IN PDEVICE_OBJECT  SourceDevice,
    IN PDEVICE_OBJECT  TargetDevice
    );

Ela é considerada unsafe por causa de uma pequena janela de tempo que pode causar um race condition. Repare que a diferença entre estas rotinas é a forma de obter o endereço do próximo device. Na versão original, este endereço é obtido pelo retorno na função. Se colocarmos essa função para rodar em câmera lenta veremos os seguintes passos.

Seu device é atachado à pilha de dispositivos.
O endereço do próximo device é retornado pela função.
Seu driver recebe este endereço no retorno da função e atualiza o device extension.
IRPs começam a chegar e seu driver às encaminham para o próximo device da lista.

Tudo parece lindo e até dá a impressão de que tudo vai funcionar muito bem em qualquer situação, mas desenvolvedor de driver é um bixo treinado para buscar race conditions. Dê mais uma olhada na sequência, mas agora em câmera super lenta. Com essa câmera super lenta agora podemos observar os passos que podem ocorrer entre os passos 2 e 3.

Seu device é atachado à lista de dispositivos.
O endereço do próximo device é retornado pela função.
1. Sua thread é interrompida e uma IRP lançada por uma aplicação que roda em paralelo começa sua viagem por essa pilha de dispositivos.
2. Seu device, que já está atachado, recebe a IRP e tenta encaminhá-la ao device de baixo.
3. Oops! Nosso device extension ainda não foi atualizado com tal endereço.
4. Seu driver se lembra de quando era uma criança e de tudo o que vivera até ali.
5. Ele decide entrar de vez naquela dança e enviar a IRP para um device cujo ponteiro ainda é NULL causando um BSOD.
"Jeremias, eu sou homem. Coisa que você não é e não atiro pelas costas não..."

Enfim, entenda que mesmo que você utilize o retorno da rotina IoAttachDeviceToDeviceStack() diretamente para atualizar seu device extension, ainda assim existe uma janela de tempo em que seu device estará atachado, mas que o valor ainda não foi atualizado no device extension. Isso porque o valor de retorno de uma rotina vem por um registrador. Pegar o valor desse registrador e atualizar uma variável ainda dá chances para o azar.

    //-f--> ----==== NÃO COPIE ISSO ====----
    //      Aqui ainda temos uma janela de tempo entre o device ser
    //      atachado e o valor de pNextDeviceObj ser atualizado.
    pDeviceExt->pNextDeviceObj = IoAttachDeviceToDeviceStack(pMyDeviceObj,
                                                             pTargetDeviceObj);

A rotina IoAttachDeviceToDeviceStackSafe() faz o sistema interromper o fluxo de IRPs nesta pilha até que a variável apontada pelo ponteiro de saída seja atualizado. Por essa razão, o endereço passado nesta rotina deve ser o endereço final da variável onde este valor será armazenado, que em nosso caso é pDeviceExt->pNextDeviceObj sem passar por variáveis intermediárias.

Esses detalhes são importantes e farão você entender que usar a versão safe desta rotina não é garantia de que tudo dará certo. Imagine que usando a versão safe você receba o endereço do próximo device em uma variável local e depois atualize seu device extension. Esse é um daqueles típicos casos que é necessário substituir aquele componente que fica entre o teclado e a cadeira.

Acha preciosismo? Tente ler o capítulo 5 do livro "Programming the Microsoft Windows Driver Model" onde Walter Oney fala sobre como lidar com cancelamento de IRPs.

Depois de atacharmos nosso device já podemos liberar a referência obtida por IoGetDeviceObjectPointer() utilizando a rotina ObDereferenceObject(), já que a rotina IoAttachDeviceToDeviceStackSafe() já garantiu a referência até que essa ligação seja desfeita.

Muito bem. Pra quem não conseguiu entender quase nada do que eu disse, segue o código fonte da implementação da nossa DriverEntry() de exemplo. Sabe como é cabeça de programador, as vezes um if vale mais que mil páginas de explicação.

/****
***     DriverEntry
**
**      Ponto de entrada do driver.
**      Bem vindo ao inferno.
*/
extern "C"
NTSTATUS
DriverEntry(IN PDRIVER_OBJECT  pDriverObj,
            IN PUNICODE_STRING pusRegistryPath)
{
    NTSTATUS            nts;
    PDEVICE_OBJECT      pMyDeviceObj;
    int                 i;
    UNICODE_STRING      usDeviceName;
    PDEVICE_OBJECT      pTargetDeviceObj;
    PFILE_OBJECT        pFileObj;
    PDEVICE_EXTENSION   pDeviceExt;
 
    //-f--> Seta a rotina de descarga do driver.
    pDriverObj->DriverUnload = OnDriverUnload;
 
    //-f--> Seta todas as dispatch routines do driver para
    //      uma que encaminhe a IRP para o driver original.
    for (i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++)
        pDriverObj->MajorFunction[i] = OnForwardDispatch;
 
    //-f--> Inicializamos a string com o nome do device ao
    //      qual queremos nos atachar.
    RtlInitUnicodeString(&usDeviceName,
                         L"\\Device\\StringList");
 
    //-f--> Obtemos o ponteito do device de destino
    nts = IoGetDeviceObjectPointer(&usDeviceName,
                                   FILE_READ_DATA,
                                   &pFileObj,
                                   &pTargetDeviceObj);
    if (!NT_SUCCESS(nts))
        return nts;
 
    //-f--> Criamos nosso device object
    nts = IoCreateDevice(pDriverObj,
                         sizeof(DEVICE_EXTENSION),
                         NULL,
                         pTargetDeviceObj->DeviceType,
                         pTargetDeviceObj->Characteristics,
                         FALSE,
                         &pMyDeviceObj);
    if (!NT_SUCCESS(nts))
    {
        //-f--> Oops!
        ObDereferenceObject(pFileObj);
        return nts;
    }
 
    //-f--> Obtem nosso DEVICE_EXTENSION
    pDeviceExt = (PDEVICE_EXTENSION)pMyDeviceObj->DeviceExtension;
 
    //-f--> Utiliza o mesmo método de IO do driver original
    pMyDeviceObj->Flags |= pTargetDeviceObj->Flags & (DO_BUFFERED_IO | DO_DIRECT_IO);
 
    //-f--> Aqui nosso driver entra na pilha de dispositivos
    nts = IoAttachDeviceToDeviceStackSafe(pMyDeviceObj,
                                          pTargetDeviceObj,
                                          &pDeviceExt->pNextDeviceObj);
    if (!NT_SUCCESS(nts))
    {
        //-f--> Oops!
        IoDeleteDevice(pMyDeviceObj);
        //-f--> Aqui não está faltando um return.
    }
 
    //-f--> Independente de estarmos atachados ou não, devemos liberar
    //      a referência obtida do device de destino.
    ObDereferenceObject(pFileObj);
    return nts;
}

Escrevendo a OnDriverUnload

Aqui é onde a festa acaba, antes de o nosso driver ser descarregado pelo sistema, teremos que remover nosso device da pilha de dispositivos e destruí-lo. (Risadas maléficas)

O código aqui é simples e não requer explicações se você for capaz de ler os comentários contidos nele.

/****
***     OnDriverUnload
**
**      Rotina de descarga do driver.
*/
VOID
OnDriverUnload(IN PDRIVER_OBJECT  pDriverObj)
{
    PDEVICE_OBJECT      pMyDeviceObj;
    PDEVICE_EXTENSION   pDeviceExt;
 
    //-f--> Nosso device está na lista de devices criados por este driver
    //      então vamos obtê-lo simples assim:
    pMyDeviceObj = pDriverObj->DeviceObject;
 
    //-f--> Aqui obtêmos o device extension.
    pDeviceExt = (PDEVICE_EXTENSION)pMyDeviceObj->DeviceExtension;
 
    //-f--> Aqui removemos nosso device da pilha passando o endereço do
    //      próximo device para a rotina abaixo.
    IoDetachDevice(pDeviceExt->pNextDeviceObj);
 
    //-f--> Agora podemos destruir nosso device (risadas maléficas)
    IoDeleteDevice(pMyDeviceObj);
}

"Fernando, nosso driver é forçado a se descarregar quando o driver original é descarregado?"

Essa é a filosofia do WDM, drivers são carregados automáticamente quandos seus dispositivos são detectados e descarregados quando seus dispositivos são desativados ou removidos. Os filtros seguem as mesmas regras e são carregados/descarregados basendo-se nestes eventos.

Mas não é isso o que acontece aqui. Os drivers de exemplo que uso neste blog são do modelo Legacy, e não WDM. No modelo Legacy, drivers são iniciados seguindo sua ordem de carga no registry, e não tem nada a ver com a detecção do seu dispositivo. Os filtros precisam iniciar depois dos drivers originais, e isso também é controlado pela sua ordem de carga. Este post fala sobre a ordem de carga dos legacy drivers.

"Tá! Falou, falou e não respondeu minha pergunta. O que acontece se eu solicitar a descarga do driver original enquanto houver um filtro atachado sobre ele?"

A descarga dos drivers que formam uma pilha deve ocorrer de forma inversa à sua carga. Neste caso o filtro deve ser descarregado antes do driver original, desempilhando os devices de cima para baixo. Caso o driver original receba uma solicitação de descarga enquanto ainda hoverem referências a seus devices, seja por um filtro ou por uma aplicação, a descarga é adiada até que suas referências sejam desfeitas. Até lá, a tentativa de obter novas referências para um device que recebeu a solicitação de descarga serão negadas.

Escrevendo Dispatch Routines

As dispatch routines de um filtro também são diferentes das dispatch routines de um driver. Apensar de elas poderem completar uma IRP chamando IoCompleteRequest(), elas normalmente repassam a socilitação adiante utilizando a rotina IoCallDriver(). Vou falar mais sobre o comportamento das dispatch routines de um filtro em posts futuros. Neste filtro de exemplo vamos apenas logar a atividade e repassar a solicitação ao próximo driver.

Quando falamos em repassar uma solicitação estamos na verdade falando de repassar IRPs. A leitura deste outro post é essencial para o que vamos fazer na implementação de nossas dispatch routines.

Para acabar esse post ainda nessa vida, segue código da implementação de nossa dispatch routine. Depois de ler o post sobre IRPs que acabei de recomendar, ler os comentários deste código devem ser suficientes para entender tudo o que foi feito aqui, ou não.

/****
***     OnForwardDispatch
**
**      Nossa dispatch routine simplesmente loga a IRP
**      recebida e repassa a solicitação adiante.
**
*/
NTSTATUS
OnForwardDispatch(IN PDEVICE_OBJECT    pDeviceObj,
                  IN PIRP              pIrp)
{
    PDEVICE_EXTENSION   pDeviceExt;
    PIO_STACK_LOCATION  pStack;
 
    //-f--> Obtém ponteiro para o device extesion
    pDeviceExt = (PDEVICE_EXTENSION)pDeviceObj->DeviceExtension;
 
    //-f--> Obtém stack location corrente
    pStack = IoGetCurrentIrpStackLocation(pIrp);
 
    //-f--> Manda o nome na major routine da IRP
    ASSERT(pStack->MajorFunction <= IRP_MJ_MAXIMUM_FUNCTION);
    DbgPrint("[StringFilter] : %s\n", g_szMajorNames[pStack->MajorFunction]);
 
    //-f--> Como não estamos modificando nada na stack location,
    //      vamos deixá-la para que o próximo device a use.
    IoSkipCurrentIrpStackLocation(pIrp);
 
    //-f--> Encaminha a IRP para o próximo device.
    return IoCallDriver(pDeviceExt->pNextDeviceObj,
                        pIrp);
}

Caso não tenham entendido nada, não esqueçam de me mandar um e-mail expondo suas dúvidas (sem ofenças pessoais). Isso me ajudará a entender suas dificuldades e a melhorar minhas explicações.

Testando o Filtro

Essa é a parte fácil do post. Para testar o filtro teremos primeiro que compilar, instalar e iniciar o driver deste post. Se você ainda não sabe como fazer isso, este outro post pode te dar um ponto de partida. Depois disso, compile, instale e inicie o filtro.

Depois de instalados, podemos utilizar a aplicação de teste para exercitar o driver. Poderemos acompanhar a atividade do filtro observando suas mensagens de debug que podem ser vistas no depurador de Kernel ou simplemente usando esta aplicação, que dispensa o uso de um depurador para ver as mensagens de debug de um driver.

"Fernando, fiz um teste aqui e ví que ao iniciar o filtro ele loga um evento de IRP_MJ_CLOSE mesmo antes de iniciar a aplicação de teste. O que eu fiz de errado?"

Não há nada de errado. Isso acontece por causa da sequência de passos seguidos na rotina DriverEntry() do filtro. Inicialmente o driver chama a rotina IoGetDeviceObjectPointer(), isso faz com que o IoManager envie uma solicitação de IRP_MJ_CREATE para o driver original. Depois disso nos atachamos à pilha de dispositivos e por fim chamamos a rotina ObDereferenceObject() que vai finalizar a única referência do file object que recebemos, enviando uma solicitação de IRP_MJ_CLOSE para o driver de baixo. Como já estamos atachados a ele, então somos capazes de ver nossa própria atividade sobre o driver original. Isso pode ser observado pela pilha de chamadas que teremos se houver um breakpoint em nossa dispatch routine quando liberarmos a referência do file object ao final da DriverEntry().

kd> k
ChildEBP RetAddr  
f8af9bcc 804ee129 StringFilter!OnForwardDispatch
f8af9bdc 80578f6a nt!IopfCallDriver+0x31
f8af9c14 805b0b18 nt!IopDeleteFile+0x132
f8af9c30 80522bd1 nt!ObpRemoveObjectRoutine+0xe0
f8af9c54 f8c80663 nt!ObfDereferenceObject+0x5f
f8af9c7c 805767ff StringFilter!DriverEntry+0xf3
f8af9d4c 8057690f nt!IopLoadDriver+0x66d
f8af9d74 80534c12 nt!IopLoadUnloadDriver+0x45
f8af9dac 805c61ee nt!ExpWorkerThread+0x100
f8af9ddc 80541de2 nt!PspSystemThreadStartup+0x34
00000000 00000000 nt!KiThreadStartup+0x16

Como de costume, o fonte do filtro que foi implementado neste post está disponível para download. Nosso filtro não faz quase nada, mas já servirá de base para posts futuros que darão mais funcionalidade a ele explicando como tais funcionalidades são implementadas.

Até mais!

Download StringFilter.zip

Symbian agora totalmente opensource

2010-02-06T01:40:22+00:00

Antes o kernel e agora toda a plataforma. A Symbian Foundation decidiu abrir todo o código-fonte para os desenvolvedores. É certo que muitas das ferramentas necessárias para a compilação e construção do sistema operacional ainda são proprietárias, mas com a ajuda da comunidade de desenvolvedores, esta migração será questão de tempo. Ao mer ver, a abertura do código-fonte é parte da estratégia

techberto

2010-01-31T15:45:33+00:00

Apesar de extremamente prazeroso (ou às vezes nem tanto) acompanhar mailists e foruns nem sempre é tarefa fácil, seja pelo rumo que certas discussões geram, pela falta de tempo ou às vezes pela questão do foco. Acredito eu, que eventualmente todos vêem um assunto que é meio (ou inteiramente) off-topic sendo tratado com certo pudor, mas que você gostaria que a discussão evoluísse mas a própria lista e a netiqueta não permite.

Alguns dizem que a relação entre arquiteto e programador é de confiança e compreensão, arquitetos não confiam em programadores e estes não compreendem os arquitetos!

Esta afirmação pode parecer exagerada (como de fato é) mas recentemente identifiquei exatamente esta situação numa reunião onde o foco era NoSQL, atritos à parte, na hora pensei que este é um assunto que merece ser profundamente e adequadamente discutido e difundido e ver ele restrito a censura ou limite dos off topics era algo cruel, e isto me fez lembrar de algumas conversas que tive, sendo uma delas com o Pedro Lamarão (figura carimbada do grupo C & C++ Brasil) num happy hour e outra com o Jack Ganssle (quando ele esteve no Brasil para o workshop que o Portal Embarcados promoveu sobre Engenharia de Software) no qual o foco de ambas conversas foi o estímulo e a iniciativa. Pra ser sincero, foi com este foco que convidamos o Felipe Tonello para palestrar no VI Encontro de Programadores do grupo C & C++ Brasil (que vai ocorrer no próximo sábado dia 06/02/2010) para falar sobre seu projeto RoboQT, é com esta abordagem em mente pensei que era necessários fazer algo em ralação ao NoSQL…

Como muitos sabem:

DBMS != SQL
SQL != Evil
NoSQL != Paraíso

Para aqueles que apreciam o assunto e desejam discuti-los sem a preocupação de criar “OFF TOPICS”, com o propósito de criar um canal
independente (de linguagens de programação e DBMS) destinada para a discussão de Banco (não bando) de Dados não relacionais - NF², NF2, N1NF (non first normal form) , MRNN (Modelo Relacional Não-Normalizado) também conhecidos como nested relational, dimensional, multivalue, free-form, schemaless porém mais populares como NoSQL (Not Only SQL) criei a lista MRNN-Brasil:

http://groups.google.com/group/MRNN-Brasil

O foco é tratar o assunto sem pudores de abordagens acadêmicas,
profissionais ou produtos podendo ser tratado tanto BigTable (???),
Dynomite, Riak, Cassandra, CouchDB, HBase, Sherpa, Voldemort, Tokyo
Cabinet, MongoDB como as bibliotecas das mais diversas linguagens, sejam elas C, C++, Python, ERlang, Go, Haskell, Ruby, Brainfuck ou Whitespace ou até novas iniciativas; seja do ponto de vista de arquitetura, programação, segurança ou o que for, mas obviamente relacionado com MRNNs.

Talvez eu não tenha procurado direito, mas como eu não havia encontrado nada semelhante em Pt-BR, resolvi tomar esta iniciativa.

A escolha de um nome do vernáculo foi em razão de que NoSQL não intui muito para o que ele realmente representa (Not Only SQL) e esta NÃO é uma lista não para aqueles que relacionam SQL com algo do mal e NoSQL dá impressão de ser uma campanha anti-SQL; mesmo que no fundo esta ”buzzword” não (?!?!) signifique isto e após estímulo (indireto) do Luciano Ramalho (que é um entusiasta do assunto tanto quanto ele é de Python) acabei adotando o nome MRNN-Brasil ao invés de NoSQL-Brasil.

Espero que iniciativa possa ser útil para a comunidade.

Um Helimodelo no XV Simpósio Multidisciplinar

2010-01-26T12:00:58+00:00

Esse é mais um daqueles posts Off-Topic que não tem nada a ver com nada. Ou quase nada. Acho que a maioria de vocês já esta cansada de saber que este é meu último ano da universidade e que este ano estou todo enrolado com nosso Trabalho de Graduação (TG). Quem acompanha meu Twitter tem uma idéia de como isso tem tomado meu tempo. Você pode estar se perguntando: "O que faz este projeto?". Em uma palavra: "Nada". Estamos trabalhando a mais de um ano desenvolvendo hardware, firmware, driver, software e controle para que o projeto não faça nada. Na verdade, o objetivo é que não aconteça nada com um helimodelo em voo. Tá, tudo bem, desde o começo agora.

Era uma vez um helimodelo

Alguns de vocês já sabem que além de programador retardado, também tento gastar o tempo que não tenho como helimodelista. Um helimodelo é um helicóptero em escala reduzida, equipado com motor à combustão ou mesmo elétrico. Com as funcionalidades de um helicóptero convencional, é capaz de realizar voos com as mesmas características e liberdade de movimentos. Na verdade, quanto à capacidade de voo, um helimodelo pode fazer mais que um helicóptero real. Não é incomum ver um helimodelo voando de cabeça para baixo.

Um helimodelo é controlado por um sistema de rádio controle que determina os movimentos de servomotores instalados na aeronave. Cada servo tem seu papel específico dentro do helimodelo. Um controla o acelerador, outro a inclinação das pás do rotor de cauda e assim por diante.

É fácil controlar um helimodelo?

Não mesmo. O rádio controle possui dois sticks, e assim, são 4 os movimentos que você deve comandar ao mesmo tempo, isso além das chaves adicionais. O grande problema é que para ganhar os reflexos necessários para fazer a correção leva um certo tempo de treino. Acredite, você não vai querer um helimodelo voando desgovernado perto de você. Além do risco de se ferir, é quase certo que o helimodelo acertará algo e se dividirá em vários pedaços. Posso dizer que este não é um equipamento barato e cada queda pode significar centenas de reais para colocar tudo para funcionar novamente. Para começar com esse hobby normalmente utilizamos um simulador.

Um simulador é muito parecido com um vídeo-game. Com ele você recebe um joystick especial que é uma réplica de um rádio controle, mas que faz interface USB com seu computador. Você utiliza tal joystick para controlar um helimodelo na tela do seu computador. Assim, a cada queda que o modelo sofrer, basta apertar um botão de reset no próprio controle para que você possa tentar novamente. Quando eu estava começando no hobby, todos me indicaram um simulador até que comprei um. Fiquei pensando: "Que dificil que nada... Pra cima de mim? Só se for pra esses coroas. Tenho mais de vinte anos de vídeo-game nas costas". Quando comecei a brincar com o simulador ví que não era tão fácil assim. Dezenas e dezenas de quedas. Os simuladores são realmente um excelente início. Eles conseguem reproduzir com grandes detalhes o comportamento de um modelo.

Depois do simulador, você normalmente faz aulas de voo. E para isso você contrata um instrutor. Mas o que pode fazer um instrutor além de lhe desejar boa sorte? O que acontece é que rádios controles podem ser ligados por um cabo de treinamento. Esse cabo permite que o instrutor possa controlar o helimodelo, e com o mudar de uma chave, o controle passa para a mão do aluno. Se o aluno perder o controle sobre o modelo, o instrutor pode tomar o controle de volta e evitar que seu helimodelo novinho se transforme num monte de lixo.

Legal, mas e o projeto?

Nosso projeto tem como objetivo controlar um helimodelo em voo de forma a estabilizá-lo. Por isso digo que nosso projeto vai fazer nada. Houve professor que ainda disse: "Caramba! Vocês vão fazer tudo isso para fazer um helicóptero ficar parado?". Se você é um helimodelista, sabe que manter o helimodelo parado é o primeiro desafio de um piloto. Mesmo em ambientes sem vento, estabilizar um helimodelo requer uma boa quantidade de experiência. Nosso objetivo final seria descrever um plano de voo simples onde ele decole, estabilize no ar, faça alguns movimentos e finalmente pouse. Não queremos dar um passo maior que a perna. Vamos ver o que conseguimos até o dia da apresentação.

Para detectar os movimentos do helimodelo, nós instalamos alguns sensores no helimodelo, os dados dos sensores são reunidos por um microcontrolador que está instalado numa placa também a bordo do helimodelo. Depois de reunidos, os dados são enviados à uma outra placa em solo através de um módulo ZigBee. Na foto abaixo pode-se ver nossa plaquinha. Essa placa em solo é um kit da Atmel que tem suporte a diversas interfaces, sendo a USB uma delas. Assim, escrevemos o firmware e o driver USB para fazer com que tais leituras agora fossem recebidas pelo nosso software de controle.

Para fazer o controle, utilizaremos o novo Toolkit de lógica Fuzzy que está disponível no novo LabVIEW 2009 da National Instruments. Para quem não conhece, o LabVIEW é uma das principais ferramentas de controle utilizadas pela engenharia moderna. É possível fazer programas de controle apenas desenhando e arrastando componentes sobre a tela, pode parecer contraditório um desenvolvedor de baixo nível dizer isso, mas toda essa abstração nos dá tempo para dedicar às coisas que realmente precisam de tempo. A ferramenta também dispõe de interfaces de I/O permitindo trabalhar com sensores e atuadores diretamente sobre o meio eletrônico.

Uma outra informação interessante é que o Toolkit de PID e Lógica Fuzzy foi completamente re-escrito e reformulado com a ajuda de um brasileiro. Isso mesmo, Bruno Cesar (na foto ao lado) trabalha na National Instruments Brasil e foi um dos responsáveis por esse desenvolvimento. Acha isso conhecidência? Então o que você me diria ao saber que ele também se formou na Universidade São Judas Tadeu? Bruno esteve semana passada no campus da Mooca dando uma palestra sobre o novo módulo de lógica Fuzzy. Isso nos deu mais certeza de que a lógica Fuzzy é a ideal para nosso problema de controle, já que ela é perfeita para lidar com problemas complexos onde não se tem o modelo matemático que descreva o comportamento de um helimodelo. A lógica Fuzzy se baseia na experiência de um operador para atuar sobre os controles. É bem interessante.

O LabVIEW também nos permite que façamos chamadas à DLLs. Essa foi uma maneira simples que conseguimos para fazer com os dados que estavam no driver chagar ao software de controle. Assim, criamos uma DLL que abstraísse muitas das complicações de se interagir com um dispositivo USB. O LabVIEW apenas chama funções do tipo LeAmostra() que já retorna o dado pronto para o uso. Todo aquele código com CreateFile() e DeviceIoControl() ficou por conta da DLL, além de outras funções auxiliares.

Agora vocês podem estar se perguntando: "Mas como o LabVIEW vai atuar sobre o helimodelo?". Lembra daquele cabo de treinamento? Nossa placa USB vai receber as ações de controle do LabVIEW através da mesma DLL. Para fazer com que tais comandos sejam aplicados sobre o helimodelo, fizemos com que nossa placa USB se comporte como um rádio controle, que utilizará o cabo de treinamento para aplicar o controle sobre o helimodelo. Obviamente ainda teremos um piloto segurando o rádio no papel de instrutor, principalmente para evitar acidentes, onde um mal funcionamento de nosso projeto poderia transformar meu helimodelo num monte de lixo.

O Simpósio Multidisciplinar

Desde que comecei a escrever sobre o projeto neste blog, algumas pessoas ficaram curiosas e disseram: "Me avise quando houver alguma apresentação". Bom, esta é a sua chance de dar uma olhada em alguns projetos. Nosso projeto foi aceito para ter um espaço neste evento que vai acontecer de 18 a 25 de setembro na Universidade São Judas Tadeu. Serão várias apresentações curtas de 15 cada. Os projetos ainda não estão terminados, e dessa forma, você ainda não verá nenhum helimodelo voando sozinho por lá, mas estaremos com nosso equipamento dispostos a responder algumas perguntas. O simpósio é aberto à visitação pública. Não é necessário ser aluno para participar, basta se inscrever gratuitamente no site da universidade e pronto. Se quiser discutir um pouco sobre sensores, microcontroladores, firmwares, drivers, controle ou ainda helimodelismo, mesmo que durante um café, é só aparecer.

Bom, é isso aí. Já escrevi demais. Agora preciso voltar ao meu projeto.
Até mais!

Jack Sullivan rodeado de Woodsprites

2010-01-25T19:43:21+00:00

Final de ano, num rancho a beira-rio, curtindo o feriadão com a família, meus primos tiveram a idéia de fazer uma festa (que para minha surpresa havia sido preparada com boa antecedência) com direito a vários badulaques e inclusive com lightsticks (à volonté como diria os franceses ou à la vonté como nós abrasileiramos e gostamos de dizer) que sempre dá um tom alegre a festas noturnas e sempre leva a criançada (e inclusive vários marmanjos) a brincar diante das lâmpadas ultra-violetas, devido aos agradáveis efeitos visuais que tal combinação produz, sendo sempre um bom elemento para complementar a diversão.

Após a festa e em momento oportuno, meu sábio tio José, que tem uma curiosidade que eu muito aprecio, me fez a seguinte pergunta:

- O que faz estas pulseiras brilharem? Elas são realmente de neon?

Estes são um daqueles momentos que você sente imenso prazer, afinal perguntaram algo do que eu sabia responder e pelo qual naquele momento eu estava pensando por razões que vocês irão descobrir abaixo. Sem contar que com certas pessoas é sempre prazeiroso compartilhar um pouco de erudição ou como alguns preferem chamar, um pouco de cultura inútil para desopilar o fígado; apesar que se tratando de cultura eu nunca a acho inútil, mesmo que seja para filosofar sobre o bater de asas das borboletas do ponto de vista entomológico, neural, da física tratando da teoria do caos, da perspectiva cinematográfica comentando sobre criativo filme “efeito borboleta” ou poético lembrando por exemplo da famosa pretensão de Mhuammad Ali de “float like a butterfly, sting like a bee“. Mas dependendo do contexto isto pode ser um porre para quem está participando e ninguém gosta de ser desagradável, mas este não era o caso.

O neon é um gás nobre incolor, abundante no universo, mas presente em pequena quantidade no ar atmosférico, ele foi descoberto pelos químicos britânicos Morris Travers (que eu sempre confundo com Tavares) e William Ramsay no século 19, os mesmos que descobriram o gás xenônio e o criptônio; que apesar do nome krypton nada tem a ver com a saga de Kal-EL.

Segundo gás nobre mais leve, com um alto poder de refrigeração, 40 vezes maior que do hélio líquido e três vezes maior que o hidrogênio líquido, ele não está presente no light-stick!!!

A tradução de ligh-stick é “bastão luminoso”, mas sei lá por que cargas d’água (talvez pela mesma razão que vulgarizaram a expressão francesa à volonté para à la vonté) o mercado abrasileirou o nome para bastão de neon ou pulseira de neon, devido a sutil semelhança com as lâmpadas de neon, porém não é o gás nobre o responsável pela fonte de energia luminosa deste artefato, mas sim uma reação que ocorre com o cyalume (que está no bastão) similar e mais barato que ao luminol. No caso do luminol, ele reage com cobre e ferro, e como há ferro na hemoglobina, o luminol é vastamente empregado por equipes de investigação forense (como de CSI) para investigações criminais.

O que presenciamos no ligh-tstick (e nas cenas de CSI quando eles encontram sangue em algum local ou objeto) é o efeito conhecido como luminescência (nome com origem no latim “lumem”) que é a emissão de luz através por estímulo de radiação ionizante, luz ou reação onde uma energia química é transformada em energia luminosa. Na realidade quando o efeito é obtido através de algum composto químico sintético, como no caso do light-stick, ele é chamado de quimiluminescência e, apesar de não ser o caso, se fosse produzido por um organismo vivo ele seria chamado de bioluminescência sendo-se que há vários outros tipos de luminescência.

Voltando ao bastão.

No caso deste, normalmente há um solução de cyalume com uma ampola de vidro contendo uma solução de peróxido de hidrogênio (água oxigenada 35%) e quando o bastão é dobrado a ampola é quebrada, as soluções são misturadas o luminol começa a ser oxigenado e a quimiluminescência começa a ocorrer e fazer a alegria da galera. A duração do efeito depende da temperatura do local, sendo-se que temperaturas baixas são mais propícias para sua durabilidade, portanto colocar a pulseira na geladeira tende a prologar o efeito mas ele não se eternizará ou fará a efeito ocorrer novamente.

Vale lembrar que apesar de ser um efeito estudado a centenas de anos, com grandes evoluções no último século, este é um fenômeno não totalmente compreendido plenamente ainda sendo alvo de estudos e pesquisas.

No caso da bioluminescência, normalmente o substrato de uma proteína denominada luciferina (nome com origem no latim “lucifer” que significa “que ilumina”) é oxidada por uma enzima, denominada luciferase. Nesta reação há o consumo de uma molécula de trifosfato de adenosina (ATP) que excita energéticamente a luciferina e proporciona a geração de energia luminosa através da liberação da energia química.

A luminescência tem atraído o interesse do homem desde o princípio de sua existência, visto que do Pernambuco à China, os primeiros registros e pirilampos, fenômeno que Aristóteles (384 – 322 A.C) descreveu como “luz fria”. Em 1669, o médico H. Brandt criou a “phosphorus mirabilis”, que era uma reação que utiliza uma propriedade do fósforo quando exposto ao oxigênio do ar em certas circunstâncias e por esta reação ele obtia a “quimiluminescência” (termo que fui criado 200 anos depois), mas Brandt que era um alquimista na época não compreendia exatamente o que ele estava fazendo, apenas o que ele estava conseguindo; o fascínio das pessoas para quem ele apresentava seu experimento alquimista.

Talvez seja este fascínio (o a intenção de fascinar) que fez James Cameron

inserir na história de Avatar, a luminescência e a bioluminescência em Pandora como uma propriedade de todo organismo deste planeta, dos animais aos pequenes Woodsprites, as sementes de Utraya “Mokri”, e a Árvore das Almas, com propriedades místicas.

Quando meu tio Zé perguntou-me sobre o bastão de luz, a pouco eu estava lembrando da carinha de alegria de minhas sobrinhas ao brincar com os bastões de luz, sobre o fascínio da luminescência na humanidade e sobre o belo efeito que James Cameron conseguiu com Avatar, portanto nem preciso dizer o quanto achei oportuno a pergunta dele; porém confesso que na hora puxei um pouco o freio de mão e não externei toda minha viagem.

E por falar em viagem e para finalizar, vejam só o que este maluco fez com um bocado destes bastões:

Alerta, Cyalume é tóxico e além disto como comentei acima, há vidro nos bastões, portanto não façam isto em casa!

Namastê!

F# talk for .NET Architects Group

2010-01-25T17:51:46+00:00

Last week, 16th January to be precise, I gave another talk about my second favorite programming language: F#.

This event was managed by .NET Architects Group, a .NET brazilian discussion group. The organization was excellent and impeccable!

As you know, every post of this blog has a piece of code. Below, we have a sample to host a REST WCF Service with F# without using a configuration file to define bindings.

#r "System.ServiceModel.dll"
#r "System.ServiceModel.Web.dll"
#r "System.Runtime.Serialization"

open System
open System.ServiceModel
open System.ServiceModel.Web
open System.Runtime.Serialization
open System.ServiceModel.Description

[<ServiceContract>]
type IMyService =
    [<OperationContract>]
    [<WebGet(ResponseFormat=WebMessageFormat.Xml)>]
    abstract Ping : value:int -> string

//http://localhost:8081/svc/Ping?value=42
type MyService =
    interface IMyService with
        member this.Ping ( value ) = printfn "%d" value; string value

let svc = new ServiceHost( typeof<MyService>, new Uri( "http://localhost:8081/svc" ) )
let metadata = new ServiceMetadataBehavior( HttpGetEnabled = true )
svc.Description.Behaviors.Add( metadata )
svc.AddServiceEndpoint( ServiceMetadataBehavior.MexContractName, MetadataExchangeBindings.CreateMexHttpBinding(), "mex" )

let binding = new WebHttpBinding()
let endpoint = svc.AddServiceEndpoint( typeof<IMyService>, binding, String.Empty )
let behavior = new WebHttpBehavior()
endpoint.Behaviors.Add( behavior )

svc.Open()

printfn "Host is running..."
Console.ReadLine()

The slide-deck, scripts and program samples (not) showed there are available from here: FSharp Talk Samples

Editpat - the transparent notepad and post-it tool will be released in another occasion.

I'd like to express my gratitude to all the attendees, both on-site or online. You were all great!