Muito bem pessoal, chegou a hora de conhecer os 3 vencedores da promoção para ganhar o livro de RTOS da Micrium!

Primeiramente, gostaria de agradecer à todos pela participação. Recebi 85 respostas, e deu um pouco de trabalho corrigir tudo! :)

A maioria acertou pelo menos 3 dos 4 desafios, e 38 acertaram tudo. Dentre estas 38 pessoas, fiz o sorteio lá no http://www.random.org/.

Mas antes de dizer quem são os 3 felizardos, que tal darmos uma olhada novamente nos desafios?

DESAFIO 1

O desafio 1 dizia o seguinte:

O código abaixo tem um erro. Qual é este erro?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

#include <stdlib.h>
#include <stdio.h>
 
#define SIZE 15 
 
int main()
{
    int *a, i;
 
    a = malloc(SIZE*sizeof(int));
 
    for (i = 0; i < SIZE; i++)
        *(a + i) = i * i;
 
    for (i = 0; i < SIZE; i++)
        printf("%dn", *a++);
 
    free(a);
 
    return 0;
}

A maioria acertou este desafio. Na linha 10 alocamos uma região de memória e armazenamos o endereço no ponteiro “a”. Na linha 16 este ponteiro é alterado, e quando tentamos desalocá-lo na linha 18 teremos problemas na certa, já que o ponteiro “a” não armazena mais o endereço inicial retornado por malloc(). A solução aqui seria não alterar este ponteiro. O código abaixo resolve o problema:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

#include <stdlib.h>
#include <stdio.h>
 
#define SIZE 15 
 
int main()
{
    int *a, i;
 
    a = malloc(SIZE*sizeof(int));
 
    for (i = 0; i < SIZE; i++)
        *(a + i) = i * i;
 
    for (i = 0; i < SIZE; i++)
        printf("%dn", *(a + i));  // CORREÇÃO
 
    free(a);
 
    return 0;
}

Algumas pessoas apontaram ainda que faltou checar o retorno da função malloc() e fazer o cast para (int *). É verdade! O cast é necessário principalmente se você tentar compilar em C++. Mas não considerei estes fatores para validar a resposta como certa.

DESAFIO 2

O desafio 2 dizia o seguinte:

O código abaixo tam­bém tem um erro. Qual?

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#include <stdio.h>
 
int main()
{
    int* ptr1, ptr2;
 
    ptr1 = malloc(sizeof(int));
 
    ptr2 = ptr1;
 
    *ptr2 = 10;
 
    return 0;
}

A maioria também acertou este exercício. Uma coisa que aprendi deste quando comecei a estudar C é que devemos colocar o “*” sempre do lado do nome do ponteiro, e não do lado do tipo. No código acima, ptr2 é um inteiro, e não um ponteiro para inteiro como pretendiamos, causando erro na linha 11. Para corrigir este código, basta declarar ptr2 como ponteiro:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#include <stdio.h>
 
int main()
{
    int *ptr1, *ptr2;  // CORREÇÃO
 
    ptr1 = malloc(sizeof(int));
 
    ptr2 = ptr1;
 
    *ptr2 = 10;
 
    return 0;
}

Assim como no primeiro exercício, algumas pessoas também apontaram a ausência da checagem do retorno da função malloc() e do cast para (int *). Mas também não considerei estes fatores para validar a resposta como certa.

Outros falaram da ausência do free(). Sim, é sempre uma boa prática usar o free(), mas sua ausência nem sempre significa erro. No nosso caso, como a aplicação aloca e depois encerra, não teremos problema com memory leak pela ausência do free().

DESAFIO 3

O desafio 3 dizia o seguinte:

A função abaixo recebe um vetor de números inteiros e tem o obje­tivo de retornar o menor número inteiro deste vetor. Imple­mente esta função sem usar nen­hum oper­ador de com­para­ção! Ou seja, você não pode usar nen­hum destes oper­adores: “==”, “!=”, “>”, “<”, “>=”, “<=”.

1
2
3
4

unsigned int menor(unsigned int buf[], size_t size)
{
 
}

Aqui o bicho pegou! Este é o típico “exercício bombril”, que pode ser resolvido de 1001 maneiras. Recebi implementações de 5 linhas e outras de 50 linhas! :)

Esta é a minha sugestão de implementação:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

unsigned int menor(unsigned int buf[], size_t size)
{
    unsigned int m = 0;
    int i;
 
    while(1) {
 
        for (i = size; i; i--) {
            if (!buf[i - 1]) return m;
            buf[i - 1]--;
        }
 
        m++;
    }
}

Eu faço uma varredura do vetor em um loop e decremento, um a um, cada elemento deste vetor. A quantidade de decrementos realizados é armazenada na variável “m”. Quando um dos elementos do vetor atingir o valor 0, significa que descobri qual era o elemento de menor valor dentro do vetor, e retorno este valor, que é exatamente a quantidade de decrementos realizada, armazenada na variável “m”.

Recebi algumas implementações que usavam esta lógica, mas também recebi outras implementações bem interessantes.

Achei bem legal esta implementação do Paulo Daniel:

1
2
3
4
5
6
7
8

unsigned int menor(unsigned int buf[], size_t size)
{
   unsigned int min = UINT_MAX;
   while(size) 
      if(!(buf[--size]/min))
         min = buf[size];
   return min;
}

Ele conseguiu resolver em 5 linhas, usando apenas uma operação de divisão de inteiros!

Atualização: Como bem observado pelos leitores Fernando Barboza e Уθя¡ςκ, esta implementação tem uma falha, já que existe o risco de divisão por 0 na linha 5. Mas a forma como o problema foi resolvido não deixa de ser bem interessante.

Já o Douglas Drumond preferiu escovar alguns bits e trabalhar com complemento de 2:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

unsigned int menor(unsigned int buf[], size_t size)
{
    unsigned int shamt =  (sizeof(unsigned int) * 8 - 1);
    unsigned int mask = 0x01;
 
    size_t i = size - 1;
 
    unsigned int menor_item = buf[i];
    while (i--) {
        if(((buf[i] - menor_item) >> shamt) && mask) menor_item = buf[i];
    }
 
    return menor_item;
}

DESAFIO 4

Este desafio dizia o seguinte:

Escreva um pro­grama em C que imprima “Quero o meu livro!”, mas sem usar nen­hum ponto-e-vírgula no arquivo “.c”! Obs: o pro­grama deve com­pi­lar e fun­cionar nor­mal­mente.

A solução é bem simples:

1
2
3
4
5
6

#include <stdio.h>
 
void main()
{
    if (printf("Quero o livro!n")) {}
}

Você pode trocar o “if” pelo “while” também.

Teve gente que queria tanto o livro que colocou em um loop infinito! :)

1
2
3
4

void main()
{
    while(printf("Quero o meu livro!n")){}
}

Mas aqui o pessoal resolveu usar a criatividade. Como falei apenas que não podia usar “;” no arquivo “.c”, e não mencionei nada sobre o uso de arquivo “.h”, recebi respostas do tipo:

1
2
3
4
5
6
7
8
9
10
11
12
13

// Author: Celso
// imprime.c
#include <stdio.h>
#include <stdlib.h>
 
#include "imprime.h"
void main()
{
  IMPRIME
}
 
// imprime.h
#define IMPRIME   printf("Quero o meu livro!n");

Ou então trocando o “;” por um define passado pelo compilador:

1
2
3
4
5
6
7
8
9
10
11

/* Author: Fernando Martines
 *
 * Compilacao: gcc -DSPECIAL=";" desafio4.c -o desafio4
 */
#include <stdio.h>
 
int main()
{
    printf("Quero o meu livro!n") SPECIAL
    return 0 SPECIAL
}

Bom, gostei muito do resultado destes desafios. Aprendi bastante e espero que vocês tenham aprendido também. Afinal, o que importa é participar. Ganhar é só um detalhe, não é verdade? O quê? Não!? :)

OK, chega de enrolação, estes são os três participantes que acertaram os 4 desafios e foram sorteados para receber o livro:

• Rodrigo (a.k.a. Skhaz)
• Eduardo Vieira
• Rodolfo Pereira Araujo

Para aqueles que não ganharam, não desanimem! Vocês podem baixar gratuitamente o PDF do livro no site da Micrium aqui.

Ou então vocês podem esperar o próximo concurso. Eu havia falado que tinha 3 livros, não é verdade? Então… eu estava escondendo o jogo! :)

Na verdade, alem destes 3, tenho mais 1! E logo mais teremos um novo desafio por aqui. Mas desta vez não será tão fácil assim! :)

Um abraço!

Sergio Prado

Posts relacionados:

1. Quer ganhar o livro uC/OS-III The Real-Time Kernel?
2. Resultado do concurso para ganhar o convite VIP
3. Sistemas de Tempo Real — Parte 2

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em Resultado do concurso do livro uC/OS-III The Real-Time Kernel.

A idéia de escrever este artigo surgiu da necessidade de um projeto que trabalhei algumas semanas atrás.

O objetivo era implementar um teclado virtual, de forma que um processo ou aplicação pudesse simular o pressionamento de uma tecla, sem que esta tecla tivesse sido realmente pressionada em um teclado físico.

Até aí tudo bem, qualquer biblioteca ou toolkit gráfico decente (X11, DirectFB, Qt, etc) possui algum mecanismo para emular entrada de teclado. Mas o objetivo era ser independente de biblioteca gráfica, e funcionar também em ambiente somente texto. Ou seja, precisavamos de algo implementado dentro do kernel.

Mas não vamos “colocar a carroça na frente dos bois”! Antes de pensar na solução, vamos pensar no problema…

PURA MÁGICA?

Não, não é mágica. Mas uma tecla pressionada dentro do kernel do Linux passa por algumas camadas até você vê-la ecoando na tela do seu monitor.

CAMADA 0: HARDWARE

Tudo começa no hardware, claro. A controladora do teclado conectado ao seu PC varre e decodifica a matriz de teclas e cuida de detalhes como o controle de debouncing.

Quando você pressiona uma tecla, essa tecla é transformada em um código chamado de scancode. Cada tecla possui um scancode quando é pressionada e outro quando é liberada (o bit mais significativo é setado). Por exemplo, a letra ‘x’ emite o scancode 0x2d quando é pressionada e 0xad quando é liberada (no meu teclado USB).

Se você quiser, pode usar a ferramenta “showkey” para fazer o dump e exibir o scancode das teclas pressionadas no seu PC:

$ sudo showkey -s
press any key (program terminates 10s after last keypress)...
0x2d 0xad

Portanto, para cada tecla pressionada, uma interrupção é gerada para a CPU, e os scancodes são enviados via barramento de comunicação, dependendo do hardware do seu teclado (PS2, USB, etc).

Logo após, a rotina de tratamento de interrupção do teclado é acionada, sendo responsável por receber e tratar estes scancodes, conforme veremos a seguir.

CAMADA 1: DEVICE DRIVER

Aqui já estamos no kernel do Linux. Um device driver vai conversar com o hardware do seu teclado, receber e tratar os scancodes.

E dependendo do hardware que você esta usando (teclado USB, PS2, etc), um diferente device driver será o responsável por ler estes scancodes. Por exemplo, a implementação do teclado PS2 padrão encontra-se nos fontes do kernel em drivers/input/keyboard/atkbd.c. Vai lá dar uma olhada, eu espero!

Após ler os scancodes, o device driver irá convertê-los em um outro código chamado keycodes. Cuidado para não confundir! Scancode é um código dependente do hardware do teclado e tratado pelo device driver. Keycode é um código que representa uma tecla dentro de um sistema Linux.

Você já viu que cada tecla pressionada gera dois scancodes (pressionada e liberada). Mas ela possui um único keycode. Por exemplo, no meu PC, quando pressiono a tecla ‘x’, é gerado o keycode 45:

$ sudo showkey -k
press any key (program terminates 10s after last keypress)...
keycode  45 press
keycode  45 release

Mas como então o kernel diferencia teclas pressionadas e liberadas se o keycode é o mesmo? Fácil. O device driver gera dois eventos para o kernel. Um para teclas pressionadas e outro para teclas liberadas. E estes eventos são enviados para camada input do kernel.

CAMADA 2: INPUT SUBSYSTEM

É nesta camada que percebemos toda a capacidade de modularização do kernel do Linux. 

A camada input foi criada para abstrair a captura de eventos de dispositivos de entrada como mouse, teclado, joysticks, touch screens, etc. Enquanto que cada um destes dispositivos possui seu respectivo device driver, cada device driver exporta os eventos para a camada input. Por sua vez, a camada input trata e exporta estes eventos em um formato padrão para arquivos de dispositivo em /dev/input/:

$ ls /dev/input
event0  event1  event2  event3  event4  event5  mice  mouse0

Cada um destes arquivos de dispositivo representam um dispositivo de entrada.

Você pode usar a ferramenta “evtest” para verificar qual o dispositivo relacionado à determinado arquivo:

