DEV Community: Guilherme Giácomo Simões

Introdução aos drivers USB

Guilherme Giácomo Simões — Tue, 03 Oct 2023 02:36:28 +0000

Introdução

Nesse quarto texto da série "introdução ao desenvolvimento de driver para linux" vamos introduzir um pouco do conceito das conexões USB, como se comunicam e como iniciar um "hello world" para um driver de usb.
Se você caiu de paraquedas nesse texto, aqui esta o link com todos os codigos e textos dessa serie

Protocolo USB

Nessa introdução ao protocoloco USB, vou falar brevemente sobre o assunto.

Pinagem
Se você pegar um cabo USB e abri-lo, vai perceber que ele tem 4 cabos dentro dele envolto na "capa". Eles tem cada um suas funções. O cabo vermelho é um VCC e tem tensão de 5v, o cabo preto é um GND, o cabo verde (chamado de DATA+ ou simplesmente D+) e o cabo branco (chamado de DATA- ou simplesmente D-) são usados para envio e recebimento de dados. Os dados são transferidos através dos conectores D+ e D- enquanto os conectores VCC e GND fornecem energia ao dispositivo USB.

Comunicação
Toda transferencia de dados, independente da direção é iniciada pelo host. O host controla o dispositivo USB. O host também controla o tempo de comunicação com o dispositivo mantendo intervalos de tempo chamados frames.
Para inicio do frames, o host emite uma sequência de início de frame (SOF - Start Of Frame ) nas linhas de dados USB no início de cada frame.
O host USB conduz transações de comunicação com os dispositivos durante o frame.

O mecanismo de transferência de dados envolve o host gravar e ler de um determinado espaço de memória. Esses locais de memória são chamados de endpoints. O tamanho de um endpoint pode variar muito dependendo do dispositivos.
O número de endpoints começa em 0 e podem chegar até 32. Os endpoints do dispositivo são encontrados em pares numerados, então, cada índice do endpoint tem dois endereços, chamados de IN e OUT. Então o endpoint 1 tem o endereço 1_IN e 1_OUT, o endpoint 2 tem o 2_IN e o 2_OUT e assim por diante.

Os endpoints OUT transportam dados que saem do host para o device, enquanto os endpoints IN contêm dados enviados do device para o host.
O software do dispositivo fica responsável por ir até o endpoint OUT e verificar se tem algo para ler. Caso durante o monitoramento o software do dispositivo identifique uma mensagem no OUT, ele copia essa mensagem e executa alguma ação. Se o software do dispositivo deseja enviar uma mensagem ele coloca essa mensagem no endpoint IN. A mensagem permanecerá no endpoint IN até que o host decida ler ela.

As informações sobre todos os parâmetros do endpoint e requisitos de comunicação são definidas pelo device e fornecidas ao host quando o dispositivo é conectado ao host e enumerado com sucesso.
Todo dispositivo USB na verdade reserva o endpoint 0 (0_in e 0_out) como um endpoint de controle. O endpoint 0_in contém uma descrição do dispositivo USB, o código do fabricante, o código do dispositivo, entre várias outras informações que são lidas pelo host durante a enumeração. O 0_out fornece ao host a capacidade de enviar comandos ao dispositivo como Redefinir, Suspender ou Restaurar um dispositivo suspenso.

Non Return To Zero
No seguimento de comunicação, um código de linha Sem Retorno a Zero (Non Return To Zero ou simplesmente NRZ) é um código binário no qual, o nível lógico alto é geralmente representado por uma tensão positiva, e o nível lógico baixo é representado por uma tensão negativa. Por isso então no USB temos o D+ e o D- para envio e recebimento de dados. D+ é para representar nível lógico alto e D- é para representar nível lógico baixo.
O NRZ, tem esse nome justamente porque ele nunca é zero, não tem um sinal de repouso nem nada do tipo. A tensão ou é positiva ou negativa. Como na imagem abaixo:

Non Return To Zero Inverted
Bom, o USB não se comunica através do NRZ, mas sim através de uma variante do NRZ conhecida como NRZI (Non Return to Zero Inverted). Ela é como o NRZ, nunca é zero, porém nesse tipo de encodamento, o nível lógico 1 significa que nenhuma mudança no bit ocorreu enquanto que o nível lógico 0 significa que o bit mudou. Parece um pouco confuso, mas não é tanto assim. Vamos pensar no seguinte binário: 0011. Veja que os dois primeiros dígitos são 0s. Logo ele vai emitir 11, porque não há mudança no nível lógico. Porém entre os bits 01, ele emitirá um bit 0 (ou uma tensão negativa através do D-) para indicar que houve uma mudança no nível lógico. E a sequência 0011, encodada para NRZI fica representada por 1101.
Agora usando um exemplo mais complexo, dado a sequência binária a seguir: 111010000100. Ela poderá ser representada pelo NRZI da seguinte forma: 111000111001. Então quando tem uma alteração do nível lógico da informação, o nível lógico do D+ e D- mudam conforme mencionado anteriormente.

Bit stiffing
Quando longas séries de 0s são transmitidas usando NRZI, causa uma transição nos níveis. Mas quando longas séries de 1s são transmitidas, nenhuma transição ocorre de acordo com o esquema de codificação NRZI. O bit sempre permanece o mesmo. Nenhuma transição de níveis por muito tempo pode confundir o receptor e dessincroniza-lo.
O Bit stiffing é um processo no qual um 0 é inserido nos dados brutos a cada seis 1s consecutivos.
A inserção de zero provoca transição de nível. O receptor deve reconhecer os bits preenchidos e descartá-los após decodificar os dados NRZI.
Caso nenhuma transição ocorra no sinal NRZI após seis 1s consecutivos, o receptor decide que o bit stiffing não foi feito e descarta os dados recebidos.

Mãos no código

Vamos começar uma breve introdução aos drivers USBs, e nos próximos textos faremos algo mais complexo.
Para começar vou criar um hello_world_usb.c bem simples com os imports e funções básicas padrões de todo modulo de driver

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>

MODULE_AUTHOR("SEU NOME <seu_email@email.com>");
MODULE_DESCRIPTION("Introducao a criacao de driver pra linux");
MODULE_LICENSE("GPL");
MODULE_VERSION("1.0");

static int __init hello_world_init(void)
{
    return 0;
}

