Link para o Tutorial 8: IIO Dummy module Experiment One: Play with iio_dummy

A realização dos tutoriais 7 e 8 foi um bom modo de encerrar essa etapa do curso, a final, pude colocar em prática vários dos conceitos aprendidos desde o primeiro tutorial.

Depois de habilitar o módulo iio_dummy via make menuconfig, realizar o build e boot da vm não consegui fazer o comando sudo make modules_install funcionar de jeito nenhum dentro da vm, por isso voltei para o Tutorial 3 para rever alguns conceitos e comando úteis sobre módulos, e finalmente consegui carregar o módulo dessa maneira:

@HOST
kw ssh --send drivers/iio/dummy/iio_dummy.ko
kw ssh --send drivers/iio/dummy/iio_dummy_evgen.ko

@VM
cp ~/iio_dummy.ko /lib/modules/`uname -r`/kernel/drivers/iio/dummy
cp ~/iio_dummy_evgen.ko /lib/modules/`uname -r`/kernel/drivers/iio/dummy

Depois disso a utilização do módulo começou tranquila:

Até o momento de montar o configfs filesystem:

Como o tutorial não comentou nada sobre esse warning e após uma breve pesquisa não pareceu ser nada que fosse quebrar os próximos passos apenas ignorei e segui em frente.

Seguindo para o problema que demorei mais tempo para resolver… Após executar o mount tentei verificar se estava tudo certo através do comando ls /mnt/iio_experiments/iio/devices/, como o tutorial indica, e foi ai que as coisas desandaram. O comando apenas retornava o erro No such file or directory, logo achei que havia algo de errado com o meu módulo. De primeiro momento sai da vm, compilei e carreguei tudo novamente e… o mesmo erro.

Meu segundo pensamento foi achar que o problema estava na vm, a final, já havia feito varios testes nela e algo poderia ter quebrado no meio do caminho, como não tinha certeza do que poderia ser esse algo resolvi “formatar” a vm. Para isso apaguei o disco ${VM_DIR}/arm64_img.qcow2 e retornei ao passo 2.2 do Tutorial 1 para criá-lo novamente - dessa vez aproveitei para salvar um backup do disco “limpo” - e mesmo após tudo isso continuei tomando o erro No such file or directory.

Dai fui tomar um café e deixei o problema de lado por um tempinho. Foi quando e me veio na cabeça “Será que o módulo tem que estar carregado?”, fui testar e… Voilà, funcionou!

Dai para frente implementai as mudanças sugeridas no tutorial e tudo correu bem:

Descrição do módulo modificado:

Conteúdo do diretório /sys/bus/iio/devices/iio:device0:

Leitura dos canais:

Considerações finais

Apesar de os tutoriais 7 e 8 serem bem explicativos algumas informações podem ser atualizadas, como por exeplo os snipets da função iio_dummy_read_raw no tutorial 7. Também acharia interessante integrar o kw em alguns passos do tutorial 8, além de adicionar o diff das mudanças feitas no módulo, para que fique mais claro o que deve ser feito.

Link para o Tutorial 6: Sending patches with git and a USP email

Nesses tutoriais vimos que o fluxo de desenvolvimento do kernel é centralizado no uso de e-mails para envio de patches, e em como podemos enviar esses patches de forma eficiente utilizando ferramentas como o git ou o kw. Aprendemos também a importância das mensagens de commits e como elas podem ser decisivas para a aceitação ou rejeição de um patch.

Para esse tutorial, por conveniência, resolvi utilizar o kw para o envio dos patches. Como o kw encapsula o git send-email os comandos de configuração acabam sendo bem parecidos, e o processo foi relativamente simples:

Por conta de limitações no e-mail USP não é possivel criar um App Password para o envio de emails. Então o tutorial fernece uma maneira de contornar isso utilizando um e-mail proxy executado via docker + docker-compose para autenticação via OAuth 2.0.

Após clonar o repositório do tutorial e configurar o arquivo emailproxy.config com as credenciais do e-mail USP, bastou executar o comando docker compose up --build para subir o container e, em outro terminal, o comando docker exec -it emailproxy-coNntainer-server-1 /bin/bash para entrar no container. Já dentro do container executei o comando emailproxy --no-gui --external-auth --config-file /app/emailproxy.config para iniciar o serviço de proxy de e-mail:

Após isso rodei o comando kw send-patch --send --private --to='felipe.souza1506@outlook.com' e confirmei o conteúdo do patch pelo editor nano:

E então… tive um problema com a autenticação do e-mail USP:

Que foi resolvido rapidamente pelo monitor da diciplina, aparentemente era uma questão de cadastro relacionado ao meu e-mail USP. Então tentando novamente tive a confirmação de sucesso no log do servidor proxy:

E a confirmação do kw informando que o e-mail foi enviado:

Então fui verificar a caixa de entrada do e-mail e o patch estava lá!

Extra!

Os comandos utilizados pelo tutorial para subir o servidor proxy necessitam de dois terminais abertos ao mesmo tempo, o que pode ser um pouco incoveniente para quem está realizando o tutorial. Por isso tomei a liberdade para editar um pouco as configurações do compose para que esse segundo terminal pudesse ser extinto.

Isso é possivel de duas maneiras:

1º:

Adicionando o comando a ser excutado diretamente no docker-compose.yaml

services:
  server:
+   command: ["emailproxy", "--no-gui", "--external-auth", "--config-file", "/app/emailproxy.config"]
    build: .
    ports:
      - "2587:2587"
    stdin_open: true
    tty: true
    volumes:
      - ./emailproxy.config:/app/emailproxy.config

E então subir o container utilizando o seguinte comando:

docker compose run --service-ports --build server 

2º:

Caso a edição do arquivo não seja desejada, é possível fazer a mesma coisa atráves do comando:

docker compose run --service-ports --build server emailproxy --no-gui --external-auth --config-file /app/emailproxy.config

Explicação:

O comando original docker compose up sobe todos services configurados e agrega o output de cada container em um único terminal, ignorando os inputs.

Já o comando docker compose run sobe apenas um único service, passado por parametro para o comando, e por isso é possível utilizar o stdin para interagir com o container. O parâmetro –service-ports serve para criar e mapear as portas declaradas.

Fim

Esses foram os valiosos aprendizados desta semana, até a próxima pessoal :)

Depois desse tutorial entendemos um pouco mais a frase “Tudo no Linux é um arquivo”, a final é nesse tutorial que aprendemos sobre os chamados Linux character devices, que são arquivos especiais utilizados para fazer a comunicação entre o espaço do usuário e o kernel. Também desenvolvemos o nosso primeiro driver para interagir com um desses “arquivos”.

Como nesse tutorial não tive nenhum problema para seguir os passos vou registar aqui tudo funcionando localmente.

O driver desenvolvido, simple_char, não faz muito mais do que tranferir informações de texto entre o espaço do usuário e um buffer no espaço do sistema, através de um character device. Podemos testar isso com auxilio dos scripts fornecidos pelo tutorial read_prog e write_prog:

Proposed Exercices

1. Printing device numbers: Modify the simple_char driver to make it print major and minor device numbers on device open.

   After a little bit of research I found that the device numbers are stored in the inode structure, so I modified the simple_char_open function to print the major and minor numbers from inode pointer using the functions MAJOR and MINOR. Here is the modified code:

    ...
    static int simple_char_open(struct inode *inode, struct file *file)
    {
        int major_num = MAJOR(inode->i_rdev);
        int minor_num = MINOR(inode->i_rdev);
        pr_info("%s: MAJOR: %d MINOR: %d %s\n", KBUILD_MODNAME, major_num, minor_num, __func__);
        return 0;
    }
    ...
   

   After recompiling and installing the module, I ran the test scripts again and got the following output in the kernel log:

   