$ sudo evtest /dev/input/event4
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x1c4f product 0x2 version 0x110
Input device name: "USB USB Keykoard"
...

Veja que, na minha máquina, /dev/input/event4 é o arquivo de dispositivo que gera os eventos do teclado USB.

A ferramenta “evtest” também é capaz de monitorar os eventos de dispositivos de entrada. Execute novamente o comando acima, pressione uma tecla e veja os eventos que foram exportados para userspace através deste arquivo de dispositivo:

...
Event: time 1323720735.849223, type 1 (Key), code 45 (X), value 1
Event: time 1323720735.849225, -------------- Report Sync ------------
Event: time 1323720735.905222, type 1 (Key), code 45 (X), value 0
Event: time 1323720776.880210, -------------- Report Sync ------------
...

Perceba o keycode 45 para a tecla ‘x’ e os valores 1 para tecla pressionada e 0 para tecla liberada.

Por fim, as bibliotecas gráficas monitoram os eventos nestes arquivos de dispositivos e exportam estes eventos para as aplicações. E assim você vê uma tecla ecoando em seu terminal!

Linux é ou não é um dos SOMLTT — sistemas operacionais mais legais de todos os tempos? :-)

Apenas um detalhe aqui: no caso do teclado, além de exportar os eventos para “/dev/input/”, a camada input também exporta os eventos de teclas pressionadas para a camada TTY ativa no momento. Desta forma, se você estiver em um terminal conectado à /dev/tty2, por exemplo, irá receber este evento. Se quiser saber mais sobre a camada TTY, leia o artigo “Por dentro da console em sistemas Linux”.

VOLTANDO AO NOSSO PROBLEMA…

Depois de todas estas explicações, espero que você não tenha se esquecido do nosso problema original: emular um teclado virtual independente de biblioteca gráfica, e que funcione em modo texto.

Agora ficou mais fácil pensar numa solução, não é verdade?

Reveja as camadas. A camada 0 é hardware, e não temos hardware no nosso caso. A camada 2 é genérica, e não é uma boa prática mexer nela. Potanto, é na camada 1 que trabalharemos.

Vamos desenvolver um device driver (no nosso caso, um módulo do kernel, já que não falaremos com nenhum hardware) que irá gerar eventos de teclado para a camada input. Simples assim!

A SOLUÇÃO

Para não complicar muito, vamos escrever um modulo simples que irá emular a digitação de uma frase a cada 10 segundos. Assim que carregado, uma frase será “digitada” pelo módulo a cada 10 segundos. E para deixar o trabalho mais divertido, a frase será “segmentation fault”!

Sem mais enrolação, este é o código completo do nosso módulo do kernel:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96

#include "linux/fs.h"
#include "linux/cdev.h"
#include "linux/module.h"
#include "linux/kernel.h"
#include "linux/delay.h"
#include "linux/kthread.h"
#include "linux/device.h"
#include "linux/slab.h"
#include "linux/tty.h"
#include "linux/tty_flip.h"
#include "linux/kbd_kern.h"
#include "linux/input.h"
 
/* vtkbd kernel thread struct */
static struct task_struct *vtkbd_thread_task;
 
/* vtkbd input device structure */
static struct input_dev *vtkbd_input_dev;
 
const char str_keys[] = { KEY_S, KEY_E, KEY_G, KEY_M, KEY_E, KEY_N,
                          KEY_T, KEY_A, KEY_T, KEY_I, KEY_O, KEY_N,
                          KEY_SPACE, KEY_F, KEY_A, KEY_U, KEY_L,
                          KEY_T, KEY_ENTER };
 
/* kernel thread */
static int vtkbd_thread(void *unused)
{
    int i;
 
    while (!kthread_should_stop()) {
 
        for (i = 0; i < sizeof(str_keys); i++) {
 
            input_report_key(vtkbd_input_dev, str_keys[i], 1);
            input_report_key(vtkbd_input_dev, str_keys[i], 0);
            input_sync(vtkbd_input_dev);
 
        }
 
        /* wait 10 seconds */
        msleep(10000);
    }
 
    return(0);
}
 
/* driver initialization */
static int __init vtkbd_init(void)
{
    static const char *name = "Virtual Keyboard";
    int i;
 
    /* allocate input device */
    vtkbd_input_dev = input_allocate_device();
    if (!vtkbd_input_dev) {
        printk("vtkbd_init: Error on input_allocate_device!\n");
        return -ENOMEM;
    }
 
    /* set input device name */
    vtkbd_input_dev->name = name;
 
    /* enable key events */
    set_bit(EV_KEY, vtkbd_input_dev->evbit);
    for (i = 0; i < 256; i++)
        set_bit(i, vtkbd_input_dev->keybit);
 
    /* register input device */
    input_register_device(vtkbd_input_dev);
 
    /* start thread */
    vtkbd_thread_task = kthread_run(vtkbd_thread, NULL, "%s", "vtkbd_thread");
 
    printk("Virtual Keyboard driver initialized.\n");
 
    return 0;
}
 
/* driver exit */
void __exit vtkbd_exit(void)
{
    /* stop thread */
    kthread_stop(vtkbd_thread_task);
 
    /* unregister input device */
    input_unregister_device(vtkbd_input_dev);
 
    printk("Virtual Keyboard driver.\n");
}
 
module_init(vtkbd_init);
module_exit(vtkbd_exit);
 
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Sergio Prado sergio.prado@embeddedlabworks.com");
MODULE_DESCRIPTION("Virtual Keyboard driver");

O módulo tem basicamente 3 funções: vtkbd_init() para inicializar o módulo, vtkbd_exit() para fazer a limpeza ao descarregar o módulo e vtkbd_thread() que faz a mágica de digitar a frase periodicamente.

Na função de inicialização, o primeiro passo é alocar um dispositivo de input com a função input_allocate_device() na linha 54. Essa função vai devolver uma estrutura que vai nos possibilitar conversar com a camada input e gerar os eventos de teclado. Nas linhas 64 a 66 habilitamos a geração de eventos em todas as teclas (veja o loop) e na linha 69 registramos o dispositivo de input com a função input_register_device(). Por último, criamos e iniciamos a thread do kernel que irá fazer o “trabalho sujo”. Se você quiser ler mais sobre Kernel Threads, leia o artigo “Linux Device Drivers — Trabalhando com Kernel Threads”

Na função de limpeza, paramos a thread e removemos o dispositivo de input que registramos na inicialização.

A thread vtkbd_thread() é bem simples e faz toda a mágica. Ela é basicamente um loop infinito que, a cada 10 segundos, gera os eventos para emular a digitação. O vetor str_keys[] contém os keycodes para a frase “segmentation fault”. Esses keycodes estão definidos em include/linux/input.h. Para cada keycode, geramos dois eventos com a função input_report_key(), simulando a tecla pressionada na linha 34 e a tecla liberada na linha 35 (veja os parâmetros 1 e 0, respectivamente). Por último, executamos a função input_sync(), notificando a camada input da existência de novos eventos a serem tratados.

Simples, não?

Para compilar, crie um Makefile com o conteúdo abaixo:

KVER := $(shell uname -r)
KDIR := /usr/src/linux-headers-$(KVER)
PWD  := $(shell pwd)
 
obj-m += vtkbd.o
 
default:
        $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
 
clean:
        @rm -Rf *.o *.ko *.mod.c modules.order Module.symvers Module.markers

E compile:

$ make

Para carregar o módulo:

$ sudo insmod vtkbd.ko

E para remover o módulo:

$ sudo rmmod vtkbd

Como o módulo ficará digitando “segmentation fault” a cada 10 segundos, este é o tempo que você terá para digitar o comando de remoção do módulo antes dele bagunçar seu shell!

E lembre-se de que você esta trabalhando em kernel space, com acesso total e irrestrito à memória e I/Os. Portanto, o ideal aqui é trabalhar em uma máquina virtual. É mais seguro e pode evitar muitos acidentes, principalmente para aqueles que estão começando os estudos do Kernel do Linux.

PEGADINHA DO MALANDRO

Agora pegue este módulo, e quando seu amigo deixar a seção aberta para tomar um café, instale e cronometre o tempo que ele vai levar para encontrar a causa do “segmentation fault”! Isso se ele encontrar… :)

Um abraço,

Sergio Prado

Posts relacionados:

1. Linux Device Drivers — Parte 1
2. Linux Device Drivers — Parte 2
3. Por dentro da console em sistemas Linux

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em Implementando um teclado virtual no Linux.

Já faz um tempo que não escrevo sobre desenvolvimento de device drivers em Linux. Na parte 2 desta série desenvolvemos um device driver completo para acessar os leds do kit FriendlyARM mini2440. Que tal estudar um pouco mais sobre a API do kernel do Linux?

Neste artigo vamos aprender a trabalhar com threads em kernel space, e para exemplificar os conceitos, vamos fazer os leds do kit mini2440 piscarem.

THREADS?

Você já sabe que o Linux é um sistema operacional multi-tarefa, e que ele consegue executar mais de uma tarefa ao mesmo tempo. É claro que em sistemas com apenas 1 núcleo, apenas uma tarefa tem a atenção da CPU em determinado momento, mas temos a impressão de que várias coisas estão acontecendo simultaneamente. Isso ocorre devido ao fato do Linux ser um sistema operacional preemptivo. O escalonador aloca uma fatia do tempo disponível para cada tarefa em execução.

Se você trabalha a um tempo desenvolvendo aplicações para Linux, sabe que é possível ter mais de uma linha de execução em um processo. É o que chamamos de threads. E o conceito é simples: “dividir para conquistar”. Cada thread tem uma responsabilidade específica, e você acaba otimizando o uso dos recursos da máquina, além de estruturar melhor o código e facilitar a manutenção.

O que você talvez não saiba é que em kernel space também podemos ter mais de uma thread de execução.

KERNEL THREADS?

Kernel threads são threads dentro do kernel. Você pode por exemplo ter tarefas executando em background em um device driver, esperando por eventos assíncronos ou executando determinada atividade de tempos em tempos.

É fácil identificar as threads do kernel rodando no seu sistema. Ao listar os processos em execução com o comando “ps”, os nomes entre “[]” são kernel threads. Veja um trecho da saída deste comando na minha máquina de desenvolvimento:

$ ps auxf
PID   USER     COMMAND
    1 root     init
    2 root     [kthreadd]
    3 root     [ksoftirqd/0]
    4 root     [events/0]
    5 root     [khelper]
   81 root     [kblockd/0]
   92 root     [khubd]
...

Da listagem acima, com exceção do processo “init”, o restante dos processos são kernel threads.

Mas quando você vai precisar de kernel threads? Em algumas situações, na verdade. Se você precisa esperar por eventos assíncronos, é bem provável que a solução seja criar uma thread no kernel para aguardar por este eventos. Se você tem uma tarefa dentro de um device driver que leva bastante tempo para ser executada, você pode delegá-la para uma kernel thread. Se você precisa executar determinada tarefa periodicamente, pode também usar uma thread no kernel para fazer isso.

Mas como isso funciona na prática? É o que veremos agora!

NOSSO EXEMPLO

Mais uma vez, nosso exemplo será executado no kit mini2440. Neste artigo aqui desenvolvemos um device driver para acender e apagar os leds deste kit. Agora iremos extender as funcionalidades deste device driver para fazer os leds piscarem. Da mesma forma que “0” apaga e “1” acende, enviar “2” ao led irá colocá-lo em um estado de “blink”, fazendo-o piscar com uma frequência de 1 segundo.

Existem duas formas de trabalhar com threads no kernel: a antiga e ultrapassada kernel_thread() e a atual e melhor estruturada kthread. Vamos ver exemplos com as duas.

Iremos criar uma thread que a cada 1 segundo irá verificar se algum dos leds esta configurado para piscar, e então inverteremos seu estado. Simples, não? Então mãos à obra!

A ANTIGA INTERFACE KERNEL_THREADS

Este é o código responsável pelo gerenciamento da thread usando a antiga interface kernel_thread():

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

#define BLINK_TIME  1000
 
/* flag to enable thread */
unsigned int thread_enabled = 1;
struct completion leds_blink_exit;
 
/* kernel thread to blink the leds */
static int leds_blink(void *unused)
{
    int i;
 
    daemonize("leds_blink");
 
    while (thread_enabled) {
 
        for (i = 0; i < NUM_LEDS; i++) {
            if (leds_dev[i].status == LED_BLINK) {
                changeLedStatus(leds_dev[i].number, LED_BLINK);
            }
        }
 
        msleep(BLINK_TIME);
    }
 
    complete_and_exit(&leds_blink_exit, 0);
}
 
/* driver initialization */
int __init leds_init(void)
{
    ...
 
    /* init completion struct */
    init_completion(&leds_blink_exit);
 
    /* initialize leds_blink therad */
    kernel_thread(leds_blink, NULL, CLONE_FS | CLONE_FILES |
                  CLONE_SIGHAND | SIGCHLD);
 
    ....
}
 