static void __exit hello_world_exit(void)
{
    pr_info("Adeus mundo cruel\n");
}

module_init(hello_world_init);
module_exit(hello_world_exit);

Bom, para começar falando sobre a implementação do driver, preciso dizer que praticamente tudo de baixo nivel relacionado a USB é abstraído pelo kernel. Então ele facilita muito nossa comunicação de driver USB com o dispositivo.
Inclusive existe uma interface chamada usb_driver para que possamos implementar o nosso driver USB com facilidade. Essa lib fica dentro do path include/linux/usb.h da árvore de código do linux. Então já podemos importar ela no inicio do nosso módulo:

///...
#include <linux/usb.h>

Vamos usar a struct usb_driver para começar nosso driver. Mas antes vamos comentar um pouco sobre ela.
Ela tem vários parâmetros, vou comentar todos. Aqui esta ela:

static struct usb_driver skel_driver = {
    .name = "skeleton",
    .probe = skel_probe,
    .disconnect = skel_disconnect,
    .suspend = skel_suspend,
    .resume = skel_resume,
    .pre_reset = skel_pre_reset,
    .post_reset = skel_post_reset,
    .id_table = skel_table,
    .supports_autosuspend = 1
};

.name: Esse parâmetro deixa bem explicito para que ele serve. Ele é uma descrição do driver e normalmente é o mesmo nome do modulo.
.probe: Chamado na inicialização do driver para verificar se o driver está disposto ou precisa gerenciar uma interface de algum dispositivo em particular. Por ex, no nosso caso, usaremos esse cara para gerenciar um usb e controlar um display de 7segmentos, então ele vai precisar gerenciar um dispositivo em particular. Se precisasse gerenciar um mouse, não precisaria informar uma interface específica.
.disconnect: Função chamada quando o dispositivo usb é desconectado ou o modulo é removido.
.suspend: Chamado quando o dispositivo será suspenso pelo sistema no contexto de suspensão do sistema ou de suspensão do tempo de execução.
.resume: Chamado quando o dispositivo volta da suspensao do sistema operacional.
.pre_reset: Chamado por usb_reset_device() quando o dispositivo esta prestes a ser reiniciado
.post_reset: Chamado por usb_reset_device() após o dispositivo ser reiniciado.
.id_table: Os drivers USB usam uma tabela de ID para suportar hotplugging (conectar e usar). Exporte esse id_table com MODULE_DEVICE_TABLE(). Se você não exportar sua função probe jamais sera chamada.
.supports_autosuspend: Se for 0 o nucleo USB do kernel jamais permitira a suspensão automatica para interfaces vinculadas a esse driver.

No usb_driver somente é obrigatório fornecer o campo name, probe, disconnect e id_table. O resto é opcional.
Os métodos probe() e disconnect() são chamados em um contexto onde podem suspender o device. Mas não abuse desse privilégio. A maior parte do trabalho de conexão a um device deve ser realizada quando o device for inicializado e desfeito no último fechamento. O código de desconexão precisa resolver problemas de simultaneidade com relação aos métodos open() e close(), bem como forcar a conclusão de todas as solicitações de E/S pendentes.

Como somente é obrigatório o campo name, probe, disconnect e id_table, não vamos inventar moda aqui em um texto introdutório sobre o assunto, vamos usar somente o obrigatório. Iremos declarar a struct no nosso hello_world_usb.c no inicio do arquivo:

//...
static struct usb_driver hello_world_usb = {
    .name = "hello world usb",
    .probe = hello_world_usb_probe,
    .disconnect = hello_world_usb_disconnect,
    .id_table = hello_world_usb_table,
};
//....

Para permitir que o sistema linux-hotplug carregue o driver automaticamente quando o dispositivo for conectado, você precisa criar um MODULE_DEVICE_TABLE. O código a seguir informa aos scripts hotplug que este modulo oferece suporte a um único dispositivo com um ID de fornecedor e ID de produto específicos:

static struct usb_device_id hello_world_usb_table[] = {
    { USB_DEVICE(USB_VENDOR_ID, USB_PRODUCT_ID) },
    { }
};
MODULE_DEVICE_TABLE(usb, hello_world_usb_table);

Lembra que dissemos acima sobre o endpoint 0 do USB? Então, essas informações de código de fornecedor (USB_VENDOR_ID) e código do produto (USB_PRODUCT_ID) estarão armazenadas la. Não vamos aprender a ler elas nesse texto por ser um conteúdo introdutório, mas nos próximos textos com certeza iremos aprender sobre isso.
Bom, ele precisa ter o VENDOR_ID e o PRODUCT_ID no endppoint 0, para ler, e achar dentro da tabela de dispositivos o VENDOR_ID e PRODUCT_ID correspondente ao que ele leu no endpoint 0, para então chamar o modulo de driver correto.

Nesse caso, vou fazer o seguinte: Tenho um Arduino aqui em casa e vou conecta-lo ao meu computador, e rodar o comando lsusb. Dessa forma ele vai listar os dispositivos conectados ao meu computador e vai me dar algumas breves informações sobre eles. Esse é o resultado do meu lsusb:

Repare na linha onde tem a descrição Arduino SA Uno R3 que temos várias informações com relação ao dispositivo. Na sexta coluna onde tem a informação 2341:0043 esses são o VENDOR ID e o PRODUCT ID do meu Arduino. Então 2341 é o vendor_id e o 0043 é o product_id. Isso é um hexadecimal. Vou declarar meu VENDOR_ID e PRODUCT_ID no código:

//...
#define USB_VENDOR_ID 0x2341
#define USB_PRODUCT_ID 0x0043
//...

Então quando eu conectar o meu Arduino, a minha função probe deve ser executada. Vou declarar minha função probe e disconnect:

static int hello_world_usb_probe(struct usb_interface *intf, 
        const struct usb_device_id *id) 
{
    pr_info("Dispositivo %s foi conectado", USB_PRODUCT_ID);
    return 0;
}

static void hello_world_usb_disconnect(struct usb_interface *intf)
{
    pr_info("Dispositivo %s desconectado", USB_PRODUCT_ID);
}

E também precisamos montar nossa função __init e nela precisamos chamar a função usb_register para registrar nosso novo driver USB.