2. Device private data: Modify the simple_char driver to register more than one minor device number and make it keep separate buffers for each of them. Check the device minor number on device open and allocate a buffer for it if it doesn’t have one. Also, make the read/write operations run over the buffer for the particular major/minor device number pair. Access f_inode field of struct file to get a pointer to the device inode then access i_rdev field of struct inode to get the device ID (dev_t) from which you can extract the device minor number. On module unload, free all allocated buffers. With that, we can think of each pair of major/minor numbers as a different character device and each of them will have their own data. Finally, create device nodes with different minor numbers to test you implementation.

   This one was a little bit more tricky, but i managed to implement it by creating a array of buffers, one for each minor number. After modifing all the functions except simple_char_release, the code looks like this:

    #include <linux/init.h>
    #include <linux/module.h>
   
    #include <linux/kdev_t.h> /* for MAJOR */
    #include <linux/cdev.h> /* for cdev */
    #include <linux/fs.h> /* for chrdev functions */
    #include <linux/slab.h> /* for malloc */
    #include <linux/string.h> /* for strlen() */
    #include <linux/uaccess.h> /* copy_to_user() */
   
    struct cdev *s_cdev;
    static dev_t dev_id;
   
    #define S_BUFF_SIZE 4096
   
    #define MINOR_NUMS 2
   
    static char *s_bufs[MINOR_NUMS];
   
    static int simple_char_open(struct inode *inode, struct file *file)
    {
        int major_num = MAJOR(inode->i_rdev);
        int minor_num = MINOR(inode->i_rdev);
        pr_info("%s: MAJOR: %d MINOR: %d %s\n", KBUILD_MODNAME, major_num, minor_num, __func__);
        if (!s_bufs[minor_num]) {
            s_bufs[minor_num] = kmalloc(S_BUFF_SIZE, GFP_KERNEL);
            if (!s_bufs[minor_num])
                return -ENOMEM;
   
            snprintf(s_bufs[minor_num], S_BUFF_SIZE, "This is data from simple_char buffer. MAJOR: %d MINOR: %d", major_num, minor_num);
            pr_info("%s: MAJOR: %d MINOR: %d %s Allocated new buffer for minor %d\n", KBUILD_MODNAME, major_num, minor_num, __func__, minor_num);
        }
        return 0;
    }
   
    static ssize_t simple_char_read(struct file *file, char __user *buffer,
                    size_t count, loff_t *ppos)
    {
        int minor_num = MINOR(file->f_inode->i_rdev);
        int n_bytes;
        pr_info("%s: %s about to read %ld bytes from buffer position %lld\n",
            KBUILD_MODNAME, __func__, count, *ppos);
        n_bytes = count - copy_to_user(buffer, s_bufs[minor_num] + *ppos, count);
        *ppos += n_bytes;
        return n_bytes;
    }
   
    static ssize_t simple_char_write(struct file *file, const char __user *buffer,
                    size_t count, loff_t *ppos)
    {
        int minor_num = MINOR(file->f_inode->i_rdev);
        int n_bytes;
        pr_info("%s: %s about to write %ld bytes to buffer position %lld\n",
            KBUILD_MODNAME, __func__, count, *ppos);
        n_bytes = count - copy_from_user(s_bufs[minor_num] + *ppos, buffer, count);
        return n_bytes;
    }
   
    static int simple_char_release(struct inode *inode, struct file *file)
    {
        pr_info("%s: %s\n", KBUILD_MODNAME, __func__);
        return 0;
    }
   
    static const struct file_operations simple_char_fops = {
        .owner = THIS_MODULE,
        .open = simple_char_open,
        .release = simple_char_release,
        .read = simple_char_read,
        .write = simple_char_write,
    };
   
    static int __init simple_char_init(void)
    {
        int ret;
   
        pr_info("Initialize %s module.\n", KBUILD_MODNAME);
   
        /* Dynamically allocate character device device numbers. */
        /* The name passed here will appear in /proc/devices. */
        ret = alloc_chrdev_region(&dev_id, 0, MINOR_NUMS, "simple_char");
        if (ret < 0)
            return ret;
   
        /* Allocate and initialize the character device cdev structure */
        s_cdev = cdev_alloc();
        s_cdev->ops = &simple_char_fops;
        s_cdev->owner = simple_char_fops.owner;
   
        /* Adds a mapping for the device ID into the system. */
        return cdev_add(s_cdev, dev_id, MINOR_NUMS);
    }
   
    static void __exit simple_char_exit(void)
    {
        /*
        * Undoes the device ID mapping and frees cdev struct, removing the
        * character device from the system.
        */
        cdev_del(s_cdev);
        /* Unregisters (disassociate) the device numbers allocated. */
        unregister_chrdev_region(dev_id, MINOR_NUMS);
   
        for (int i = 0; i < MINOR_NUMS; i++) {
            if (s_bufs[i]) {
                kfree(s_bufs[i]);
                pr_info("%s: The buffer for minor %d is free\n", KBUILD_MODNAME, i);
            }
        }
        pr_info("%s exiting.\n", KBUILD_MODNAME);
    }
   
    module_init(simple_char_init);
    module_exit(simple_char_exit);
   
    MODULE_AUTHOR("felipers@ime.usp.br");
    MODULE_DESCRIPTION("A simple character device driver example.");
    MODULE_LICENSE("GPL");
   

   Despite the new stuff, I also had to change strcpy to snprintf in simple_char_open function, beacuse I wanted to print major and minor numbers on the buffer and strcpy doesn’t format the string:

   

   After recompiling and installing the module, I created two device nodes with different minor numbers to test the implementation:

   

