Instituto de Computação - UNICAMP

MC504/MC514 - Sistemas Operacionais

Implementação de um Módulo no Linux

Islene Calciolari Garcia

Introdução
- Ambiente 1: QEMU, imagem e kernel compilado externamente
- Ambiente 2: Qualquer máquina em que você possa ser um superusuário
Outros exemplos
Sistemas de arquivos como módulos
Especificação

Antes de implementar os nossos drivers, vamos testar os exemplos disponibilizados na série Linux Device Drivers do site Open Source forU. No arquivo ofd.tar.xz você encontrará um diretório ofd com arquivos retirados do site citado. As aplicações de teste estão em apps.tar.xz

Outra fonte interessante é o curso An introduction to Linux Kernel Programming.

Ambiente 1: QEMU, imagem e kernel compilado externamente

Configuração similar à do projeto 2. Você deve colocar sua implementação no subdiretório drivers e fazer o build completo.

Devemos criar um diretório ofd em drivers contendo o arquivo ofd.c e um Makefile contendo apenas:
```
obj-m += ofd.o
```
Devemos alterar o Makefile deste diretório drivers acrescentando a linha:
```
obj-y += ofd/
```
A seguir, você deverá deverá executar make no diretório raiz dos fontes do kernel.
```
 $ make -j 5 ARCH=i386
```

Precisaremos incluir os arquivos .ko no ambiente do QEMU. Como não vamos fazer um make modules_install, passaremos o novo driver como um disco.

$ qemu-system-i386 -hda ../ArchLinux_mc504.cow -kernel arch/x86/boot/bzImage -append "rw root=/dev/hda" -drive format=raw,file=drivers/ofd/ofd.ko

Neste teste, o driver tem apenas as função init e exit. Vocé pode testar se o driver foi incluído dinamicamente. No QEMU, execute os comandos:
```
  $ cat /dev/hdb > ofd.ko
  $ insmod ofd.ko
  $ lsmod
   ...
  $ rmmod ofd.ko
  $ dmesg | grep ofd
```

Ambiente 2: Qualquer máquina em que você possa ser um superusuário

Uma opção é utilizar o ambiente OpenStack.

Neste caso, você irá compilar os drivers e depois incorporá-los dinamicamente com o comando insmod ou modprobe. Utilize, preferencialmente, uma partição dedicada só para isso ou uma máquina virtual. Caso contrário, sua implementação pode corromper o kernel.

Você precisará dos headers do kernel. Para instalar a versão mais recente:
```
# dnf install kernel-devel
```
Para instalar headers que combinam com o kernel instalado.
```
    
# dnf install "kernel-devel-uname-r == $(uname -r)"
```

O arquivo Makefile terá o seguinte conteúdo (veja explicação detalhada sobre este arquivo em An introduction to linux kernel programming: lesson 5.

CC = gcc
CONFIG_MODULE_SIG=n

ifeq ($(KERNELRELEASE),)

KERNELDIR ?= /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)

.PHONY: build clean

build:
        $(MAKE) -C $(KERNELDIR) M=$(PWD) modules

clean:
        rm -rf *.o *~ core .depend .*.cmd *.ko *.mod.c
else

$(info Building with KERNELRELEASE = ${KERNELRELEASE})
obj-m :=    ofd.o

endif

Outros exemplos

O código para os exemplos está disponível em ofd.tar.xz. Siga passos semelhantes aos já explicados anteriormente e no projeto 2 para rodá-los no ambiente escolhido.

`ofcd: primeiro driver de caracteres`

Os drivers são identificados por números major e um minor. O driver ofcd requisita dinamicamente um número major para o sistema e reserva três números do tipo minor. Você pode conferir isso com os comandos:

  $ insmod ofcd.ko
  $ lsmod
   ...
  $ dmesg | tail
  $ cat /proc/devices
   ...
   252 ofcd

É possível criar as entradas em /dev explicitamente:

  $ mknod /dev/ofcd0 c 252 0
  $ mknod /dev/ofcd1 c 252 1
  $ mknod /dev/ofcd2 c 252 2
  $ ls /dev

No entanto, ainda não conseguimos utilizar estes arquivos.

  $ cat /dev/ofcd0

`ofcd-null`

O arquivo ofcd-null.c tem o código que permitirá operações de leitura e escrita, com a instalação automática do arquivo em /dev.

  $ insmod ofcd-null.ko
  $ ls /dev/
  $ cat /dev/ofcd-null
  $ echo "teste" > /dev/ofcd-null

`ofcd-lastchar-bug`