static int __init hello_world_init(void)
{
    int result = usb_register(&hello_world_usb);
    if(result) {
        pr_err("usb_register falhou para o driver %s. Erro numero %s"
                , hello_world_usb.name, result);
        return -1;
    }

    return 0;
}

E na minha função __exit preciso remover o meu driver:

static void __exit hello_world_exit(void)
{
    usb_deregister(&hello_world_usb);
    pr_info("Adeus mundo cruel\n");
}

Vamos declarar nosso Makefile

obj-m += hello_world_usb.o

all: run

run:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

Agora podemos compilar e instalar nosso modulo

$ make
$ sudo insmod hello_world_usb.ko

Apos a insercao do modulo de driver, quando eu insiro meu dispositivo USB o meu dmesg tem a seguinte saida:

Ele reconheceu a conexão e printou a mensagem que esperávamos. Agora quando eu remover o dispositivo USB:

Obtemos a mensagem esperada que colocamos na nossa função de disconnect.

Revisão

Aprendemos como funciona a pinagem da conexão USB.
Aprendemos como funciona a comunicação USB.
Aprendemos a criar um driver introdutório para um dispositivo USB existente.

Referencias

Driver de display de 7seg

Guilherme Giácomo Simões — Tue, 19 Sep 2023 16:41:54 +0000

Introdução
Começando agora o quarto episódio da série "introdução ao desenvolvimento de drivers para o kernel linux".
Se você caiu de paraquedas nesse texto, o link com todos os episódios dessa série, está aqui
Hoje finalmente escreveremos nosso primeiro driver para linux. Mais especificamente para o raspberry pi (no meu caso 3). A versão do kernel do meu raspberry é a 6.1-rc7.
Eu vou começar pelo raspberry por alguns motivos. Primeiro que vamos mapear os pinos do GPIO do raspberry para ser usado por nosso driver e para isso precisamos introduzir o conceito de device-tree que é importante para os desenvolvedores de driver, e segundo porque é uma comunicação simples de fazer e me parece um bom caminho para começar.
Nos próximos textos faremos drivers para USB utilizando classes existentes.

Queria salientar que esse é um texto maior e mais denso do que os anteriores, então é preciso que você leia, releia e pratique para conseguir entender os conceitos.

Circuito
O circuito é muito simples. Somente um display de 7 segmentos em uma protoboard com resistires de +/- 220Ω. O display de 7segmentos espera uma corrente entre 6mA e 20mA. A tensão emitida pela GPIO do raspberry é 3,3v. Então 3,3v/220Ω = 15mA. Estamos dentro do range de 6mA a 20mA. O esquema do circuito fica como abaixo:

Da pra perceber que não sou a melhor pessoa do mundo para fazer esquemas de circuito, mas acho que da para ter uma noção. Para ajudar, vou deixar também uma tabela com a descrição das conexões:

Segmento	GPIO
A	2
B	3
C	4
D	5
E	6
F	7
G	9

Aqui a foto de como ficou meu circuito montado na protoboard:

O que sao device-tree
No kernel linux temos uma estrutura de dados chamado device-tree que fica responsável por informar a descrição dos periféricos de IO para o kernel.

Em varias situações do nosso dia-a-dia temos que usar documentos ou ferramentas que nos ajudam a descrever certas funcionalidades de algo. Manuais de usuario nos auxiliam a entender as funcionalidades de um produto. Device-tree em sistemas Linux Embarcados compartilham dessa mesma particularidade, e servem para descrever com precisão como sera configurado e utilizado o hardware.

O que faremos aqui é o chamado overlay do device-tree. Um overlay do device-tree consiste em um arquivo de dados que altera a estrutura atual do device-tree do hardware em questão. Assim como os módulos ele pode ser acoplado dinamicamente ao kernel.

Explicando a estrutura do device-tree
Segue abaixo nosso device-tree para acoplar ao kernel chamado overlay.dts:

/dts-v1/;
/plugin/;
/{   
  compatible = "brcm,bcm2835";
  fragment@0 {         
    target-path = "/";         
    __overlay__{             
      my_device{
        compatible = "ggs-prd,7segment";
        status = "okay";                 
        a-gpio = <&gpio 2 0>;      
        b-gpio = <&gpio 3 0>;
        c-gpio = <&gpio 4 0>;
        d-gpio = <&gpio 5 0>;
        e-gpio = <&gpio 6 0>;
        f-gpio = <&gpio 7 0>;
        g-gpio = <&gpio 9 0>;
        dp-gpio = <&gpio 10 0>;
    };         
    };      
  }; 
};

A primeira linha /dts-v1/; é usada para informar a versão do dts.

A segunda linha /plugin/ é usada para informar que esse overlay de device-tree é um plugin

A linha compatible = "brcm,bcm2835"; descreve para qual plataforma esse device-tree foi feito para funcionar. Aqui existe uma regra super importante, ele começa sempre na mais compativel e vai para a menos compativel. Então nesse caso a plataforma mais compativel para a qual esse device-tree foi feito é a brcm, e a segunda é a bcm2835.
É importante sempre mencionar todas as plataformas para a qual você quer que o overlay funcione porque vão acontecer erros nas plataformas que não forem mencionadas.
Nesse caso, brcm e bcm2835 fazem referencia a fabricante Broadcom, responsavel por fabricar os chips do raspberry pi.

A linha com fragment@0 é o inicio dos fragmentos do device-tree. Aqui descreveremos qual dispositivo sera sobreposto.

A linha que contem o segundo "compatible" compatible = "ggs-prd,7segment"; é super importante, ele é o identificador do nosso driver em questão. Ele indica o nome do driver e qual a empresa ou dev responsavel pela manutenção dele. Esse segundo compatible é indispensável para nossos próximos passos para que o modulo reconheça qual overlay contém as alterações necessárias para que o driver funcione corretamente.

Nas linhas a-gpio = <&gpio 2 0>;, b-gpio = <&gpio 3 0>; e assim por diante, apesar de nao parecer é um conceito muito simples. Estamos mapeando as portas gpio para serem uma porta de saida de dados. Por isso o 0 no fim.

Criando um novo driver
Para começar, vamos criar dois arquivos 7segment.c e um 7segment.h. E criar uma classe e um atributo de classe como ensinamos nos textos anteriores:

7segment.h