/* driver exit */
void __exit leds_exit(void)
{
    ...
 
    /* stop thread */
    thread_enabled = 0;
    wait_for_completion(&leds_blink_exit);
 
    ...
}

A thread é criada na linha 37 com a função kernel_thread(). Esta função recebe basicamente um ponteiro para a função da thread e alguns parâmetros que indicam quais recursos serão compartilhados com o processo pai.

A função da thread leds_blink() na linha 8 é bem simples. Ela é basicamente um loop infinito que periodicamente faz piscar os leds com o estado configurado como LED_BLINK.

A complexidade aqui esta no controle de finalização da thread. Se removermos o módulo do device driver sem aguardar a finalização da thread, esta ficará no sistema com o status de zombie. Precisamos controlar manualmente este processo, e fazemos isso através da flag thread_enabled. Ao finalizar a execução do módulo, setamos esta flag na linha 49 e aguardamos a finalização da execução da thread na linha 50.

Para testar, basta enviar “2” ao arquivo de dispositivo do led que se deseja piscar. Por exemplo, para piscar o led 3:

$ echo 2 > /dev/leds3

O código completo deste device driver pode ser baixado aqui.

A interface kernel_thread é antiga, propensa a bugs, e não deve ser usada em novos projetos. A frase abaixo é da própria documentação do kernel, disponível em “documentation/feature-removal-schedule.txt”:

“kernel_thread is a low-level implementation detail. Drivers should use the <linux/kthread.h> API instead which shields them from implementation details and provides a higherlevel interface that prevents bugs and code duplication”.

É por isso que você deve esquecer tudo que leu acima… brincadeira! É bem capaz que você encontre um ou outro device driver usando esta API, por isso é bom conhecê-la. Mas você verá que com a interface kthread as coisas são muito mais fáceis.

A INTERFACE KTHREAD

Os conceitos são os mesmos. A interface kthread na verdade utiliza a função kernel_thread internamente, mas abstraindo alguns conceitos, e tornando-a mais simples e segura de usar:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

#define BLINK_TIME  1000
 
/* kernel thread to blink the leds */
static int leds_blink(void *unused)
{
    int i;
 
    while (!kthread_should_stop()) {
 
        for (i = 0; i < NUM_LEDS; i++) {
            if (leds_dev[i].status == LED_BLINK) {
                changeLedStatus(leds_dev[i].number, LED_BLINK);
            }
        }
 
        msleep(BLINK_TIME);
    }
 
    return(0);
}
 
/* driver initialization */
int __init leds_init(void)
{
    ...
 
    /* initialize leds_blink therad */
    leds_blink_task = kthread_run(leds_blink, NULL, "%s", "leds_blink");
 
    ....
}
 
/* driver exit */
void __exit leds_exit(void)
{
    ...
 
    /* stop thread */
    kthread_stop(leds_blink_task);
 
    ...
}

Veja como ficou simples. Usamos apenas 3 funções: kthread_run() para iniciar a thread (linha 28), kthread_should_stop() para que a thread saiba quando deve finalizar sua execução (linha 8) e kthread_stop() para finalizar a thread (linha 39).

O código completo deste device driver pode ser baixado aqui.

Vocês viram como é fácil usar threads no kernel do Linux. Mas devemos ter sempre muito cuidado com o que fazemos em kernel space. Dentro do kernel, temos acesso completo a todos os recursos da máquina. E com o poder vem a responsabilidade. Portanto, use este recurso com sabedoria.

Um abraço,

Sergio Prado

Posts relacionados:

1. Linux Device Drivers — Parte 1
2. Linux Device Drivers — Parte 2
3. Device Drivers e gerenciamento dinâmico de dispositivos

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em Linux Device Drivers — Trabalhando com Kernel Threads.

Em uma “promoção relâmpago” da Netrino, tive a oportunidade de comprar seu padrão para desenvolvimento de software embarcado em C por míseros $9.

Assim como todo bom padrão de codificação, seu objetivo é diminuir a quantidade de bugs, melhorar a legibilidade, a manutenibilidade e a portabilidade de seus códigos em C.

Quem acompanha meu blog sabe da importância que dou para este tipo de assunto, vide meus artigos sobre a história e os padrões da linguagem C, e o padrão MISRA-C.

Mas este documento da Netrino define algumas normas que se aproximam bastante da nossa realidade como desenvolvedor de software embarcado em C, já que não é tão aberto à interpretações como o padrão C99, nem tão restritivo quanto o MISRA-C.

Michael Barr, autor do documento, e que já foi entrevistado por mim aqui, é uma personalidade conhecida no mercado mundial de embarcados, e teve a ajuda de outras personalidades como Nigel Jones, Jack Ganssle e Jean Labrosse na elaboração do padrão.

A principal premissa seguida pelo documento é a de que existe um trabalho contínuo em um produto com software embarcado. Apesar de alguns desenvolvedores pensarem o contrário, o código que você esta desenvolvendo não é seu, e sim da empresa em que atua! A não ser que esta empresa seja sua mesmo…:)

E um dia você, ou outra pessoa, precisará dar manutenção no código. Ou então o código é complexo o bastante para envolver uma equipe de vários desenvolvedores, cada um trabalhando em um módulo do software. Como coordenar este trabalho conjunto? Como garantir que todos “falarão a mesma língua”? Sem um padrão, fica realmente muito difícil.

E tem muita coisa boa nesse documento, incluindo regras como:

• Todo bloco deve explicitamente abrir e fechar chaves.
• Ser explícito no uso de parênteses.
• Usar #if 0 para comentar código.
• Escrever comentários antes de começar a codificar, mesmo porque você deve saber explicar o algoritmo antes de escrever uma linha de código.
• Usar o Doxygen para gerar documentação do código.
• Usar uma ferramenta de Lint para análise estática de código (escrevi um artigo sobre análise estática de código aqui).
• Usar um Code Beautifier para formatar o código (eu uso o astyle).
• Definir uma variável apenas quando precisar dela, o que facilita a leitura do código e está dentro do padrão C99.

Confesso que não concordei 100% com o documento, como por exemplo as regras abaixo:

• Manter o código-fonte limitado a 80 colunas. Isso fazia sentido quando desenvolvíamos em monitores monocromáticos e imprimíamos o código em impressoras matriciais. Hoje, na minha opinião, já não é tão importante assim.
• Não usar goto, continue e break. Ainda acho que estas palavras-chave possuem alguma utilidade bem específica. Este meu post sobre goto pode explicar.
• Não usar short ou long. Por quê? Desde que protegidas com typedef, não vejo motivo em não utilizá-las.
• Não usar vírgula na declaração de variáveis. Esta regra visa resolver problemas do tipo “char * x, y;”, quando queremos declarar ambas variáveis como ponteiro. Neste caso, o correto seria “char *x, *y;”. Mas discordo que, por causa deste tipo de problema, precisamos necessariamente declarar cada variável em uma linha. Uma função com 5 variáveis do tipo char precisaria de 5 linhas para declará-las. Acho isso desnecessário, e pode até piorar a legibilidade do código. Acredito que devemos tratar o caso da declaração de ponteiros como exceção, e não como regra.

Ao todo, são 105 páginas com boas práticas de desenvolvimento em C para sistemas embarcados. No final do documento o autor disponibiliza modelos de arquivo fonte (.c) e header (.h).

Se você tiver a oportunidade, vale a pena comprar o documento. A propósito, não estou ganhando um centavo com isso, e até acho seu valor demasiado caro.

Mas pensando bem, aquela “uma horinha” que você ou sua equipe perderam procurando um bug no software que poderia ter sido evitado seguindo algumas boas práticas, teriam pago o investimento, e com sobras!

Um abraço,

Sergio Prado

Sem posts relacionados.

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em Netrino’s Embedded C Coding Standard.

Esses dias estava trabalhando em um device driver para Linux de um display LCD de 3.5″, e me deparei com o código abaixo, responsável pela inicialização do display:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189

static int __init s3c24xxfb_probe(struct platform_device *pdev,
                                  enum s3c_drv_type drv_type)
{
    struct s3c2410fb_info *info;
    struct s3c2410fb_display *display;
    struct fb_info *fbinfo;
    struct s3c2410fb_mach_info *mach_info;
    struct resource *res;
    int ret;
    int irq;
    int i;
    int size;
    u32 lcdcon1;
 
    mach_info = pdev->dev.platform_data;
    if (mach_info == NULL) {
        dev_err(&pdev->dev,
                "no platform data for lcd, cannot attach\n");
        return -EINVAL;
    }
 
    if (mach_info->default_display >= mach_info->num_displays) {
        dev_err(&pdev->dev, "default is %d but only %d displays\n",
                mach_info->default_display, mach_info->num_displays);
        return -EINVAL;
    }
 
    display = mach_info->displays + mach_info->default_display;
 
    irq = platform_get_irq(pdev, 0);
    if (irq < 0) {
        dev_err(&pdev->dev, "no irq for device\n");
        return -ENOENT;
    }
 
    fbinfo = framebuffer_alloc(sizeof(struct s3c2410fb_info), &pdev->dev);
    if (!fbinfo)
        return -ENOMEM;
 
    platform_set_drvdata(pdev, fbinfo);
 
    info = fbinfo->par;
    info->dev = &pdev->dev;
    info->drv_type = drv_type;
 
    res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
    if (res == NULL) {
        dev_err(&pdev->dev, "failed to get memory registers\n");
        ret = -ENXIO;
        goto dealloc_fb;
    }
 
    size = (res->end - res->start) + 1;
    info->mem = request_mem_region(res->start, size, pdev->name);
    if (info->mem == NULL) {
        dev_err(&pdev->dev, "failed to get memory region\n");
        ret = -ENOENT;
        goto dealloc_fb;
    }
 
    info->io = ioremap(res->start, size);
    if (info->io == NULL) {
        dev_err(&pdev->dev, "ioremap() of registers failed\n");
        ret = -ENXIO;
        goto release_mem;
    }
 
    info->irq_base = info->io + ((drv_type == DRV_S3C2412) ? S3C2412_LCDINTBASE : S3C2410_LCDINTBASE);
 
    dprintk("devinit\n");
 
    strcpy(fbinfo->fix.id, driver_name);
 
    /* Stop the video */
    lcdcon1 = readl(info->io + S3C2410_LCDCON1);
    writel(lcdcon1 & ~S3C2410_LCDCON1_ENVID, info->io + S3C2410_LCDCON1);
 
    fbinfo->fix.type      = FB_TYPE_PACKED_PIXELS;
    fbinfo->fix.type_aux  = 0;
    fbinfo->fix.xpanstep  = 0;
    fbinfo->fix.ypanstep  = 0;
    fbinfo->fix.ywrapstep = 0;
    fbinfo->fix.accel     = FB_ACCEL_NONE;
 
    fbinfo->var.nonstd      = 0;
    fbinfo->var.activate    = FB_ACTIVATE_NOW;
    fbinfo->var.accel_flags = 0;
    fbinfo->var.vmode       = FB_VMODE_NONINTERLACED;
 
    fbinfo->fbops           = &s3c2410fb_ops;
    fbinfo->flags           = FBINFO_FLAG_DEFAULT;
    fbinfo->pseudo_palette  = &info->pseudo_pal;
 
    for (i = 0; i < 256; i++)
        info->palette_buffer[i] = PALETTE_BUFF_CLEAR;
 
    ret = request_irq(irq, s3c2410fb_irq, IRQF_DISABLED, pdev->name, info);
    if (ret) {
        dev_err(&pdev->dev, "cannot get irq %d - err %d\n", irq, ret);
        ret = -EBUSY;
        goto release_regs;
    }
 
    info->clk = clk_get(NULL, "lcd");
    if (!info->clk || IS_ERR(info->clk)) {
        printk(KERN_ERR "failed to get lcd clock source\n");
        ret = -ENOENT;
        goto release_irq;
    }
 
    clk_enable(info->clk);
    dprintk("got and enabled clock\n");
 
    msleep(1);
 
    info->clk_rate = clk_get_rate(info->clk);
 
    /* find maximum required memory size for display */
    for (i = 0; i < mach_info->num_displays; i++) {
        unsigned long smem_len = mach_info->displays[i].xres;
 
        smem_len *= mach_info->displays[i].yres;
        smem_len *= mach_info->displays[i].bpp;
        smem_len >>= 3;
        if (fbinfo->fix.smem_len < smem_len)
            fbinfo->fix.smem_len = smem_len;
    }
 
    /* Initialize video memory */
    ret = s3c2410fb_map_video_memory(fbinfo);
    if (ret) {
        printk(KERN_ERR "Failed to allocate video RAM: %d\n", ret);
        ret = -ENOMEM;
        goto release_clock;
    }
 
    dprintk("got video memory\n");
 
    fbinfo->var.xres = display->xres;
    fbinfo->var.yres = display->yres;
    fbinfo->var.bits_per_pixel = display->bpp;
 
    s3c2410fb_init_registers(fbinfo);
 
    s3c2410fb_check_var(&fbinfo->var, fbinfo);
 