Em Decoding Character Device File Operations, o autor ensina como manter o último caractere escrito. Na parte 6 da série, Shweta tenta armazenar o último caractere da seguinte maneira:

static char c;

static ssize_t my_read(struct file *f, char __user *buf, size_t len, loff_t *off)
{
    printk(KERN_INFO "Driver: read()\n");
    buf[0] = c;
    return 1;
}
static ssize_t my_write(struct file *f, const char __user *buf, size_t len, loff_t *off)
{
    printk(KERN_INFO "Driver: write()\n");
    c = buf[len - 1];
    return len;
}

Esta abordagem está codificada no arquivo ofcd-lastchar-bug.c. Você pode testar com a aplicação bug-app.

`ofcd-lastchar: copy_to_user e copy_from_user`

Ainda na parte 6 da série, Shweta descobre as funções copy_to_user e copy_from_user.

static char c;

static ssize_t my_read(struct file *f, char __user *buf, size_t len, loff_t *off)
{
    printk(KERN_INFO "Driver: read()\n");
    if (copy_to_user(buf, &c, 1) != 0)
        return -EFAULT;
    else
        return 1;
}
static ssize_t my_write(struct file *f, const char __user *buf, size_t len, loff_t *off)
{
    printk(KERN_INFO "Driver: write()\n");
    if (copy_from_user(&c, buf + len - 1, 1) != 0)
        return -EFAULT;
    else
        return len;
}

Refaça os testes com a aplicação lastchar-app.

Se você procurar a documentação sobre copy_to_user e copy_from_user verá que estas funções podem dormir. Por quê?

Exercício simples (não é sugestão de tema para projeto): tente implementar uma versão deste driver que armazene a última escrita com kmalloc e kfree.

`query_ioctl`

Na parte 9 da série, o autor ilustra o uso da função ioctl (i/o control) para controle dos dispositivos. O driver query_iocl tem três variáveis (status, dignity, ego) que são controladas a partir de chamadas da aplicação query_app.

./query_app      to display the driver variables
./query_app -c   to clear the driver variables
./query_app -g   to display the driver variables
./query_app -s   to set the driver variables

Você deve rodar este exemplo e entender o funcionamento de ioctl. Como posso alterar o tipo de argumento passado para ioctl? Esta função permite grande flexibilidade..

No capítulo 4 do Kernel Hacking: ioctls: Not writing a new system call podemos encontrar a seguinte informação:

A system call generally looks like this

asmlinkage long sys_mycall(int arg)
{
        return 0;
}

First, in most cases you don't want to create a new system call. You create a character device and implement an appropriate ioctl for it. This is much more flexible than system calls, doesn't have to be entered in every architecture's include/asm/unistd.h and arch/kernel/entry.S file, and is much more likely to be accepted by Linus.

No entanto, nem todos amam este design. Você consegue dizer algumas desvantagens?

Sistemas de arquivos como módulos

Todo device driver é um driver, mas nem todo driver é um device driver... :-)

Sistemas de arquivos podem ser implementados como módulo que podem ser adicionados dinamicamente ao kernel. Veja os seguintes exemplos:

LWNFS: Texto didático, primeira versão escrita em 2002. O sistema de arquivos proposto é bastante simples e contém apenas 4 arquivos que funcionam como contadores do número de acessos. Veja o código atualizado em lwnfs.tar.xz e teste, após fazer a instalação, seguindo os seguintes passos:
```
$ dd if=/dev/zero of=rep bs=1k count=4
$ mkdir -p mnt
$ mount -t lwnfs -o loop rep mnt
$ cd mnt
$ ls
$ cat counter0
0
$ cat counter0
1
$ echo 200 > counter1
$ cat counter1
200      
```
islenefs: Código desenvolvido por Glauber de Oliveira Costa em 1s2008 para um projeto da disciplina MC514. É um sistema de arquivos simples que armazena os arquivos em memória. Veja a versão atualizada em islenefs.tar.xz e teste como a seguir:
```
$ dd if=/dev/zero of=rep bs=1k count=4
$ mkdir -p mnt
$ mount -t islenefs -o loop rep mnt      
```

Se for utilizar o QEMU, coloque a implementação do sistema de arquivos em fs e não é necessário fazer o passo de instalação do módulo.

Especificação

Seu grupo deve escolher e implementar uma funcionalidade para um pseudo device-driver ou um mini sistema de arquivos.

Apresentação obrigatória nos dias 12 ou 14 de dezembro. Entrega do código, uma abordagem para testes e um arquivo README explicando o projeto via Moodle.