#ifndef __7SEGMENT_H__
#define __7SEGMENT_H__

static struct class *device_class = NULL;
static struct class_attribute *attr = NULL;

static ssize_t show_value(struct class *class, 
        struct class_attribute *attr, char* buf);

static ssize_t store_value(struct class *class, 
        struct class_attribute *attr, const char* buf, size_t count);

volatile int value_display;

#endif

7segment.c

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/device.h>

#include "7segment.h" 

MODULE_AUTHOR("SEU NOME <seu_email@email.com>");
MODULE_DESCRIPTION("7segment");
MODULE_LICENSE("GPL");
MODULE_VERSION("1.0");

static ssize_t show_value(struct class *class, 
        struct class_attribute *attr, char* buf)
{
    pr_info("valor do display %s - LEITURA", value_display);
    return sprintf(buf, "%d", value_display);
}

static ssize_t store_value(struct class *class, 
        struct class_attribute *attr, const char* buf, size_t count)
{
    sscanf(buf, "%d", &value_display);
    pr_info("valor do display %d - ESCRITA", value_display);
    return count;
}

static int __init class_init(void)
{
    device_class = (struct class *) kzalloc(sizeof(struct class), GFP_ATOMIC);
    if(!device_class) 
      pr_err("ERRO NA ALOCACAO DA CLASSE");

    device_class->name = "7segment";
    class_register(device_class);

    attr = (struct class_attribute *) kzalloc(sizeof(struct class_attribute), GFP_ATOMIC);
    attr->show = show_value;
    attr->store = store_value;
    attr->attr.name = "value";
    attr->attr.mode = 0777;
    class_create_file(device_class, attr);

    pr_info("class registrada");

    return 0;
}

static void __exit class_exit(void)
{
    class_unregister(device_class);
    class_destroy(device_class);
    pr_info("Modulo removido");

}

module_init(class_init);
module_exit(class_exit);

Pronto, nada de diferente do que fizemos nos textos anteriores. É exatamente o mesmo codigo do texto anterior.

Agora precisamos realizar a integracao do nosso novo device-tree com o nosso driver para conseguirmos alterar o estado das GPIOs do raspberry.
Para isso, primeiro vou criar uma struct do tipo of_device_id que está declarado em /include/linux/of_device.h e passar como parametro para ela o compatible do driver explicado anteriormente. Ele vai vincular o nosso driver atual com esse "identificador" e ela conseguirá identificar todos os devices na device-tree que utilizam esse driver.
Então vamos declarar e atribuir o parametro na struct dentro do nosso 7segment.h

//...
static struct of_device_id driver_ids[] = {
    {.compatible = "ggs-prd,7segment"},
    {}
};

Agora, precisamos criar uma struct do tipo platform_driver que fica declarada em /include/linux/platform_device.h que é uma interface para criação de um driver genérico, ela vai receber como parâmetro nossa struct declarada anteriormente (of_device_id driver_ids[]) e as funções de inicialização e remoção do driver que não serão as mesmas das funções de inicialização e remoção do módulo.

Então vamos declarar a struct platform_driver e tambem declarar as assinaturas das funções de inicialização e remoção do driver no nosso 7segment.h:

static int gpio_init_probe(struct platform_device *pdev);
static int gpio_exit_remove(struct platform_device *pdev);

static struct platform_driver display_driver = {
    .probe = gpio_init_probe,
    .remove = gpio_exit_remove,
    .driver = { 
        .name = "display_driver",
        .owner = THIS_MODULE,
        .of_match_table = driver_ids,
    }
};

E agora no nosso 7segment.c vamos dar inicio a implementação das funções probe e remove do driver e tambem importar nossas bibliotecas of_device.h e platform_device.h:

//...
#include <linux/of_device.h>
#include <linux/platform_device.h>

//
//...
//

static int gpio_init_probe(struct platform_device *pdev) 
{
    pr_info("Driver inicializado");
    return 0;
}

static int gpio_exit_remove(struct platform_device *pdev) 
{
    pr_info("Driver removido");
    return 0;
}

Feito isso, vamos criar no nosso 7segment.h as variaveis referentes a cada gpio em uso no display no nosso raspberry. Essas variaveis serão do tipo gpio_desc, struct declarada em include/linux/gpio/consumer.h elas serão mapeadas para cada porta do raspberry que configuramos como saida no nosso overlay de device-tree e poderemos manipular o valor logico delas (1 ou 0):

//...
struct gpio_desc *a, *b, *c, *d,
    *e, *f, *g;

Não podemos nos esquecer de importar o consumer.h
no nosso 7segment.c:

//...
#include <linux/gpio/consumer.h>
//...

Agora, vamos mapear nossas variáveis para as portas gpio do rasp e setá-las com valor lógico 0 por padrão usando a função devm_gpiod_get da lib gpio/consumer.h dentro da nossa função gpio_init_probe:

static int gpio_init_probe(struct platform_device *pdev) 
{
    pr_info("Driver inicializado");
    a = devm_gpiod_get(&pdev->dev, "a", GPIOD_OUT_LOW);
    b = devm_gpiod_get(&pdev->dev, "b", GPIOD_OUT_LOW);
    c = devm_gpiod_get(&pdev->dev, "c", GPIOD_OUT_LOW);
    d = devm_gpiod_get(&pdev->dev, "d", GPIOD_OUT_LOW);
    e = devm_gpiod_get(&pdev->dev, "e", GPIOD_OUT_LOW);
    f = devm_gpiod_get(&pdev->dev, "f", GPIOD_OUT_LOW);
    g = devm_gpiod_get(&pdev->dev, "g", GPIOD_OUT_LOW);

    return 0;
}

Agora, com as funções de inicialização e remoção do driver prontos, e preciso registrá-lo no módulo, pra isso os seguintes trechos foram, respectivamente, acrescentados nas funções de inicialização e remoção do módulo.

Na função de inicialização deve ser registrado o driver no fim da função, antes do return 0;

static int __init class_init(void)
{
    //...

    if(platform_driver_register(&display_driver)) {
        pr_err("ERRO! nao foi possivel carregar o driver");
        return -1;
    }

    return 0;
}

static void segments_display_exit(void)
{
    //...    
   platform_driver_unregister(&display_driver);

}