    ret = s3c2410fb_cpufreq_register(info);
    if (ret < 0) {
        dev_err(&pdev->dev, "Failed to register cpufreq\n");
        goto free_video_memory;
    }
 
    ret = register_framebuffer(fbinfo);
    if (ret < 0) {
        printk(KERN_ERR "Failed to register framebuffer device: %d\n",
               ret);
        goto free_cpufreq;
    }
 
    /* create device files */
    ret = device_create_file(&pdev->dev, &dev_attr_debug);
    if (ret) {
        printk(KERN_ERR "failed to add debug attribute\n");
    }
 
    printk(KERN_INFO "fb%d: %s frame buffer device\n",
           fbinfo->node, fbinfo->fix.id);
 
    return 0;
 
free_cpufreq:
    s3c2410fb_cpufreq_deregister(info);
free_video_memory:
    s3c2410fb_unmap_video_memory(fbinfo);
release_clock:
    clk_disable(info->clk);
    clk_put(info->clk);
release_irq:
    free_irq(irq, info);
release_regs:
    iounmap(info->io);
release_mem:
    release_resource(info->mem);
    kfree(info->mem);
dealloc_fb:
    platform_set_drvdata(pdev, NULL);
    framebuffer_release(fbinfo);
    return ret;
}

Esqueça um pouco o que a função faz, e perceba como ela implementa o tratamento de erros. Para cada erro identificado, ela usa chamadas a goto para tratar o erro e fazer uma limpeza antes de retornar da função (desalocar buffers previamente alocados, liberar recursos, configurar portas de I/O, etc). São ao todo oito chamadas a goto apenas nesta função!

Não aprendemos que usar goto é uma técnica ruim? Também não aprendemos que todo código bem estruturado em C não deve ter nenhuma chamada a goto? Então como é possível encontrar um código assim dentro do kernel do Linux?

NÃO SE ASSUSTE

Usar goto em código C pode ser mais comum do que você imagina. Fiz um levantamento do uso da palavra-chave “goto” no kernel do Linux 2.6.37, no Busybox e no U-Boot.

Apenas o core do kernel (/kernel), possui 1.417 usos de goto. Quando incluimos os drivers de dispositivo (/drivers) e o código dependente de arquitetura (/arch) são 54.223 usos de goto. Fazendo a contagem completa, chegamos ao impressionante numero de 84.719 usos de goto no kernel do Linux!

Mas não é só o kernel do Linux que abusa de goto. O pacote Busybox, comum em sistemas embarcados com Linux, usa o goto 1.782 vezes. E o famoso bootloader U-Boot utiliza em 1.662 oportunidades.

Ok Sergio, então você esta me dizendo que estou livre para usar e abusar de goto no meu código?

Calma aí, não é bem assim!

BAIXANDO O NÍVEL

Veja o código que o compilador gcc gera em uma chamada a goto, comparando o fonte em C e o arquivo assembly gerado:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