No tutorial 3 aprendemos a criar módulos que podem ser “acoplados” no kernel linux.

Seguindo o conceito do blog vou discorrer apenas sobre os pontos do tutorial em que tive algum tipo de problema.

Passo 2:

Esse não é bem um problema em si, mas o tutorial informa que os registros nos arquivos Kconfig e Makefile devem estar em ordem alfabética, porém os arquivos originais já estavam fora de ordem, então apenas inseri as novas configurações no inicio de cada um.

Passo 3:

Ao Executar make -C "$IIO_TREE" menuconfig reparei que a opção apresentada no tutorial Simple Test Module não estava disponível então selecionei a opção Simple exemple Linux Kernel module (NEW): Então segui o tutorial até o momento de instalar os novos módulos, mas quando executei o seguinte comando:

sudo guestmount --rw --add "${VM_DIR}/arm64_img.qcow2" --mount /dev/<rootfs> "${VM_DIR}/arm64_rootfs"

Fui agraciado com o seguinte erro: Tentei exportar as variáveis de debug mas o erro continou o mesmo, ai notei que a minha VM estava rodando, então desliguei ela e tentei rodar novamente, funcionou!

Seguindo os comandos bloco…Tive um problema no unmount sudo guestunmount "$VM_MOUNT_POINT":

Já que a variável VM_MOUNT_POINT não existe, o comando correto é o:

sudo guestunmount "${VM_DIR}/arm64_rootfs" 

Passo 4:

Todos os comandos rodaram sem problemas, vou deixar aqui um print do módulo funcionando:

Passo 5:

Ao executar o comando make -C "$IIO_TREE" menuconfig para configurar o simple_mod_part, selecionei a opção: Dai para frente não tive mais problemas para seguir o tutorial e consegui executar o simple_mod_part com sucesso dentro da VM.

Proposed Exercices

1. The .config file that comes with the arm64 VM is bloated with features built together with the kernel image (y config value) which is why even after make localmodconfig the .config file did not reduce significantly and the build took a lot of time. Run make allmodconfig to turn builtin configuration values into module values when possible. After that, boot the VM, regenerate the list of needed modules as described in Part 1, run make localmodconfig with new list of modules. Did it reduce .config size further? How much? Does the whole kernel build take less time with the new .config? Does the resulting kernel still boot?

   .config size before the exercise: 179Kb
   .config size after make allmodconfig: 419K
   .config size after make localmodconfig with new list of modules: 204K
   If we compare the final size with the initial size it actualy got bigger, but if we compare with the size of .config with all the modules enabled it got ~51% smaller.
   Build time before the exercise: ~6:30
   Final build time: ~8:40
   Yes, the result kernel still boots, but I cant connect to it neither using sudo virsh connect arm64 nor kw ssh.

2. Sometimes developers lose track of what .config was used to generate a running kernel after messing arround for enough time. The in kernel configuration config (IKCONFIG) exports (imports?) the .config file used to build the kernel into the kernel image and make it later availabe as /proc/config.gz file. Enable IKCONFIG, rebuild the kernel and read your .config from /proc/config.gz within the VM.

   In my case IKCONFIG was already enabled, so i just needed to read the file inside the VM:

3. Customize the log messages for simple_mod and simple_mod_part. Add #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt at the top of the module source files. KBUILD_MODNAME will expand to the module source file name resulting in every message logged through pr_info() (and friends) being prepended by the module name. See include/linux/printk.h for documentation. Tip, add the above define before header inclusions to avoid build warnings.

   No problems with these, here is the logs:

Considerações finais

Achei interessante a maneira que o kernel lida com novos módulos e como podemos ver eles sendo executados.

Nesse tutorial aprendemos a compilar o kernel linux e depois realizar um boot em um máquina virtual utilizando esse kernel.

Seguindo o conceito do blog vou discorrer apenas sobre os pontos do tutorial em que tive algum tipo de problema.

Passo 3:

Na primeira vez que segui o tutorial defini o IP da VM para o IP obtido através do comando:

sudo virsh net-dhcp-leases default

Que dentre as outras informações retornados, temos o IP 192.168.122.24/24, então rodei:

kw remote --add arm64 root@192.168.122.24 --set-default

Segui o tutorial até o passo 5 mas precisei desligar a minha máquina para tratar de outro assunto, quando retomei o tutorial notei que o comando kw ssh estava falhando pois o IP definido não estava correto, executei o comando sudo virsh net-dhcp-leases default novamente o obtive o IP 192.168.122.166. Então configurei o kw para utilizar o novo IP:

kw remote --add arm64 root@192.168.122.166 --set-default

Passo 4:

Ao executar o comando kw ssh --get '~/vm_mod_list' me deparei com o seguinte erro:

bash: line 1: rsync: command not found
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(232) [Receiver=3.2.7]
An error occurred while uploading the file(s). rsync return code: 12

Após uma breve pesquisa entendi que isso estava ocrrendo pela falta da ferramenta rsync na VM, o que foi rapidamente resolvido através da instalação da mesma:

sudo apt update
sudo apt install rsync

Passo 6:

Ao executar kw deploy --modules me deparei com alguns erros além dos erros apontados pelas ferramentas strip e make:

Mas o deploy finalizou com sucesso.

De inicio achei que o boot utilizando o novo kernel não tinha funcionado, pois fiz as alterações nos scripts launch_vm_qemu e create_vm_virsh e quando executei as funções não obtive nenhum log. O que me fez “criar” mais duas funções launch_vm_qemu_original e create_vm_virsh_original que utilizam o kernel obtido da imagem baixada no Tutorial 1 e essas rodaram com sucesso. O que me fez pensar que o novo kernel poderia estar com problema, então refiz o tutorial para garantir que não pulei nenhuma etapa e mesmo assim o problema continou. A solução para esse caso é subir a VM e aguardar alguns momentos, já que não sabemos o que está acontecendo pela falta de logs, então entrar nela via ssh para verificar que novo kernel estava lá:

Considerações finais

Achei o tutorial bem explicativo, no geral nenhum dos problemas encontrados foi complicado de resolver.

Como o próprio nome já diz, o primeiro tutorial nos ensina a realizar o setup inical do QEMU e do libvirt para desenvolvimento do Kernel Linux.

• QEMU: Emulador utilizado para subir máquinas virtuais.
• libvirt: Gerenciador de máquinas virtuais.
• Kernel Linux: Núcleo utilizado por diversos sistemas operacionais.

Já que a finalidade desse blog é contar como foi a minha experiência seguindo o tutorial, vamos lá…

PS: Vou fazer comentários apenas sobre os passos em que tive algum tipo de problema.

Passo 1:

Tive problemas para inserir o usuário no grupo libvirt-qemu. No tutorial é informado que basta fazer logout + login e seguir, mas precisei reiniciar minha máquina para que as configurações fossem persistidas.

Passo 2:

Passo 2.1: O único problema que tive foi para baixar a imagem. A imagem informada no tutorial não está mais disponível, então baixei a http://cdimage.debian.org/cdimage/cloud/bookworm/daily/latest/debian-12-nocloud-arm64-daily.qcow2.

Passo 2.3: cometi um erro no script launch_vm_qemu, invés de vda2 coloquei <vda2> sem perceber, ai estava tomando o seguinte erro:

...
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/<vda2> does not exist.  Dropping to a shell!
(initramfs) ^[[Aqemu-system-aarch64: terminating on signal 15 from pid 9100 ()

Acabei demorando um pouco para perceber que o erro era por conta dos sinais de maior que e menor que. Mas no final consegui subir a vm com sucesso:

Passo 3:

Para que esse passo desse certo precisei instalar o openssh-server na vm e iniciar o serviço do ssh:

sudo apt-get update
sudo apt-get install openssh-server
sudo systemctl enable ssh

Passo 5:

Fiquei um pouco confuso sobre onde era para rodar o comando, já que no tutoral não existe indicação de @host nem de @VM no snippet:

sudo EDITOR=vim; sudo virsh edit iio-arm64

Porém fica evidente que deveria ser no host devido ao uso do comando virsh.

Além disso o nome io-arm64 não segue o padrão arm64 adotado no resto do tutorial, o que também deixa um pouco confuso.

Após rodar o comando e instalar o virtiofs no host tive que reiniciar a vm para que a configuração do filesystem compartilhado fosse persistida. O que funcionou perfeitamente:

Considerações finais

Achei o tutorial bem explicativo, no geral nenhum dos problemas encontrados foi complicado de resolver.