Pronto registramos nosso driver. Agora, precisamos criar na nossa função store_value que a função que é executada quando o arquivo de atributo de classe e fechado algumas condições para mudar as portas GPIOs do raspberry de acordo com o número que esta dentro da variável value_display antes do nosso return count;.

    if(value_display == 0) {
        gpiod_set_value(a, 1);                 
        gpiod_set_value(b, 1);                
        gpiod_set_value(c, 1);                 
        gpiod_set_value(d, 1);      
        gpiod_set_value(e, 1);                 
        gpiod_set_value(f, 1);                 
        gpiod_set_value(g, 0);
    }
    else if(value_display == 1) {
        gpiod_set_value(a, 0);                 
        gpiod_set_value(b, 1);                
        gpiod_set_value(c, 1);                 
        gpiod_set_value(d, 0);      
        gpiod_set_value(e, 0);                 
        gpiod_set_value(f, 0);                 
        gpiod_set_value(g, 0);
    }
    else if(value_display == 2) {
        gpiod_set_value(a, 1);                 
        gpiod_set_value(b, 1);                
        gpiod_set_value(c, 0);                 
        gpiod_set_value(d, 1);      
        gpiod_set_value(e, 1);                 
        gpiod_set_value(f, 0);                 
        gpiod_set_value(g, 1);
    }
    else if(value_display == 3) {
        gpiod_set_value(a, 1);                 
        gpiod_set_value(b, 1);                
        gpiod_set_value(c, 1);                 
        gpiod_set_value(d, 1);      
        gpiod_set_value(e, 0);                 
        gpiod_set_value(f, 0);                 
        gpiod_set_value(g, 1);
    }
    else if(value_display == 4) {
        gpiod_set_value(a, 0);                 
        gpiod_set_value(b, 1);                
        gpiod_set_value(c, 1);                 
        gpiod_set_value(d, 0);      
        gpiod_set_value(e, 0);                 
        gpiod_set_value(f, 1);                 
        gpiod_set_value(g, 1);
    }
    else if(value_display == 5) {
        gpiod_set_value(a, 1);                 
        gpiod_set_value(b, 0);                
        gpiod_set_value(c, 1);                 
        gpiod_set_value(d, 1);      
        gpiod_set_value(e, 0);                 
        gpiod_set_value(f, 1);                 
        gpiod_set_value(g, 1);
    }
    else if(value_display == 6) {
        gpiod_set_value(a, 0);                 
        gpiod_set_value(b, 0);                
        gpiod_set_value(c, 1);                 
        gpiod_set_value(d, 1);      
        gpiod_set_value(e, 1);                 
        gpiod_set_value(f, 1);                 
        gpiod_set_value(g, 1);
    }
    else if(value_display == 7) {
        gpiod_set_value(a, 1);                 
        gpiod_set_value(b, 1);                
        gpiod_set_value(c, 1);                 
        gpiod_set_value(d, 0);      
        gpiod_set_value(e, 0);                 
        gpiod_set_value(f, 0);                 
        gpiod_set_value(g, 0);
    }

    else if(value_display == 8) {
        gpiod_set_value(a, 1);                 
        gpiod_set_value(b, 1);                
        gpiod_set_value(c, 1);                 
        gpiod_set_value(d, 1);      
        gpiod_set_value(e, 1);                 
        gpiod_set_value(f, 1);                 
        gpiod_set_value(g, 1);
    }
    else if(value_display == 9) {
        gpiod_set_value(a, 1);                 
        gpiod_set_value(b, 1);                
        gpiod_set_value(c, 1);                 
        gpiod_set_value(d, 0);      
        gpiod_set_value(e, 0);                 
        gpiod_set_value(f, 1);                 
        gpiod_set_value(g, 1);
    }
    else {
        gpiod_set_value(a, 1);                 
        gpiod_set_value(b, 0);                
        gpiod_set_value(c, 0);                 
        gpiod_set_value(d, 1);      
        gpiod_set_value(e, 1);                 
        gpiod_set_value(f, 1);                 
        gpiod_set_value(g, 1);
    }

Repare que não nos atentamos a legibilidade do código aqui, você tem a liberdade de depois abstrair isso em funções e melhorar a qualidade desse trecho de código

Caso o valor não esteja no range de 0..9 vamos exibir a letra E de erro.

Agora vamos criar nosso Makefile como todos os outros que ja criamos

obj-m += 7segment.o

all: run

run:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

Porém, faremos algumas alterações, porque precisamos compilar o nosso device-tree e fazer o overlay dele no kernel.
Para compilar precisamos do seguinte comando:

dtc -@ -I dts -O dtb -o overlay.dtbo overlay.dts

E para fazer o overlay dele no kernel precisamos do seguinte comando:

sudo dtoverlay overlay.dtbo

Então vamos criar uma rotina no Makefile chamada dt

#...
dt: overlay.dts
    dtc -@ -I dts -O dtb -o overlay.dtbo overlay.dts
    sudo dtoverlay overlay.dtbo

E na rotina all: vamos chamar além do nosso run tambem o nosso dt.

all: run dt

O nosso Makefile fica assim

obj-m += 7segment.o

all: run dt

run:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

dt: overlay.dts
    dtc -@ -I dts -O dtb -o overlay.dtbo overlay.dts
    sudo dtoverlay overlay.dtbo

Feito, agora vamos rodar o make e inserir nosso modulo no kernel e ver o resultado.

make
sudo insmod 7segment.ko

Nosso resultado:

[99897.183680] 7segment: loading out-of-tree module taints kernel.
[99897.185331] class registrada

Agora quando rodarmos o comando sudo echo "8" > /sys/class/7segment/value a letra 8 será exibida no nosso display.

Revisão

Aprendemos o que é um device-tree.
Aprendemos como substituir o atual device-tree do kernel por um que nós mesmo criamos.
Aprendemos como registrar um novo driver de dispositivo.

Referencias

Doc oficial Linux
Livro linux kernel programming comprehensive guide de Kaiwan N Billimoria
Artigo driver-linux-para-display-de-7-segmentos de Brenda Jacomelli

Atributos de classes

Guilherme Giácomo Simões — Fri, 15 Sep 2023 13:13:53 +0000

Introdução
Nesse terceiro texto da saga "introdução ao desenvolvimento de drivers para kernel linux" vou falar sobre atributos de classes. Os atributos de classes são arquivos criados no /sys/class/classe_do_driver que serão usados como forma de interagir com o SO.