int main()
{
    int i = 1;
 
    if (i) {
        printf("Goto error!\n");
        goto error;
    }
 
    printf("OK!\n");
 
    return 0;
 
error:
    return 1;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

    .file   "goto.c"
    .section    .rodata
.LC0:
    .string "Goto error!"
.LC1:
    .string "OK!"
    .text
.globl main
    .type   main, @function
main:
    pushl   %ebp
    movl    %esp, %ebp
    andl    $-16, %esp
    subl    $32, %esp
    movl    $1, 28(%esp)
    cmpl    $0, 28(%esp)
    je  .L2
    movl    $.LC0, (%esp)
    call    puts
    nop
.L3:
    movl    $1, %eax
    jmp .L4
.L2:
    movl    $.LC1, (%esp)
    call    puts
    movl    $0, %eax
.L4:
    leave
    ret
    .size   main, .-main
    .ident  "GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3"
    .section    .note.GNU-stack,"",@progbits

Veja que o if na linha 5 do fonte C gera uma chamada a “je .L2″ (jump condicional) na linha 17 do código Assembly. E o goto na linha 7 do fonte C gera uma chamada a “jmp .L4″ (jump) na linha 23 do código assembly.

Perceba que, na prática, tudo é tratado com uma instrução de salto no nível do assembly, não importa se você esta usando goto, if/else, switch, do/while ou for. Não existe nenhum impacto na performance ou no uso de memória da aplicação. Na verdade, em alguns casos, o uso de goto pode até melhorar a performance da aplicação. Mas normalmente seu uso é uma questão de legibilidade do código.

Os mais puristas afirmam que não existe nada que se escreva usando goto, que não possa ser escrito usando as estruturas de controle disponíveis na linguagem C (if/else, switch, do/while, for), e durante um bom tempo também acreditei nisso. Mas na prática, às vezes, a teoria é diferente! E existem alguns casos onde o uso de goto pode ser a melhor solução.

Sergio, você já não falou que é contra o uso de goto em código C? Sim, mas isso não muda o fato de que pode existir uma forma de utilizar esta palavra-chave melhorando a estrutura e a legibilidade do seu programa.

Mas você também não esta sempre defendendo qualidade de código, segurança, bla bla bla, e agora vem me falar que existe uma utilidade para o uso de “goto”? Sim, existe! É só olhar para os números (e para o código-fonte do kernel do Linux, e para outros tantos códigos open-source). Essa utilidade chama-se: Tratamento de Erros!

O PROBLEMA EM QUESTÃO

Uma das deficiências da linguagem C é a ausência de um mecanismo simples e eficiente de tratamento de erros. Já escrevi sobre isso neste post aqui.

O problema fica mais transparente quando precisamos lidar com limpeza (desalocação) de recursos. Dê uma olhada no exemplo abaixo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

int initRTC()
{
    char *buf1, *buf2;
 
    if ((buf1 = (char *)malloc(20)) == NULL)
        return ERR_RTC_MALLOC;
 
    if ((buf2 = (char *)malloc(40)) == NULL) {
        free(buf1);
        return ERR_RTC_MALLOC;
    }
 
    if (openRTC()) {
        free(buf2);
        free(buf1);
        return ERR_RTC_OPEN;
    }
 
    if (cfgRTC(buf1, 20, buf2, 40)) {
        closeRTC();
        free(buf2);
        free(buf1);
        return ERR_RTC_CFG;
    }
 
    if (txCmd(buf1, 20, buf2, 40)) {
        closeRTC();
        free(buf2);
        free(buf1);
        return ERR_RTC_TX;
    }
 
    closeRTC();
    free(buf2);
    free(buf1);
 
    return RTC_OK;
}

Esta função faz duas alocações de memória, abre a comunicação com o RTC, configura os buffers e transmite. Perceba que existe vários pontos de retorno.

Na linha 8, em caso de erro na chamada a malloc() para o buf2, é necessário liberar a memória alocada para buf1 antes de retornar. Da mesma forma, se der erro ao abrir a comunicação com o RTC na linha 13, é necessário liberar a memória alocada em buf1 e buf2. E por aí vai.

Para cada ponto de retorno adicional, precisamos lembrar de fazer a limpeza necessária antes de retornar. Veja que os trechos de código responsáveis pela limpeza são replicados nos vários pontos de retorno. Imagine o problema e os riscos envolvidos em dar manutenção num código desse tipo.

Veja agora a mesma função reescrita usando goto:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

int initRTC()
{
    char *buf1, *buf2;
    int ret = RTC_OK;
 
    if ((buf1 = (char *)malloc(20)) == NULL) {
        ret = ERR_RTC_MALLOC;
        goto fim0;
    }
 
    if ((buf2 = (char *)malloc(40)) == NULL) {
        ret = ERR_RTC_MALLOC;
        goto fim1;
    }
 
    if (openRTC()) {
        ret = ERR_RTC_OPEN;
        goto fim2;
    }
 
    if (cfgRTC(buf1, 20, buf2, 40)) {
        ret = ERR_RTC_CFG;
        goto fim3;
    }
 
    if (txCmd(buf1, 20, buf2, 40)) {
        ret = ERR_RTC_TX;
        goto fim3;
    }
 
fim3:
    closeRTC();
fim2:
    free(buf2);
fim1:
    free(buf1);
fim0:
    return ret;
}

Agora a função tem apenas um ponto de retorno e não existe mais código replicado para fazer a limpeza (desalocação de recursos) em caso de erro, o que facilita a leitura e futuras manutenções. Me parece uma solução interessante para um problema comum e sem solução fácil em C.

É claro que existem outros mecanismos para resolver este mesmo problema. Você pode criar uma máquina de estados, conforme o exemplo abaixo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

int initRTC()
{
    char *buf1, *buf2;
    int ret = RTC_OK, state = ST_BUF1;
 
    while (state != ST_DONE) {
 
        switch(state) {
 
            case ST_BUF1:
                if ((buf1 = (char *)malloc(20)) == NULL) {
                    ret = ERR_RTC_MALLOC;
                    state = ST_DONE;
                }
                else {
                    state = ST_BUF2;
                }
                break;
 
            case ST_BUF2:
                if ((buf2 = (char *)malloc(40)) == NULL) {
                    ret = ERR_RTC_MALLOC;
                    state = ST_ERR_BUF2;
                }
                else {
                    state = ST_OPEN_RTC;
                }
                break;
 
            case ST_OPEN_RTC:
                if (openRTC()) {
                    ret = ERR_RTC_OPEN;
                    state = ST_ERR_OPEN;
                }
                else {
                    state = ST_CFG_RTC;
                }
                break;
 
            // ....
 
            case ST_ERR_BUF2:
                free(buf1);
                state = ST_DONE;
                break;
 
            case ST_ERR_OPEN:
                free(buf2);
                state = ST_ERR_BUF2;
                break;
 
            case ST_ERR_TX:
                closeRTC();
                state = ST_ERR_OPEN;
                break;
 
            // ....
        }
    }
 
    return ret;
}

Não implementei todos os estados, mas dá para ter uma idéia do mecanismo utilizado. Perceba a complexidade deste código, comparado ao código com goto.

Podemos também aninhar chamadas if/else e controlar a desalocação de recursos com alguns flags:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

int initRTC()
{
    char *buf1, *buf2;
    int ret = RTC_OK;
 
    if ((buf1 = (char *)malloc(20)) == NULL) {
        ret = ERR_RTC_MALLOC1;
    }
    else if ((buf2 = (char *)malloc(40)) == NULL) {
        ret = ERR_RTC_MALLOC2;
    }
    else if (openRTC()) {
        ret = ERR_RTC_OPEN;
    }
    else if (cfgRTC(buf1, 20, buf2, 40)) {
        ret = ERR_RTC_CFG;
    }
    else if (txCmd(buf1, 20, buf2, 40)) {
        ret = ERR_RTC_TX;
    }
 
    if (ret >= ERR_RTC_CFG) {
        closeRTC();
    }
 
    if (ret >= ERR_RTC_OPEN) {
        free(buf2);
    }
 
    if (ret >= ERR_RTC_MALLOC2) {
        free(buf1);
    }
 
    return ret;
}

Neste exemplo estamos usando a própria variável de retorno como flag para desalocação de recursos. O problema deste tipo de código é que nem sempre temos a possibilidade de aninhar if’s e else’s desta forma. Esta técnica pode também deixar o código muito sujo, dependendo da sua complexidade.

Ainda neste exemplo, você poderia usar o próprio estado do recurso para verificar se deve realizar a desalocação, implementando no fim da função:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

    //...
 
    if (rtcOpenned) {
        closeRTC();
    }
 
    if (buf2 != NULL) {
        free(buf2);
    }
 
    if (buf1 != NULL) {
        free(buf1);
    }
 
    //...

Mas nem sempre você tem o controle de quais recursos precisa desalocar. De qualquer forma, o código com if/else aninhados ainda continua mais complicado de ler, quando comparado à solução com goto.

ONDE ESTA O PROBLEMA ENTÃO?

Se o código com goto neste caso é menos complicado de ler, e o binário gerado não sofre nenhum impacto na performance ou no uso de memória, porque não usá-lo?

Assim como grande parte dos problemas da vida, o erro esta no excesso. É muito fácil abusar deste recurso, e deixar o código cheio de “idas” e “vindas” (o famoso código-espaguete!).

Foi o que aconteceu no passado, e isso ajudou a criar a má reputação do uso de goto. Pense sempre nos prós e contras, reflita sobre sua forma de pensar e use os recursos disponíveis na linguagem com muita sabedoria.

Não foi meu objetivo neste artigo fazer qualquer tipo de apologia ao uso de “goto” em linguagem C, muito pelo contrário! Particularmente evito seu uso sempre que possível. Apenas acho válida uma análise mais profunda de nossos paradigmas de programação. Eu procuro sempre “guardar na manga” algumas técnicas para usar quando necessário.

E você? O que acha do uso de goto em linguagem C? Conhece alguma outra técnica para tratar o problema citado acima?

Um abraço,

Sergio Prado

Posts relacionados:

1. Tratamento de erros em Linguagem C

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em Você usa goto nos seus códigos em C?.

Conforme expliquei no meu primeiro artigo sobre device drivers, tudo em Linux são arquivos. Expliquei também que todo acesso ao hardware é realizado através de arquivos no diretório /dev. Portanto, sempre que você precisar acessar determinado hardware, seu arquivo de dispositivo deve estar presente em /dev. Obs: em alguns casos bem específicos, o hardware pode ser acessado via /proc ou /sys.

Nos primeiros anos de vida do Linux, a quantidade de dispositivos suportados era apenas uma pequena fração do que é hoje. Naquela época, para cada hardware suportado pelo sistema operacional, criava-se um arquivo estático em /dev.

À medida que o kernel foi evoluindo com a adição de novos drivers de dispositivo, a quantidade de arquivos criados em /dev começou a crescer exponencialmente, tornando difícil seu gerenciamento, e acabando aos poucos com a disponibilidade de major e minor numbers que podiam ser atribuídos à outros dispositivos. No RedHat 9, por exemplo, existiam 19.000 arquivos de dispositivo em /dev!

Além disso, sempre que você adicionasse um hardware não suportado nativamente pelo kernel, você precisaria adicionar um arquivo de dispositivo manualmente com o comando mknod. Foi o que fizemos no segundo artigo sobre device drivers, para acessar os leds do kit FriendlyARM mini2440:

$ mknod /dev/led1 c 253 0
$ mknod /dev/led2 c 253 1
$ mknod /dev/led3 c 253 2
$ mknod /dev/led4 c 253 3

Em determinado momento, os desenvolvedores do kernel precisaram buscar uma solução que possibilitasse a criação dinâmica de arquivos de dispositivo. Então nasceu o devfs.

DEVFS

O devfs é um sistema de arquivos virtual criado para representar dinamicamente todos os dispositivos conectados ao sistema. Isso significa que, no boot, bastaria você montar o devfs no /dev, conforme abaixo:

$ mount -t devfs none /dev

Para cada hardware adicionado ou removido, o kernel atualizaria este sistema de arquivos virtual, refletindo diretamente no diretório /dev. Pareceu uma solução boa, e resolveu o problema de ter uma lista enorme de arquivos criados em /dev.

Porém, toda sua implementação estava em kernel space. Isso significa que, se por exemplo inserirmos um dispositivo não suportado pelo kernel, ainda teríamos que usar o comando mknod para criá-lo manualmente. Além disso, o nome dos dispositivos eram estáticos e não poderiam ser mudados, além da implementação ter alguns bugs.

Foi então que, para corrigir estas deficiências, criou-se a arquitetura de hotplug do kernel, e um tempo depois o udev foi implementado.

HOTPLUG E UDEV

A arquitetura de hotplug do kernel levou toda a implementação do devfs para userspace. A única responsabilidade do kernel nesta arquitetura é notificar o userspace quando um hardware é inserido, removido, etc. Esta implementação deu uma flexibilidade muito maior para o gerenciamento dos arquivos de dispositivo.

Nesta arquitetura, o kernel pode trabalhar de duas formas:

1. O kernel notifica o userspace através da chamada à um processo definido em /proc/sys/kernel/hotplug (no começo usava-se o /sbin/hotplug).
2. O kernel notifica o userspace através de um socket do tipo netlink. Qualquer processo que estiver “escutando” este socket irá receber as notificações (que também são chamadas de uevents).

Então surgiu a implementação do udev para se beneficiar destas facilidades do kernel. No começo, o udev usava o primeiro mecanismo, trocando o /sbin/hotplug pelo /sbin/udevsend. Depois, ele passou a usar o segundo mecanismo, através da implementação do processo udevd para escutar os eventos no netlink socket. Desde então, o uso do udevd é padrão na maioria das distribuições Linux atuais.

fonte: http://free-electrons.com/

A notificação enviada em ambos os casos (processo ou socket) é idêntica. O evento gerado pelo kernel, ao invés de trazer todas as informações do dispositivo conectado, traz apenas um identificador do dispositivo. A partir deste identificador, o udev busca as informações necessárias no diretório /sys. Este diretório, que também é montado a partir de um sistema de arquivos virtual (sysfs), contém dados detalhados do hardware do sistema, e é de suma importância para a arquitetura de hotplug do kernel.

Basicamente, o que acontece em um sistema com udev é o seguinte:

1. No boot, o kernel gera eventos para todos os dispositivos identificados no /sys, o udevd captura estes eventos e cria no /dev os arquivos de dispositivo para o hardware presente no sistema. Este procedimento é chamado de coldplugging.
2. Para cada novo evento, o kernel envia uma nova notificação, o udev captura esta notificação trata. Este procedimento é chamado de hotplugging.

Uma explicação mais detalhada sobre o mecanismo de hotplug pode ser encontrado aqui.

O usuário poderá definir regras para o tratamento das notificações enviadas pelo kernel, e a grande vantagem desta arquitetura é a criação de regras persistentes. O udev resolve problemas do tipo: quando conectar este pendrive, quero que seja sempre atribuído a ele o arquivo de dispositivo /dev/mypendrive.

Outro exemplo: imagine que você tenha duas impressoras, uma jato de tinta e outra à laser. A primeira impressora identificada pelo kernel será a /dev/lp0, e a segunda a /dev/lp1. Isso significa que o nome do arquivo associado à impressora vai depender da ordem de identificação do hardware pelo kernel. Isso pode causar um problema para as aplicações, já que não existe uma garantia de que a impressora à laser estará sempre em /dev/lp0, por exemplo. Mas podemos resolver este problema com a criação de uma regra no udev.

No udev, as regras são salvas em /etc/udev/rules.d, e para cada evento recebido, o udev procura uma regra que se encaixe. No exemplo abaixo, conseguimos garantir que a impressora à laser, que possui o número serial “L72010011070626380”, será sempre associada ao arquivo de dispositivo /dev/printer/laser:

SUBSYSTEM=="usb", ATTRS{serial}=="L72010011070626380", SYMLINK+="printer/laser"

Um artigo bem completo sobre como criar regras no udev pode ser lido aqui. Além da criação de arquivos de dispositivo, o udev também é capaz de carregar drivers ou baixar um firmware no hardware conectado.

A implementação do udev é bem compacta (no meu desktop com Ubuntu ela tem apenas 100K), mas para sistemas embarcados com recursos bem escassos, podemos recorrer implementações mais enxutas como o mdev do nosso bom e velho amigo Busybox.

MDEV

O mdev é uma implementação do udev dentro do Busybox.

Vamos ver então um exemplo prático de como usar o mdev para criar dinamicamente os arquivos de dispositivo do device driver que desenvolvemos para controlar os leds do kit FriendlyARM mini2240.

PREPARADO O KERNEL

O kernel precisa ser compilado com a opção CONFIG_HOTPLUG habilitada. Para verificar se seu kernel foi compilada com esta opção habilitada, veja se o arquivo /proc/sys/kernel/hotplug existe. Se não existir, você precisará habilitá-lo e recompilar o kernel.

PREPARANDO O BUSYBOX

O Busybox precisa estar configurado para gerar o mdev. Esta opção vem habilitada no config padrão do Busybox, mas se não estiver, você precisará habilitá-la com as opções abaixo:

Linux System Utilities
    [*] mdev
    [*]   Support /etc/mdev.conf

COMANDOS NO BOOT

Altere uns dos scripts de inicialização e insira os dois comandos abaixo:

$ echo /sbin/mdev > /proc/sys/kernel/hotplug
$ mdev -s

O primeiro comando serve para configurar o processo que irá receber os eventos do kernel. O segundo comando serve para inicializar o /dev no boot com os dispositivos listados no /sys.

Obs: Antes de executar estes comandos, certifique-se de que os diretórios /proc, /sys e /dev estejam montados e disponíveis.

ALTERANDO O DEVICE DRIVER

Para quem não acompanhou, desenvolvemos um device driver para controlar os leds do kit FriendlyARM mini2440 neste artigo aqui. Agora, iremos alterá-lo para criar as entradas necessárias no /sys e enviar eventos ao udev (no nosso caso mdev), para que este gere automaticamente os arquivos de dispositivo em /dev.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

/* class for the sysfs entry */
struct class *leds_class;
 
/* driver initialization */
int __init leds_init(void)
{
    int ret, i;
 
    /* request device major number */
    if ((ret = alloc_chrdev_region(&leds_dev_number, 0, NUM_LEDS, DEVICE_NAME) < 0)) {
        printk(KERN_DEBUG "Error registering device!\n");
        return ret;
    }
 
    /* create /sys entry */
    leds_class = class_create(THIS_MODULE, DEVICE_NAME);
 
    /* init leds GPIO port */
    initLedPort();
 
    /* init each led device */
    for (i = 0; i < NUM_LEDS; i++) {
 
        /* init led status */
        leds_dev[i].number = i + 1;
        leds_dev[i].status = LED_OFF;
 
        /* connect file operations to this device */
        cdev_init(&leds_dev[i].cdev, &leds_fops);
        leds_dev[i].cdev.owner = THIS_MODULE;
 
        /* connect major/minor numbers */
        if ((ret = cdev_add(&leds_dev[i].cdev, (leds_dev_number + i), 1))) {
            printk(KERN_DEBUG "Error adding device!\n");
            return ret;
        }
 
        /* init led status */
        changeLedStatus(leds_dev[i].number, LED_OFF);
 
        /* send uevent to udev to create /dev node */
        device_create(leds_class, NULL, MKDEV(MAJOR(leds_dev_number), i), NULL, "leds%d", i);
    }
 
    printk("Leds driver initialized.\n");
 
    return 0;
}
 
/* driver exit */
void __exit leds_exit(void)
{
    int i;
 
    /* release major number */
    unregister_chrdev_region(leds_dev_number, NUM_LEDS);
 
    /* delete devices */
    for (i = 0; i < NUM_LEDS; i++) {
        device_destroy(leds_class, MKDEV(MAJOR(leds_dev_number), i));
        cdev_del(&leds_dev[i].cdev);
    }
 
    /* destroy class */
    class_destroy(leds_class);
 
    printk("Exiting leds driver.\n");
}

Na linha 2 declaramos o ponteiro que irá armazenar a estrutura com as informações do dispositivo no /sys. Na linha 16, com a função class_create(), criamos esta estrutura. Esta chamada criará a entrada /sys/class/leds.

Na linha 42, a função device_create() é chamada para cada led. É na chamada desta função que o kernel irá enviar uma notificação de evento para o mdev. Ao receber este evento, o mdev irá automaticamente criar um arquivo de dispositivo no /dev.

Ao inserir o módulo, serão criadas automaticamente as seguintes entradas:

$ ls -la /sys/class/leds/
total 0
drwxr-xr-x    6 root     root             0 Oct 29 17:46 .
drwxr-xr-x   29 root     root             0 Oct 29 17:46 ..
drwxr-xr-x    2 root     root             0 Oct 29 17:46 leds0
drwxr-xr-x    2 root     root             0 Oct 29 17:46 leds1
drwxr-xr-x    2 root     root             0 Oct 29 17:46 leds2
drwxr-xr-x    2 root     root             0 Oct 29 17:46 leds3
$ ls -la /dev/leds*
crw-rw----    1 root     root      251,   0 Jan 21  2011 /dev/leds0
crw-rw----    1 root     root      251,   1 Jan 21  2011 /dev/leds1
crw-rw----    1 root     root      251,   2 Jan 21  2011 /dev/leds2
crw-rw----    1 root     root      251,   3 Jan 21  2011 /dev/leds3

Da mesma forma, ao remover o modulo, a função leds_exit() será executada, e a chamada à device_destroy() na linha 60 fará com que o kernel envie uma mensagem para o mdev remover os arquivos de dispositivo previamente criados.

Vejam que, com poucas linhas de código, conseguimos tornar dinâmico o gerenciamento de arquivos de dispositivo do nosso device driver. O código-fonte completo do device driver pode ser baixado aqui.

No próximo artigo iremos aprender sobre mais algumas funções da API kernel, usar timers e transformar os leds em pisca-piscas. Até lá!

Um abraço,

Sergio Prado

Posts relacionados:

1. Linux Device Drivers — Parte 1
2. Mini2440 — Compilando aplicações e device drivers
3. Linux Device Drivers — Parte 2

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em Device Drivers e gerenciamento dinâmico de dispositivos.

Em qualquer livro de programação, normalmente as primeiras páginas são voltadas à história da linguagem (e são também as páginas que não lemos ou damos uma “passada bem rápida”). Mas conhecer a origem da linguagem pode nos ajudar a entender um pouco suas características.

C é uma linguagem desenvolvida por engenheiros e para engenheiros. Foi criada em 1972 por Dennis Ritchie para ser usada no desenvolvimento sistema operacional Unix no Bell Labs, que na época pertencia à AT&T (hoje parte da Alcatel-Lucent). C foi derivada da linguagem B, desenvolvida por Ken Thompson, que por sua vez se baseou-se na linguagem BCPL.

Ritchie e Thompson também participaram da equipe de desenvolvimento do UNIX, cujas primeiras versões foram totalmente desenvolvidas em Assembly. Em um certo momento, eles sentiram a necessidade de uma linguagem mais portável para implementar o Unix no PDP-11.

Esta linguagem precisava prover acesso de baixo nível ao hardware (PCU, I/Os e periféricos) e se entender bem com o Assembly, precisava ser portável para que o SO pudesse rodar em diferentes plataformas de hardware, além de ter um bom desempenho e otimizar o uso de memória, principalmente numa época em que estavam começando a surgir as primeiras CPUs, e o preço por byte de memória era caríssimo. Foi portanto destas necessidades que surgiu a linguagem C.

Deste então, 99,99999% das arquiteturas de CPU possuem a implementação de um compilador C. De mainframes, supercomputadores e minicomputadores, a celulares, relógios e torradeiras. É difícil encontrar uma plataforma de hardware sem um compilador C compatível.

O PRIMEIRO PADRÃO

O livro “The C Programming Language”, publicado em 1978 por Brian Kernighan e Dennis Ritchie, foi considerado o padrão de facto da linguagem C durante muitos anos, até sair o padrão ANSI C. Este padrão informal também ficou conhecido como “K&R C”.

É provavelmente o livro de C que mais se vendeu até hoje, por vários motivos. Dentre eles, foi o primeiro livro de C disponível de forma mais abrangente, um dos autores do livro é o próprio criador da linguagem, é escrito de forma clara e possui poucas páginas, comparado à outras “bíblias” que vemos por aí. Todo desenvolvedor C deveria ter sua cópia.

A segunda edição do livro foi lançada em 1988 e atualizada para ficar de acordo com o padrão ANSI C.

OS PADRÕES ANSI C E ISO C

Durante a década de 80 “choveram” implementações de compiladores C, já que naquela época a semântica da linguagem estava aberta à interpretações. Surgiu então a necessidade de um padrão formal da linguagem.

Este padrão foi desenvolvido pelo ANSI (American National Standards Institute), que formou um comitê e ratificou o padrão em 1989 como ANSI X3.159‑1989 “Programming Language C”, também conhecido com ANSI C ou C89.

Um ano depois o padrão foi adotado pela ISO (International Organization for Standardization) como ISO/IEC 9899:1990, também chamado de C90. Na prática, C89 (ANSI C) e C90 (ISO C) referem-se ao mesmo padrão.

A partir de 1990, a ISO ficou responsável pela evolução do padrão. O endereço oficial do grupo é este aqui, e um draft do padrão pode ser visto aqui.

O que eles fizeram foi acrescentar algumas novas características ao padrão anterior K&R C.

As principais mudanças foram a inclusão de protótipos de função, a padronização das bibliotecas e a adição de algumas palavras-chave como enum, const, volatile, signed, void (isso mesmo, estas palavras-chave não existiam formalmente antes do padrão ANSI C).

A maioria do código compilado em K&R C, compila em ANSI C, com algumas exceções. Para tratar estas exceções, foi criado o #define __STDC__, que deveria ser implementado por padrão em todos os compiladores ANSI C. Veja no exemplo abaixo o protótipo da função soma() nos padrões ANSI C e K&R C.

1
2
3
4
5

#if __STDC__
extern int soma(int a, int b);
#else
extern int soma();
#endif

Todos os compiladores modernos suportam ANSI C. E ter um programa compatível com ANSI C significa que este será provavelmente portável para qualquer arquitetura de hardware que possua um compilador ANSI C disponível.

O PADRÃO C99

Na década de 90 a ISO corrigiu alguns detalhes e publicou em 1999 o ISO/IEC 9899:1999, que ficou conhecido como C99. Um draft do padrão pode ser visto aqui.

Dentre as alterações, podemos destacar a inclusão de funções inline, variáveis “long long”, suporte para comentários de uma linha, além de não assumir int quando não é especificado o retorno da função.

Por exemplo, o código abaixo esta de acordo com o padrão C89, mas não compila de acordo com o padrão C99:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

#include "stdio.h"
 
/* Retorna indice do maior elemento do array */
maior(long buf[], int qtd)
{
    long m = 0;
    int i, ind = -1;
 
    for (i = 0; i < qtd; i++) {
        if (buf[i] > m) {
            m = buf[i];
            ind = i;
        }
    }
 
    return(ind);
}
 
main(void)
{
    int m = -1;
 
    long buf[] = { 1234, 3456, 7345, 5897 };
 
    if ((m = maior(buf, 4)) >= 0)
        printf("Maior elemento buf[%d]=%ld\n", m, buf[m]);
    else
        printf("Maior elemento nao encontrado\n", buf[m]);
 
    return 0;
}

Para compilar de acordo com o padrão C99, algumas linhas precisam ser alteradas:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#include "stdio.h"
 
int maior(long long buf[], int qtd);
 
// Retorna indice do maior elemento do array
inline int maior(long long buf[], int qtd)
{
    long long m = 0;
    int i, ind = -1;
 
    for (i = 0; i < qtd; i++) {
        if (buf[i] > m) {
            m = buf[i];
            ind = i;
        }
    }
 
    return(ind);
}
 
int main(void)
{
    int m = -1;
 
    long long buf[] = { 1234, 3456, 7345, 5897 };
 
    if ((m = maior(buf, 4)) >= 0)
        printf("Maior elemento buf[%d]=%lld\n", m, buf[m]);
    else
        printf("Maior elemento nao encontrado\n", buf[m]);
 
    return 0;
}

Para compilar, foi necessário alterar os retornos de função, declarando explicitamente “int”.

Além disso, fizemos algumas alterações permitidas no padrão C99. Alteramos todas as variáveis “long” para “long long”, usamos comentários de uma linha com “//” e declaramos a função maior() como “inline”. 

Com estas alterações o código ficou compatível com o padrão C99, mas perdeu a compatibilidade como padrão ANSI C (C89).

O FUTURO PADRÃO C1X

C1X é um nome não-oficial para um trabalho que começou em 2007, com o objetivo de revisar e definir um novo padrão para a linguagem C. Algumas das alterações propostas podem ser encontradas no site da Wikipedia.

Algumas adições me pareceram bem interessantes: uso das palavras-chave _Generic para declarar uma função que pode receber diferentes tipos de dados e _Atomic para definir que o acesso à determinada variável deve ser atômico; a substituição da função gets() pela gets_s(), cuja implementação é bem mais segura; implementação de estruturas e unions anônimas; etc.

Claro que o padrão atual (C99) é bem maduro, e você deveria usá-lo em todos os seus projetos. O novo padrão pretende adicionar novas funcionalidades para melhorar a vida do desenvolvedor. Eu particularmente gostaria de ver um mecanismo de tratamento de erros ao estilo try-catch-throw do C++. De qualquer forma, deve levar ainda um tempo para o padrão sair, e mais um tempo para os compiladores implementarem.

Nenhum dos documentos oficiais dos padrões esta disponível gratuitamente na internet para download. Mas podemos baixar versões iniciais da especificação, ATAs de reunião e adendos. Esta wiki tem algumas informações interessantes com links para documentos relacionados aos padrões.

Um abraço,

Sergio Prado

Posts relacionados:

1. Otimização de código em Linguagem C — Parte 2
2. Memory leak em linguagem C
3. Tratamento de erros em Linguagem C

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em Linguagem C: História e Padrões.

Na parte 1 desta série de artigos, dei uma introdução sobre o desenvolvimento de drivers de dispositivos em Linux. Vimos detalhes de um sistema com Linux embarcado, a arquitetura do kernel e como as aplicações se comunicam com o hardware.

Neste artigo vamos finalmente colocar a mão na massa e codificar um driver de dispositivo de caractere (char driver). Desenvolveremos o “Hello world!” do software embarcado: acenderemos leds!

Usaremos o kit mini2440, que possui 4 leds disponibilizados nas portas de I/O GPB5 à GPB8. Criaremos 4 arquivos de dispositivo (/dev/led1, /dev/led2, /dev/led3, /dev/led4) para gerenciar o status destes leds. Enviar “1″ para “/dev/led1″ irá acender o led 1, e enviar “0″ irá apagá-lo.

ESQUELETO DE UM DEVICE DRIVER

Muito bem, chega de teorias e bla bla bla. Este é o esqueleto de um device driver:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88

#include "linux/fs.h"
#include "linux/cdev.h"
#include "linux/module.h"
#include "linux/kernel.h"
#include "linux/device.h"
#include "asm/uaccess.h"
#include "asm/io.h"
#include "linux/slab.h"
 
#define DEVICE_NAME     "leds"
 
#define NUM_LEDS        4
 
#define LED_ON          1
#define LED_OFF         0
 
/* per led structure */
struct leds_device {
    int number;
    int status;
    struct cdev cdev;
} leds_dev[NUM_LEDS];
 
/* file operations structure */
static struct file_operations leds_fops = {
    .owner      = THIS_MODULE,
    .open       = leds_open,
    .release    = leds_release,
    .read       = leds_read,
    .write      = leds_write,
};
 
/* leds driver major number */
static dev_t leds_dev_number;
 
/* driver initialization */
int __init leds_init(void)
{
    int ret, i;
 
    /* request device major number */
    if ((ret = alloc_chrdev_region(&leds_dev_number, 0, NUM_LEDS, DEVICE_NAME) < 0)) {
        printk(KERN_DEBUG "Error registering device!\n");
        return ret;
    }
 
    /* init leds GPIO port */
    initLedPort();
 
    /* init each led device */
    for (i = 0; i < NUM_LEDS; i++) {
 
        /* init led status */
        leds_dev[i].number = i + 1;
        leds_dev[i].status = LED_OFF;
 
        /* connect file operations to this device */
        cdev_init(&leds_dev[i].cdev, &leds_fops);
        leds_dev[i].cdev.owner = THIS_MODULE;
 
        /* connect major/minor numbers */
        if ((ret = cdev_add(&leds_dev[i].cdev, (leds_dev_number + i), 1))) {
            printk(KERN_DEBUG "Error adding device!\n");
            return ret;
        }
 
        /* init led status */
        changeLedStatus(leds_dev[i].number, LED_OFF);
    }
 
    printk("Leds driver initialized.\n");
 
    return 0;
}
 
/* driver exit */
void __exit leds_exit(void)
{
    /* release major number */
    unregister_chrdev_region(leds_dev_number, NUM_LEDS);
 
    printk("Exiting leds driver.\n");
}
 
module_init(leds_init);
module_exit(leds_exit);
 
MODULE_LICENSE("GPL");

Para começar, veja que existem duas funções definidas: leds_init(), que será chamada na inicialização do driver, ao ser carregado para a memória; e leds_exit(), que por sua vez será chamada ao remover o driver.

Existem também duas estruturas definidas: leds_dev[] armazena as informações de cada um dos 4 leds, e leds_fops armazena as operações que poderão ser realizadas com os leds (os nomes são auto-explicativos). Dentro de leds_dev[], temos cdev, que é a estrutura que representa um char device.

A primeira tarefa que um driver deve executar é definir o “major number” que estará associado a ele. Ele pode requisitar um determinado número fixo com a função register_chrdev_region(), ou pedir para o kernel gerar um número dinamicamente com a função alloc_chrdev_region(). Requisitar um número fixo pode ser um risco pois não sabemos se ele já esta sendo usado, portanto a solução mais segura é requisitá-lo dinamicamente (é o que fazemos na linha 42).

Na chamada a alloc_chrdev_region(), requisitamos ao kernel a alocação de 4 “minor numbers” (parâmetro 3), começando por “0″ (parâmetro 2) e armazenando o “major number” em leds_dev_number (parâmetro 1). O quarto parâmetro diz ao kernel o nome associado ao driver, que você poderá ver quando listar o dispositivo em “/proc/devices”.

Na linha 51 temos um loop a ser executado para cada device (led) que criaremos. Na linha 58, a função cdev_init() associa a estrutura do led “cdev” (parâmetro 1) às funções de acesso ao arquivo de dispositivo (parâmetro 2).

Na linha 62 é que a mágica acontece. A função cdev_add() associa a estrutura do led cdev (parâmetro 1) ao seu “major e minor number” (parametro 2).

Na prática: quando você realiza uma operação de escrita em /dev/led1 (major=253 e minor=0), o kernel procura a estrutura cdev associada a este device (mesmo major/minor numbers), que você definiu em cdev_add(), e então passa esta estrutura como parâmetro para a função write(), que você associou na chamada a cdev_init(). Simples, não?

Mas como é então a implementação das funções de operação nos arquivos de dispositivo?

ACESSANDO O HARDWARE PELO ARQUIVO DE DISPOSITIVO

Não tem segredo, o conceito é simples:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

/* open led file */
int leds_open(struct inode *inode, struct file *file)
{
    struct leds_device *leds_devp;
 
    /* get cdev struct */
    leds_devp = container_of(inode->i_cdev, struct leds_device, cdev);
 
    /* save cdev pointer */
    file->private_data = leds_devp;
 
    /* return OK */
    return 0;
}
 
/* close led file */
int leds_release(struct inode *inode, struct file *file)
{
    /* return OK */
    return 0;
}
 
/* read led status */
ssize_t leds_read(struct file *file, char *buf, size_t count, loff_t *ppos)
{
    struct leds_device *leds_devp = file->private_data;
 
    if (leds_devp->status == LED_ON) {
        if (copy_to_user(buf, "1", 1))
            return -EIO;
    }
    else {
        if (copy_to_user(buf, "0", 1))
            return -EIO;
    }
 
    return 1;
}
 
ssize_t leds_write(struct file *file, const char *buf, size_t count, loff_t *ppos)
{
    struct leds_device *leds_devp = file->private_data;
    char kbuf = 0;
 
    if (copy_from_user(&kbuf, buf, 1)) {
        return -EFAULT;
    }
 
    if (kbuf == '1') {
        changeLedStatus(leds_devp->number, LED_ON);
        leds_devp->status = LED_ON;
    }
    else if (kbuf == '0') {
        changeLedStatus(leds_devp->number, LED_OFF);
        leds_devp->status = LED_OFF;
    }
 
    return count;
}

A função leds_open() é chamada na abertura do arquivo. Sua única responsabilidade, no nosso caso, é salvar a estrutura leds_dev associada ao device (led), pois usaremos esta estrutura nas funções de leitura e escrita. Isso é feito através da função container_of() na linha 7. O ponteiro para leds_dev é salvo em file->private_data na linha 10.

Na função de leitura leds_read(), recuperamos a estrutura do led leds_dev em file->private_data na linha 26, verificamos o staus do led e retornamos “1″ para aceso e “0″ para apagado. Veja que, para retornar dados para a aplicação, você precisa usar a função copy_to_user(). Esta é uma forma do kernel enviar dados para a aplicação, já que o kernel não “enxerga” a memória dos processos rodando em “user mode”, assim como a aplicações não enxergam a memória dos processos rodando em “kernel mode”.

Na função de escrita leds_write(), também recuperamos a estrutura do led leds_dev em file->private_data na linha 42. E usamos também a função copy_from_user() na linha 45 para ler os dados recebidos da aplicação. E então, dependendo dos dados recebidos (“0″ ou “1″), mudamos o estado dos leds.

Bom, agora falta o principal: as rotinas de acesso às portas de I/O para gerenciar os leds da mini2440.

ESCOVANDO UM POUCO DE BITS

Iremos acessar os leds disponíveis na porta GPB da CPU, conforme configuração abaixo:

Precisamos configurar as portas como saída no registrador GPBCON, e ligar/desligar os leds no registrador GPBDAT. Os leds são acionados em nível baixo.

Esta CPU (S3C2440) mapeia o acesso ao GPB através do endereço de memória 0x56000010. Porém, este é um endereço real, e no kernel você trabalhará sempre com endereços virtuais. Olhando os fontes do kernel, verifiquei que o endereço virtual associado à este endereço real é o 0xFB000010. As definições estão no arquivo “arch/arm/mach-s3c2410/include/mach/regs-gpio.h”.

Vamos então dar uma olhada no código:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

#define GPB_BASE    0xFB000010
#define GPBCON      GPB_BASE
#define GPBDAT      GPB_BASE + 4
 
#define CLEAR_PORT_MASK     0xFFFC03FF
#define SET_WRITE_PORT_MASK 0x00015400
 
/* initialize led port - GPB */
void initLedPort(void)
{
    void __iomem *base = (void __iomem *)GPBCON;
 
    u32 port = __raw_readl(base);
 
    port &= CLEAR_PORT_MASK;
    port |= SET_WRITE_PORT_MASK;
 
    __raw_writel(port, base);
}
 
/* change led status */
void changeLedStatus(int led_num, int status)
{
    void __iomem *base = (void __iomem *)GPBDAT;
    u32 mask, data;
 
    data = __raw_readl(base);
 
    mask = 0x01 << (4 + led_num);
 
    switch (status) {
 
        case LED_ON:
            mask = ~mask;
            data &= mask;
            break;
 
        case LED_OFF:
            data |= mask;
            break;
    }
 
    __raw_writel(data, base);
}

A função initLedPort() é chamada na carga do driver e irá inicializar as portas dos leds (GPB5-GPB8) para trabalhar como saída através do registrado GPBCON (bits 10..17). Na linha 15 zeramos a configuração e na linha 16 configuramos as portas como saída.

Veja que estamos usando as macros __raw_readl() para ler um inteiro de 4 bytes da memória virtual e __raw_writel() para escrever um inteiro de 4 bytes na memória virtual. Esse mecanismo é mais seguro para acessar I/O mapeado em memória em Linux.

A função changeLedStatus() irá mudar o status do led para aceso ou apagado através do registrador GPBDAT (bits 5..8).

COMPILANDO E TESTANDO

O código-fonte completo e o Makefile podem ser baixados aqui. Para compilar, basta seguir os procedimentos que descrevi neste artigo.

Para transferir para a mini2440, você pode colocar a placa em rede com seu PC, e usar alguma aplicação de transferência de arquivos como o scp ou o ftp. Você pode também configurar um sistema de arquivos com NFS, conforme descrevi aqui.

Alguns dos comandos que usaremos para testes assumem que o módulo compilado (leds.ko) foi copiado para a mini2440 no diretório abaixo:

/lib/modules/2.6.32.2-FriendlyARM/kernel/drivers/char/

Portanto, adapte os comandos se necessário.

O primeiro passo é iniciar o driver. Uma mensagem será exibida indicando sucesso na inicialização e todos os leds serão apagados.

$ insmod /lib/modules/2.6.32.2-FriendlyARM/kernel/drivers/char/leds.ko
Leds driver initialized.

Agora você precisa verificar o “major number” alocado pelo kernel para o device driver usando o comando abaixo (veja que, no meu caso, foi alocado o número 253):

$ grep leds /proc/devices
253 leds

Com o “major number” em mãos, criaremos todos os arquivos de dispositivo com os comandos abaixo (mude o valor do major number se necessário):

$ mknod /dev/led1 c 253 0
$ mknod /dev/led2 c 253 1
$ mknod /dev/led3 c 253 2
$ mknod /dev/led4 c 253 3
$ chmod a+w /dev/led*

Obs: No próximo artigo veremos como usar um mecanismo de hotplug para criação dinâmica de arquivos de dispositivo.

Agora é hora de testar. Para acender um led, basta enviar o caracter “1”. Os comandos abaixo acendem os leds 1 e 3:

$ echo "1" > /dev/led1
$ echo "1" > /dev/led3

E para apagar um led, basta enviar “0”:

$ echo "0" > /dev/led3

Para verificar o estado de um led, não podemos apenas ler o arquivo com o comando “cat” por exemplo. Isso porque na rotina que trata a leitura do arquivo, perceba que nunca retornamos EOF (end-of-file). Isso significa que, se por exemplo o led estiver aceso, o comando “cat /dev/led1″ irá imprimir indefinidamente o número “1″. Então, para ler o estado do led, precisamos de um comando que leia apenas 1 byte. Podemos fazer isso com o comando “dd”, salvar o byte em um arquivo, e depois imprimir, conforme abaixo:

$ dd if=/dev/led1 of=/tmp/led bs=1 count=1
$ echo "LED=$(cat /tmp/led)"
LED=1

E finalmente, para remover o driver:

$ rmmod leds
Exiting leds driver.

PRÓXIMOS PASSOS

Muito bem, vocês viram que o assunto deste artigo foi bem denso. Se para você foi muita informação de uma só vez, pare, respire, pense. Estude o código com mais calma, e você verá que não existe nenhum segredo no desenvolvimento de device drivers para Linux. Basta conhecer a API do Linux e escovar um pouco de bits.

No próximo artigo vamos aprender alguns novos conceitos, como criação dinâmica de arquivos de dispositivo, gerenciamento do hardware através do diretório “/sys” e rotinas de timer do kernel (vamos adicionar uma funcionalidade de pisca-pisca ao nosso driver).

Um abraço!

Sergio Prado

Posts relacionados:

1. Mini2440 — Compilando aplicações e device drivers
2. Linux Device Drivers — Parte 1
3. Mini2440 — Linux com U-Boot e Emdebian

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em Linux Device Drivers — Parte 2.

Vimos um tempo atrás como gerar um Linux embarcado do zero com o Buildroot neste artigo aqui. Geramos o toolchain, a imagem do kernel e o rootfs. Mas compilamos apenas com os pacotes disponíveis por padrão no Buildroot. E se agora você quiser compilar uma aplicação ou um device driver e integrar na sua solução. Como podemos usar a infraestrutura gerada pelo Buildroot e cross-compilar qualquer código para ser executado na mini2440. Isso é o que veremos neste artigo.

Obs: Os termos cross-compiling, cross-compilar, cross-compilação e compilação cruzada tem o mesmo significado: compilar uma aplicação em uma arquitetura e gerar código para uma outra arquitetura. No nosso caso iremos compilar em um x86 e gerar código para um ARM.

Como pré-requisito, é necessário que você tenha executado todos os passos do artigo mencionado acima. Para realizar os testes, você pode configurar um ambiente com NFS, conforme expliquei neste artigo aqui.

Vamos utilizar o toolchain gerado pelo Buildroot. Você verá que o processo de compilação cruzada é bem simples, bastando apenas algumas alterações no Makefile do projeto.

COMPILANDO UMA APLICAÇÃO STANDALONE

Este é o código que iremos compilar para testar na mini2440:

1
2
3
4
5
6
7
8
9
10

/* hello.c */
 
#include "stdio.h"
 
int main()
{
    printf("Hello mini2440!\n");
 
    return 0;
}

Se fossemos compilar normalmente em nossa máquina, este seria o Makefile que utilizaríamos:

all:
	@gcc hello.c -o hello
 
clean:
	@rm -Rf *.o hello

Porém, iremos cross-compilar. Isso significa que iremos utilizar um compilador diferente, e o código compilado será linkado com uma biblioteca diferente. Este será o nosso Makefile para cross-compilar a aplicação:

TOOLCHAIN=/opt/buildroot/buildroot-2010.08/output/staging/usr/bin/
CROSS_COMPILE=arm-linux-
 
PATH := ${TOOLCHAIN}:${PATH}
 
all:
	@${CROSS_COMPILE}gcc hello.c -o hello
 
clean:
	@rm -Rf *.o hello

A variável TOOLCHAIN vai depender do local onde você instalou o Buildroot. No meu caso, instalei em “/opt/buildroot/buildroot-2010.08″. Ajuste de acordo com seu ambiente.

Veja que foram apenas 2 mudanças em relação ao Makefile anterior. Alteramos a variável de ambiente PATH para que o sistema encontre os binários do toolchain, e em vez de compilar com o “gcc”, estamos usando o “arm-linux-gcc”.

Os dois arquivos (hello.c e Makefile) devem estar no mesmo diretório. Para compilar, digite apenas “make”. Após a compilação, você pode conferir se o binário foi compilado para a arquitetura correta com o comando “file”:

$ file hello
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

Para testar, copie o binário para o sistema de arquivos que você configurou com o NFS:

$ sudo cp hello /home/mini2440/rootfs/usr/bin/

Agora, entre na console da mini2440 e teste sua aplicação:

$ /usr/bin/hello
Hello mini2440!

COMPILANDO UM DEVICE DRIVER

Para compilar um device driver não é muito diferente ou mais complicado.

Este é um “esqueleto” de um driver simples que escrevi, apenas com as funções de inicialização e finalização, mas que serve para nosso propósito de compilar e testar na mini2440:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77

/* file leds.c */
 
#include "linux/fs.h"
#include "linux/cdev.h"
#include "linux/module.h"
#include "linux/kernel.h"
#include "linux/device.h"
#include "asm/uaccess.h"
#include "linux/slab.h"
 
#define DEVICE_NAME     "leds"
 
#define NUM_LEDS        1
 
int __init leds_init(void);
void __exit leds_exit(void);
 
/* per led structure */
struct leds_device {
    int status;
    struct cdev cdev;
} leds_dev[NUM_LEDS];
 
/* file operations structure */
static struct file_operations leds_fops = {
    .owner      = THIS_MODULE,
};
 
static dev_t leds_dev_number;
 
/* driver initialization */
int __init leds_init(void)
{
    int ret, i;
 
    /* request device major number */
    if ((ret = alloc_chrdev_region(&leds_dev_number, 0, NUM_LEDS, DEVICE_NAME) < 0)) {
        printk(KERN_DEBUG "Error registering device!\n");
        return ret;
    }
 
    /* init each led device */
    for (i = 0; i < NUM_LEDS; i++) {
 
        /* init led status */
        leds_dev[i].status = 0;
 
        /* connect file operations to this device */
        cdev_init(&leds_dev[i].cdev, &leds_fops);
        leds_dev[i].cdev.owner = THIS_MODULE;
 
        /* connect major/minor numbers */
        if ((ret = cdev_add(&leds_dev[i].cdev, (leds_dev_number + i), 1))) {
            printk(KERN_DEBUG "Error adding device!\n");
            return ret;
        }
 
    }
 
    printk("Initializing leds driver.\n");
 
    return 0;
}
 
/* driver exit */
void __exit leds_exit(void)
{
    /* release major number */
    unregister_chrdev_region(leds_dev_number, NUM_LEDS);
 
    printk("Exiting leds driver.\n");
}
 
module_init(leds_init);
module_exit(leds_exit);
 
MODULE_LICENSE("GPL");

Para compilar, este é o Makefile:

TOOLCHAIN := /opt/buildroot/buildroot-2010.08/output/staging/usr/bin/
KDIR := /opt/buildroot/buildroot-2010.08/output/build/linux-2.6/
PWD  := $(shell pwd)
PATH := $(TOOLCHAIN):${PATH}
 
obj-m += leds.o
 
default:
	$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
 
clean:
	@rm -Rf *.o *.ko *.mod.c modules.order Module.symvers

A variável KDIR deve apontar para o diretório do kernel que o Buildroot compilou para a mini2440. Ajuste-a de acordo com seu ambiente. O mesmo deve ser feito novamente com a variável TOOLCHAIN. Perceba que aqui não precisamos setar o compilador para “arm-linux-gcc”. Este Makefile é uma extensão do Makefile do kernel, e como o kernel já foi compilado para esta arquitetura, ele sabe qual toolchain (compilador) usar.

Novamente, os dois arquivos (leds.c e Makefile) devem estar no mesmo diretório, e para compilar, digite apenas “make”. O módulo gerado terá a extensão “.ko”. Você também pode conferir se o módulo foi compilado para a arquitetura correta com o comando “file”:

$ file leds.ko
leds.ko: ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not stripped

Agora, copie o binário para o sistema de arquivos que você configurou com o NFS:

$ sudo cp leds.ko /home/mini2440/rootfs/usr/bin/

E teste inserindo e removendo o driver:

$ insmod /usr/bin/leds.ko
Initializing leds driver.
 
$ rmmod leds
Exiting leds driver.

Claro que estes exemplos são bem simples, e o Makefile pode ficar bem complicado em projetos maiores. Mas os conceitos utilizados serão sempre os mesmos.

Um abraço,

Sergio Prado

Posts relacionados:

1. Linux Device Drivers — Parte 1
2. Mini2440 — Linux from scratch com Buildroot
3. Mini2440 — Montando rootfs no Linux via NFS

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em Mini2440 — Compilando aplicações e device drivers.

Na primeira parte deste artigo falei sobre os conceitos de pilha, como o compilador gera o código e usa o stack, e dei alguns exemplos de como minimizar seu uso em código desenvolvido em linguagem C.

Agora vamos estudar algumas metodologias para calcular o tamanho do stack necessário por determinada aplicação.

CALCULANDO O USO DO STACK

Qual o tamanho do stack necessário para sua aplicação? Vamos desperdiçar muita memória alocando um espaço bem grande para o stack, ou iremos alocar um espaço mais reduzido, e correr o risco de um stack overflow?

Não é fácil responder à estas perguntas. Não existe receita de bolo, e muito menos um caminho das pedras.

O tamanho do stack depende de muitas variáveis e eventos assíncronos, como chamadas aninhadas de funções, tamanho de variáveis automáticas, chamadas à funções do sistema operacional, bibliotecas e interrupções. E o problema vai ficando cada vez pior conforme aumentamos a complexidade e a quantidade de linhas de código.

Para analisar então o tamanho do stack necessário pela aplicação, também chamado de profundidade do stack, podemos usar dois tipos de técnicas: análise estática de código e análise dinâmica de código — cada uma com seus prós e contras. Vamos dar uma olhada melhor nestas técnicas.

ANÁLISE ESTÁTICA

O objetivo da análise estática é calcular a profundidade máxima alcançada pelo stack, varrendo o código-fonte (ou arquivo binário) da aplicação, passando por cada caminho dentro das chamadas de função e interrupção, contabilizando basicamente as instruções de PUSH e POP.

Usar os fontes da aplicação não é uma técnica muito recomendada por diversos fatores, dentre eles:

1. É muito mais complicado fazer a análise sintática e semântica do código-fonte do que interpretar e converter o arquivo binário em mnemônicos assembly. Quem já desenvolveu ou trabalhou com compiladores sabe como esta tarefa é complexa.
2. A análise fica incompleta se o código-fonte do sistema operacional e de bibliotecas não estiverem disponíveis.
3. É difícil prever o que o compilador fará com o código-fonte. Por exemplo, uma chamada de função, que poderia gerar algumas instruções de PUSH, pode ser otimizada pelo compilador para uma função inline, não gerando nenhuma instrução de PUSH.

O ideal então é usar o binário final para fazer esta análise. Mas isso não deixa a solução mais fácil.

A ferramenta precisa lidar com problemas como ponteiros dinâmicos de função, funções recursivas, funções de callback, etc. As interrupções também são outro problema, já que são eventos assíncronos. Como prever quais interrupções irão acontecer, e quando? Quantas interrupções ao mesmo tempo? Elas são reentrantes?

Mesmo com todos esses desafios, existem ferramentas que tentam chegar num valor aproximado de utilização do stack.

O Stacktool foi desenvolvido pelo John Regehr para fins educacionais. Esta ferramenta é um script em Perl que analisa o binário de uma aplicação desenvolvida para microcontroladores AVR. A saída do programa parece interessante (clique na figura para vê-la em tamanho maior):

Outra ferramenta interessante, o Stack Analyser da AbsInt também promete o mesmo resultado, com um ambiente gráfico e suporte à diversas arquiteturas como PowerPC, HC12/HCS12, ARM, M68k, TMS320C3x/Texas, etc.

ANÁLISE DINÂMICA

O objetivo desta técnica é analisar o código dinamicamente em tempo de execução. Você pode adotar duas soluções:

1. Preencher o stack com uma “palavra mágica”.

Esta solução consiste em preencher e monitorar os valores do stack com uma ferramenta de debugger. No boot do seu código, antes da função main, desenvolva uma função que preencha todo o stack com um conjunto de caracteres, por exemplo “STACK123”. Um dump do stack no boot ficaria mais ou menos assim:

00001000   53 54 41 43  4B 31 32 33  53 54 41 43  4B 31 32 33  STACK123STACK123
00001010   53 54 41 43  4B 31 32 33  53 54 41 43  4B 31 32 33  STACK123STACK123
00001020   53 54 41 43  4B 31 32 33  53 54 41 43  4B 31 32 33  STACK123STACK123
00001030   53 54 41 43  4B 31 32 33  53 54 41 43  4B 31 32 33  STACK123STACK123
00001040   53 54 41 43  4B 31 32 33  53 54 41 43  4B 31 32 33  STACK123STACK123
00001050   53 54 41 43  4B 31 32 33  53 54 41 43  4B 31 32 33  STACK123STACK123
00001060   53 54 41 43  4B 31 32 33  53 54 41 43  4B 31 32 33  STACK123STACK123
00001070   53 54 41 43  4B 31 32 33  53 54 41 43  4B 31 32 33  STACK123STACK123

Agora execute sua aplicação e realize testes completos, forçando inclusive a geração de eventos assíncronos como interrupções. Teste durante bastante tempo, simulando o comportamento real da aplicação. Finalizados os testes, tire outro dump do stack:

00001000   FF 02 05 09  12 01 01 03  08 DE A7 C3  C9 F3 04 E9  ................
00001010   03 08 DE A7  C3 C9 F3 04  E9 09 12 01  01 03 C9 F3  ................
00001020   F3 04 E9 09  4B 31 32 33  53 54 41 43  4B 31 32 33  ....K123STACK123
00001030   53 54 41 43  4B 31 32 33  53 54 41 43  4B 31 32 33  STACK123STACK123
00001040   53 54 41 43  4B 31 32 33  53 54 41 43  4B 31 32 33  STACK123STACK123
00001050   53 54 41 43  4B 31 32 33  53 54 41 43  4B 31 32 33  STACK123STACK123
00001060   53 54 41 43  4B 31 32 33  53 54 41 43  4B 31 32 33  STACK123STACK123
00001070   53 54 41 43  4B 31 32 33  53 54 41 43  4B 31 32 33  STACK123STACK123

Os bytes com os caracteres alterados indicam a região do stack usada pela aplicação. Veja que neste exemplo 36 bytes foram consumidos do stack.

2. Monitorar o stack pointer

Se você não tiver um debugger para tirar dumps do stack, você pode desenvolver uma função que monitore o conteúdo do Stack Pointer e armazene o maior valor. Exemplo:

1
2
3
4
5
6
7

volatile int stackDepth = 0;
 
void stackMonitor()
{
    if (stackDepth < STACK_POINTER)
        stackDepth = STACK_POINTER;
}

Coloque esta função para ser executada em um timer do sistema na menor resolução possível. E crie uma forma de visualizar este valor, através de um display, ou transmitindo por uma interface de comunicação.

QUAL A MELHOR SOLUÇÃO?

Depende! 

Na análise estática, sempre será considerado o pior dos cenários. Se uma interrupção é reentrante, a análise pode chegar a conclusão de que o stack usado será infinito! Ou seja, prevendo os piores caminhos (dentre eles os improváveis e os impossíveis), esta técnica poderá sugerir um tamanho de stack maior do que o necessário, desperdiçando memória RAM. Por outro lado, este método é mais rápido e seguro.

Na análise dinâmica, o resultado poderá estar mais próximo do real. Porém, dependendo do tamanho do programa, você pode não conseguir simular todos os caminhos possíveis, e o stack pode não ser estimado corretamente. É mais dificil também prever eventos assíncronos como interrupções. Existe então um risco de subestimar o valor necessário para o stack, correndo o risco de Stack Overflow.

Na prática, use os dois métodos. Considere um valor para o stack que esteja entre os valores encontrados na análise estática e na analise dinâmica.

Análise estática > Tamanho do Stack > Análise Dinâmica

Dependendo do seu projeto, pode ser que não exista uma ferramenta de análise estática no mercado. E desenvolver uma também pode estar fora dos seus planos. Neste caso, quando temos apenas a análise dinâmica como parâmetro, adicione à sua medida uma margem de segurança de mais ou menos 30%. Por exemplo, se você mediu o uso de 100 bytes no stack, configure-o com 130 bytes.

É claro que não existe nada científico que comprove o uso desta margem de segurança de 30%. Poderia ser 20%, 40% ou mesmo 100%! Tudo vai depender do nível de confiança (e paranóia) que você tem nos testes que executou. A decisão da quantidade de bytes a serem alocados para o stack será sempre um trade-off entre a economia de memória RAM e o risco de acontecer um stack overflow.

PROTEGENDO O STACK

Se você tiver sorte, terá em mãos uma CPU com MMU (Memory Management Unit). Neste caso, configure na MMU uma região para o stack e proteja as áreas acima e abaixo desta região alocada para o stack. Qualquer acesso fora do stack causará uma exceção que poderá ser tratada por software.

Com um debugger conectado ao equipamento, você pode identificar em qual chamada o stack overflow aconteceu. Fica muito mais fácil de identificar, analisar e resolver o problema.

MAIS UMA VEZ, USE FERRAMENTAS

Sempre ressalto aqui a importância de aproveitar as funcionalidades das ferramentas que usamos no dia-a-dia.

O ambiente de desenvolvimento da IAR possui um plugin para analisar o stack que usa uma técnica parecida com a descrita na primeira solução de análise dinâmica, preenchendo o stack com 0xCD e monitorando-o durante a execução do programa. Se chegar a um limite pré-definido pelo usuário (90% por exemplo) irá avisar.

Já o µVision Simulator da Keil usa a técnica descrita na segunda solução da análise dinâmica, monitorando o valor máximo do stack pointer e armazenando em uma variável chamada sp_max. A responsabilidade de analisar esta variável e ajustar o stack é do desenvolvedor.

Você deve ter percebido que a análise do uso do stack é um problema sem uma solução simples. O ideal é unir um conjunto de técnicas, ferramentas e bom senso.

Se você conhece mais alguma técnica ou ferramenta, deixe seus comentários!

Um abraço,

Sergio Prado.

Posts relacionados:

1. Trabalhando com o stack em linguagem C — Parte 1
2. Otimização de código em Linguagem C — Parte 1
3. Otimização de código em Linguagem C — Parte 2

Sergio Prado atua com desenvolvimento de software para sistemas embarcados há mais de 15 anos. É sócio-fundador da Embed­ded Lab­works, uma empresa focada em te aju­dar a desen­volver soft­ware de qual­i­dade para sis­temas embar­ca­dos. Se você pre­cisa de ajuda para desen­volver seu pro­duto, ou quer saber mais sobre o que a Embed­ded Lab­works pode fazer por você, acesse http://e-labworks.com/servicos.

Este post foi originalmente publicado em Trabalhando com o stack em linguagem C — Parte 2.