O que são atributos de classes
Os atributos de classe, como mencionado na introdução são uma forma de comunicação do SO com o driver. Quando estamos desenvolvendo um driver para algum dispositivo podemos precisar de algumas informações que o kernel pode nos fornecer.
A comunicação entre driver x Kernel é feita a partir de um arquivo que fica no /sys/class/classe_do_driver, e o nome do arquivo é dado por nós mesmo na hora de declarar o atributo. Então, como no texto anterior criamos uma classe chamada 7segment o diretorio da classe fica declarado em /sys/class/7segment. Como expliquei no texto anterior, essa classe 7segment vamos usar futuramente para exibir um valor em um circuito simples com um display de 7 segmentos. Então, se precisarmos exibir algum número no display, podemos pegar o numero que esta declarado no atributo de classe da classe 7segment. Então, criaremos um atributo de classe para a classe 7segment e leremos esse atributo com o número para exibir no display.
Gostaria de salientar, que nesse texto somente faleremos e implementaremos os códigos relacionados ao atributo de classe, e a implementação da comunicação com o display ficará para os próximos textos.
Ficará mais claro com a implementação prática do código.

Caso tenha caído de paraquedas nesse texto, aqui esta o link com os códigos e links dessa serie.

Mãos no código
Para começar vamos criar os arquivos básicos, um attribute.c com a classe ja criada, assim como ensinamos no texto anterior, um attribute.h e um Makefile:

attribute.c:

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/device.h>

#include "attribute.h" 

MODULE_AUTHOR("SEU NOME <seu_email@email.com>");
MODULE_DESCRIPTION("Classes de dispositivos");
MODULE_LICENSE("GPL");
MODULE_VERSION("1.0");

static int __init class_init(void)
{
    device_class = (struct class *) kzalloc(sizeof(struct class), GFP_ATOMIC);
    if(!device_class) 
      pr_err("ERRO NA ALOCACAO DA CLASSE");

    device_class->name = "7segment";
    class_register(device_class);

    pr_info("class registrada");

    return 0;
}

static void __exit class_exit(void)
{
    class_unregister(device_class);
    class_destroy(device_class);
    pr_info("Modulo removido");

}

module_init(class_init);
module_exit(class_exit);

attribute.h

#ifndef __MY_CLASS_H__
#define __MY_CLASS_H__

static struct class *device_class = NULL;

#endif

Makefile

obj-m += attribute.o

all: run

run:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

Como declarar um atributo de classe
Agora vamos começar a criar nosso atributo de classe. Para isso, no attribute.h vamos criar uma variável do tipo class_attribute, que que fica declarado dentro do header device.h no path include/linux/device.h da árvore de código do kernel.

atrribute.h

//...
static struct class_attribute *attr = NULL;
//...

E após declara-lo, vamos alocar memória para ele na nossa função de inicialização do módulo após ter registrado nossa classe:

//...
static int __init class_init(void)
{
    //...
    //declarao e registro da classe

    attr = (struct class_attribute *) kzalloc(sizeof(struct class_attribute), GFP_ATOMIC);
    attr->show = show_value;
    attr->store = store_value;
    attr->attr.name = "value";
    attr->attr.mode = 0777;
    class_create_file(device_class, attr);

    //...

Agora vamos a alguns esclarecimentos. O atributo nome é o mais óbvio de todos, ele espera receber um nome de atributo, aqui chamamos apenas de "value". Como mencionei, quando criamos o atributo ele cria um arquivo no diretorio /sys/class/classe_do_device, como chamamos nosso atributo de "value" e nossa classe de 7segment então ele ficará no path /sys/class/7segment/value. Esse arquivo conterá o valor do atributo.
O atributo mode, recebe as permissoes do arquivo, aqui demos a permissao mais aberta de todas (777 - leitura e escrita pra qualquer ususario) porque isso é apenas um tutorial extremamente introdutório, é importante que você entenda sobre as permissões e coloque uma adequada quando fizer isso em produção.
Temos outros dois atributos: show e value. Eles esperam duas funções uma que será chamada quando o arquivo for aberto (show) e uma que será chamada quando o arquivo for fechado (store). Então precisamos declarar a assinatura dessas funções no nosso header e também declarar uma variável que vai receber o valor que esta no atributo.

attribute.h

//...
static ssize_t show_value(const struct class *class, 
        const struct class_attribute *attr, char* buf);

static ssize_t store_value(const struct class *class, 
        const struct class_attribute *attr, const char* buf, size_t count);

volatile int value_display;

E agora no attribute.c vamos implementa-las
attribute.c

static ssize_t show_value(const struct class *class, 
        const struct class_attribute *attr, char* buf) 
{
    pr_info("valor do display %d - LEITURA", value_display);
    return sprintf(buf, "%d", value_display);
}

static ssize_t store_value(const struct class *class, 
        const struct class_attribute *attr, const char* buf, size_t count) 
{
    sscanf(buf, "%d", &value_display);
    pr_info("valor do display %d - ESCRITA", value_display);
        return count;
}

Perfeito, agora quando abrirmos o arquivo sys/class/7segment/value a função show_value vai executar e poderemos ler o valor que esta nele, e quando editarmos esse arquivo a função store_value() vai ser executada e salvar o nosso novo valor em sys/class/7segment/value.

Compilando e inserindo o modulo no kernel
Vamos compilar e inserir o módulo no kernel.

make

sudo insmod attribute.ko

E vamos conferir os logs sudo dmesg
E obtemos a seguinte saída

[  958.089903] attribute: loading out-of-tree module taints kernel.

Incluímos nosso código no kernel.

Agora, vamos dar um ls em sys/class/7segment.
E veja só que coisa mais bonita:

Bom, agora vamos manipular o valor dentro do arquivo value e verificar os logs do Kernel.
Vou abrir o arquivo e colocar la dentro o valor 8 e vou consultar os logs sudo dmesg

Pronto, conseguimos gravar um novo atributo e ler ele do arquivo de atributo de classe.

Revisão

Vimos o que são atributos de classe
Aprendemos a criar um atributo de classe
Aprendemos a ler e gravar um novo atributo de classe

Classe de dispositivos

Guilherme Giácomo Simões — Wed, 13 Sep 2023 20:21:56 +0000

Nesse segundo texto sobre a introdução ao desenvolvimento de drivers de dispositivos pro kernel linux, vamos falar sobre classes de dispositivos.

Caso tenha caído de paraquedas nesse texto, aqui esta o link do github com o compilado dos códigos e links dessa serie.

O que são classes de dispositivos?
Classes de dispositivos é uma forma de classificar a familia do dispositivo do qual voce esta escrevendo o driver e tambem uma forma de facilitar uma comunicação do kernel com o driver em questão.

Os dispositivos são enumerados nas classes e cada vez que um novo driver é atribuído a classe ele incrementa um atributo de classe chamado devnum, e atribui esse devnum ao dispositivo. O devnum nunca é decrementado, por tanto se você remover o dispositivo e inserir novamente ele receberá outro devnum.

Após inserirmos o módulo de driver no kernel, ele criará um diretório com o nome da sua classe no caminho /sys/class .
Se quisermos ver as classes de dispositivos registradas no nosso kernel, podemos listar os diretorios em /sys/class

Podemos observar que temos classes de bluetooth, graphics, cpuid, etc.
Essas são as classes registradas no meu kernel, e podemos criar uma nova classe de dispositivo, ou usar alguma já existente como a classe de usb ou bluetooth.
Nesse texto, vamos criar nossa própria classe. Toda classe deve ficar declarada em um arquivo header para que seja usada pelos drivers, extensões e interfaces. Como os dispositivos estão vinculados aos drivers, eles devem ser adicionados a classe a qual pertencem.

Para criar uma classe de dispositivo e consequentemente um diretorio para essa classe no /sys/class , é preciso registrar essas informações em uma struct chamada class que fica declarada dentro do header include/linux/device.h. , portanto…

Mãos no codigo
Entao, sem mais enrolação, vamos criar um novo módulo chamado my_class.c, lembrando que todos os códigos completos estão no link do github citado acima.

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>

MODULE_AUTHOR("SEU NOME <seu_email@email.com>");
MODULE_DESCRIPTION("Classes de dispositivos");
MODULE_LICENSE("GPL");
MODULE_VERSION("1.0");

static int __init class_init(void)
{
  return 0;
}

static void __exit class_exit(void)
{}

module_init(class_init);
module_exit(class_exit);

Assim como seu Makefile padrão:

obj-m += my_class.o

all: run

run:
 make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
 make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

Vamos declarar também um header my_class.h pra organizar nosso código e dentro do header vamos já criar nossa variável device_class.

#ifndef __MY_CLASS_H__
#define __MY_CLASS_H__

static struct class *device_class = NULL;

#endif

Agora precisamos tanto importar o header device.h quanto o nosso header my_class.h dentro do my_class.c .

#include <linux/device.h>
#include "my_class.h"

Para criarmos a nossa classe, precisamos agora alocar memória para a struct e preencher seus atributos.
Provavelmente você esta acostumado a usar o malloc() para alocação de memória em aplicações C em nível de usuário. Porém o malloc() faz parte da biblioteca stdlib.h e nós não temos acesso as bibliotecas no nível do kernel.
Porém, no kernel temos um header chamado slab.h que tem o poder de fazer alocações de memória, então, podemos importar ele no nosso my_class.c: #include <linux/slab.h>. E depois usar a função kzalloc() para alocar memória para a nossa classe.

Uma coisa a se frizar da função kzalloc() é que ela recebe dois parametros, ao contrario de malloc() que só recebe um: A quantidade de bytes a ser alocado.
O kzalloc() recebe a quantidade de bytes a ser alocado e mais uma flag, que diz respeito ao controle do comportamento dos alocadores.

Segundo a Documentação oficial:

Eles informam quais zonas de memória podem ser usadas, o quanto o alocador deve tentar encontrar memória livre, se a memória pode ser acessada pelo espaço do usuário, etc.

Caso queira mais informações sobre as flags de alocacao de memoria, pode acessar esse link.
No nosso caso, vamos utilizar a flag GFP_ATOMIC , que sinaliza ao alocador que a reserva de memória é extremamente justificada e o kernel terá problemas caso a alocação não seja feita. Porém para a maioria dos casos, GFP_KERNEL resolve.

Então alocaremos memória para a nossa classe dentro da nossa função de inicialização do modulo:

#include <linux/slab.h>

// ... 
static int __init class_init(void)
{
  device_class = (struct class *) kzalloc(sizeof(struct class), GFP_ATOMIC);
  if(!device_class) 
    pr_err("ERRO NA ALOCACAO DA CLASSE");

Após a nossa alocação de classe vamos preencher somente um atributo dessa classe: O seu nome.

 device_class->name = "7segment";

O atributo name é bem óbvio. Ele é somente o nome da classe do nosso dispositivo. Aqui declarei "7segment" porque nos próximos textos, usaremos esse modulo e construiremos um circuito simples em uma protoboard e controlaremos um display de 7 segmentos através do kernel.

Por fim, chamaremos uma função dentro da função de inicialização que registrará nossa classe e criará um diretório para a classe dentro de /sys/class com o nome que especificamos, nesse caso 7segment.

class_register(device_class);

Agora, na função de __exit precisamos matar a classe de dispositivo que criamos, então vamos incrementar essa linha de código na função de __exit

 class_unregister(device_class);
 class_destroy(device_class);

Somente para fins de visualização, vamos colocar dois pr_info() , um no__init e outro no __exit para printar algo no console

No init:

static int __init class_init(void)
{
  //...
  pr_info("class registrada");
  return 0;
}

E no exit:

static void __exit class_exit(void)
{
  //...
 pr_info("Modulo removido");
}

Vamos compilar: make .
Vamos limpar o nosso log para melhor visualizar o resultado do nosso módulo sudo dmesg -C.
E por fim vamos inserir o módulo no kernel: sudo insmod my_class.ko .
Após isso a saída do nosso sudo dmesg :

[ 1107.594074] my_class: loading out-of-tree module taints kernel.
[ 1107.594093] my_class: class registrada

Além disso, se consultarmos o diretorio /sys/class temos o diretório da classe 7segment que criamos.

Quando removermos o modulo: sudo rmmod my_class . O diretório da classe também é removido.

Revisão

Aprendemos o que é uma classe de dispositivo.
Como criar uma nova classe de dispositivo.
Vimos também uma BREVÍSSIMA introdução sobre a alocação de memória no kernel.

Hello world linux kernel module

Guilherme Giácomo Simões — Wed, 13 Sep 2023 20:06:49 +0000

Começa aqui a série que pretendo fazer sobre o desenvolvimento de device drivers para o kernel linux.
Esse texto é um conteúdo bem introdutório sobre o assunto, porém é esperado que você tenha conhecimento em linguagem C.

Aqui está o link para o repositório com os códigos contidos nessa série.
O linux é conhecido por ser um Kernel monolito. Porém, na verdade, podemos afirmar que ele é monolito e ao mesmo tempo modular. Porque temos a possibilidade de "injetar" códigos no kernel, sem precisar recompilar o kernel toda vez que fizermos uma mudança.
Existe um pacote chamado linux-headers que contém alguns utilitários para injetar um código no kernel sem que ele esteja na árvore do código.
Para instalar o linux-headers:
sudo apt install linux-headers
Caso esteja em um raspberry também ira precisar desse pacote:
sudo apt install raspberrypi-kernel-headers
Para fins de estudo, também recomendo clonar o repositório do linux
git clone https://github.com/torvalds/linux

Para começar essa BREVÍSSIMA introdução de como escrevermos módulos de drivers pra kernel linux, vou começar com o famigerado hello world. E nem será um driver em si , será somente um arquivo que vamos injetar no kernel e printar a mensagem "hello world" nos logs do kernel.
Então aqui esta nosso código do nosso hello_world.c

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>

MODULE_AUTHOR("SEU NOME <seu_email@email.com>");
MODULE_DESCRIPTION("Introducao a criacao de driver pra linux");
MODULE_LICENSE("GPL");
MODULE_VERSION("1.0");

static int __init hello_world_init(void)
{
 pr_info("Hello World\n");
 return 0;  /* successo */
}

static void __exit hello_world_exit(void)
{
 pr_info("Adeus mundo cruel\n");
}

module_init(hello_world_init);
module_exit(hello_world_exit);

Vamos a explicação desse pequeno trecho de código:
Começando pelos imports, esses 3 primeiros imports são necessarios para um modulo linux.

O primeiro <linux/init.h> fica no caminho include/linux/init.h da árvore de código do kernel, e ela é responsável por nos dar a possibilidade de usarmos a macro __init nas funções de inicialização do modulo bem como a macro __exit nas funções de destruição do modulo.

O import <linux/module.h> fica no caminho include/linux/module.h, nos da as implementações das funções module_init() e também module_exit() para informarmos ao kernel, quais funções são responsáveis pela criação e destruição do modulo. Também, esse cabeçalho contém as funções MODULE_AUTHOR, MODULE_DESCRIPTION, MODULE_LICENSE e MODULE_VERSION.

O cabeçalho <linux/kernel.h> que fica no caminho include/linux/kernel.h é um tanto quanto confuso, porque ele contém algumas coisas que não tem relação entre si, e no momento de escrita desse texto, a divisão dessas coisas ja esta em andamento, e o kernel.h é mantido para garantir a compatibilidade com os módulos que estão usando esse header. Aqui vamos usar esse cabeçalho única e exclusivamente porque eu, infelizmente, ainda não tenho conhecimento dos arquivos que estão recebendo o split do kernel.h nesse momento.

Quando inserirmos esse modulo no kernel a função hello_world_init sera invocada, e quando removermos o modulo do kernel a função hello_world_exit será invocada. Isso é uma regra de todo módulo linux.

A função pr_info() serve para registrar uma mensagem nos logs do kernel. Você pode ver essas mensagens rodando o comando sudo dmesg .
No desenvolvimento do kernel, não temos acesso as bibliotecas que normalmente temos quando desenvolvemos um sistema em C no espaço de usuário. No nível do kernel, você deve usar as libs do próprio kernel, ou fazer suas próprias libs. Você com certeza está habituado com a lib <stdio.h> , ela permite que usemos a função printf() e scanf() , mas como mencionado, ela não está disponível para nós aqui. Então, temos a implementação de algo muito parecido no kernel: As funções pr_info() , pr_err() , pr_emerg() , pr_alert() , pr_crit() , pr_warning(), pr_devel() e pr_notice() . Cada uma dessas funções vai printar no console do kernel com alguma cor diferente e uma etiqueta, diferente. Aqui está um exemplo de um pr_emerg:

[ 257.712077] Hello world @ log-level KERN_EMERG [0]

Sem mais delongas, para injetar esse codigo ao kernel, primeiro vamos compilar esse arquivo:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules.
Após isso, será gerado o binario chamado hello_world.ko e podemos inserir ele no kernel: sudo dmesg -C && sudo insmod hellow_world.ko .
Pronto, inserimos um codigo ao kernel, sem que necessariamente ele estivesse na arvore de codigo do kernel.

Claro que no futuro, caso desejarmos que esse módulo faça parte da arvore, podemos simplesmente mover ele para dentro da arvore, compilar o kernel e instalar ele na maquina. Mas isso vai ficar para um outro texto.

Agora se rodarmos o comando sudo dmesg poderemos ver o log do kernel, com a mensagem "Hello world".

Pronto, fizemos nosso primeiro modulo para o kernel do Linux. Agora, para removermos esse codigo do kernel, podemos rodar o comando sudo rmmod hello_world e quando checarmos os logs com sudo dmesg podemos ver a mensagem "Adeus mundo cruel".

Agora, somente para efeitos de facilidade, vamos criar um Makefile para esse cara, e automatizar nossa compilação do modulo:

obj+= hello_world.o

all: run

run:
 make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
 make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
Agora quando formos compilar, basta rodar o comando make.

Revisão

Aprendemos que o Kernel Linux pode ser modular, apesar de ser conhecido por ser um kernel monólito.
Aprendemos como escrever um código extremamente simples e inserir ele no kernel sem que ele esteja realmente na árvore de código do kernel.
Aprendemos que no espaço do kernel não existe bibliotecas como stdio.h e precisamos usar as bibliotecas do próprio kernel ou implementar nossas próprias bibliotecas.
Aprendemos como visualizar os logs do kernel com o comando sudo dmesg.