Integração de Sistemas Embebidos MECom :: 5º ano

Transcrição

1 Integração de Sistemas Embebidos MECom :: 5º ano Device Drivers em Linux Criação e execução de módulos António Joaquim Esteves Bibliografia: capítulo 2, LDD 3ed, O Reilly DEP. DE INFORMÁTICA ESCOLA DE ENGENHARIA UNIVERSIDADE DO MINHO

2 Sumário Exemplo: o módulo Hello World Módulos vs aplicações Compilar e carregar um módulo A tabela de símbolos Questões preliminares Inicializar e desinstalar um módulo Módulos com parâmetros Drivers que funcionam no espaço do utilizador

3 Introdução Esta secção introduz todos os conceitos essenciais para desenvolver módulos e programar o kernel. Através do módulo Hello World vamos analisar o código básico e as fases envolvidas no desenvolvimento de qualquer módulo, sem especificar uma classe de dispositivos. Os módulos dados como exemplo funcionam na maioria dos kernels 2.6.x. Para construir módulos para um kernel 2.6.x requer que se tenha criado e configurado toda a árvore dum kernel no sistema. Os módulos para um kernel 2.6.x são linkados com ficheiros objecto que se encontram na árvore do código fonte dum kernel.

4 Criação e execução de módulos m Exemplo: o módulo m Hello World Este exemplo já foi analisado na aula anterior: #include "/usr/src/kernels/ _fc5i686/include/linux/init.h #include "/usr/src/kernels/ _fc5i686/include/linux/module.h /* MODULE_LICENSE() Indica ao kernel que este modulo possui uma licenca livre, evitando assim que ele se queixe quando se carrega o modulo */ MODULE_LICENSE("Dual BSD/GPL"); static int hello_init (void) { /* printk() e' uma funcao similar ao printf do C, mas que nao recorre a qualquer biblioteca standard do C. KERN_ALERT e' uma string que indica a prioridade da mensagem, alta neste caso para garantir que a mensagem aparece em tempo util. */ printk(kern_alert "Ola', o modulo foi carregado no kernel.\n"); return 0; } static void hello_exit (void) { printk(kern_alert "Adeus, o modulo foi removido.\n"); } module_init (hello_init); module_exit (hello_exit);

5 Módulos vs aplicações Enquanto a maioria das aplicações executa uma única tarefa do início até ao fim, os módulos apenas se registam de modo a responder a pedidos futuros. A tarefa da função de inicialização dum módulo é preparálo para as evocações futuras das suas funções. A função de conclusão (exit) dum módulo é evocada exactamente antes de o módulo ser desinstalado. Esta abordagem é análoga à programação orientada a eventos. Nem todas as aplicações são orientadas a eventos todos os módulos são. Uma aplicação pode chamar funções que não define a fase de link resolve as referências externas usando a biblioteca adequada. Um módulo é linkado apenas com o kernel só pode chamar as funções exportadas pelo kernel não se pode fazer o link com bibliotecas.

6 Módulos vs aplicações Espaço do utilizador vs espaço Enquanto os módulos são executados no espaço, as aplicações são executadas no espaço do utilizador. O sistema operativo deve garantir o funcionamento independente de vários programas e protegelos de acessos não autorizados aos recursos. Isto só é conseguido se o CPU proteger o software do sistema das aplicações. Uma alternativa para conseguir esta protecção é implementar vários níveis de protecção no CPU. Cada nível tem o seu papel e algumas operações não são permitidas nos níveis inferiores. Um programa tem um número reduzido de formas de mudar de um nível para outro. Os processadores actuais possuem pelo menos 2 níveis de protecção.

7 Módulos vs aplicações Espaço do utilizador vs espaço Em Linux, o kernel é executado no nível mais alto (modo supervisor), em que tudo é permitido. As aplicações executamse no nível mais baixo (modo user), onde o processador controla o acesso directo ao h/w e impede o acesso não autorizado à memoria. Os modos de execução são normalmente designados de espaço do kernel e espaço do utilizador. A cada modo estão associados os privilégios de execução e um espaço de endereçamento próprio. O Linux transfere a execução do espaço do utilizador para o sempre que a aplicação fizer uma chamada ao sistema ou a aplicação for suspensa por uma interrupção de h/w. Num driver, alguma funções são executadas usando chamadas ao sistema e outras servem interrupções.

8 Concorrência no kernel Módulos vs aplicações A maioria das aplicações é executada sequencialmente do início ao fim. O código do Kernel não executa dessa forma tão simples deve estar preparado para que ocorram vários eventos em simultâneo. Em Linux, vários processos podem tentar usar um driver ao mesmo tempo. A maioria dos dispositivos é capaz de interromper o processador. As rotinas de serviço a interrupções funcionam assincronamente e podem ser evocadas enquanto o driver executa outra tarefa. Como o Linux pode correr em sistemas multiprocessador, um driver pode estar a executar concorrentemente em vários CPUs.

9 Concorrência no kernel Módulos vs aplicações No kernel 2.6, o código passou a ser preemptivo as questões de concorrência dum sistema uniprocessador são similares às dum sistema multiprocessador. Em consequência, o código em Linux deve ser reentrante pode ser executado em vários contextos (processos) ao mesmo tempo. Os múltiplos fios de execução (threads) devem ser mantidos separados e deve evitarse corromper os dados partilhados. No kernel 2.6, o código não deve assumir que dispõe do processador atribuído a si durante um determinado intervalo.

10 O processo actual Módulos vs aplicações Embora os módulos não sejam executados sequencialmente, como são as aplicações, o grosso da actividade decorre no âmbito de um processo específico. O código do Kernel pode referenciar o processo actual acedendo à variável global current, definida em <asm/current.h>. current guarda um apontador para struct task_struct, definida em <linux/sched.h>. A instrução seguinte imprime o ID e o comando do processo actual, acedendo aos campos de struct task_struct: printk (KERN_INFO O processo e \"%s\" (pid %i)\n", current>comm, current>pid);

11 Módulos vs aplicações Programação vs programação no modo user As aplicações executam em memória virtual e com uma pilha enorme. O kernel possui uma pilha muito reduzida ex: 1 página de 4k bytes. As funções de todos os módulos kernel vão partilhar a mesma pilha. Funções da API assinaladas com costumam ser de baixo nível devem ser usadas com cuidado. O código do Kernel não pode usar aritmética em virgula flutuante.

12 Compilar módulos Compilar e carregar um módulo m Primeiro, vamos ver como se constrói um módulo. Depois de instalar as fontes, escrevese uma makefile para o módulo. Para o exemplo Hello World a seguinte linha é suficiente: objm := hello.o Esta atribuição indica que se vai construir um módulo a partir do ficheiro objecto hello.o. O módulo gerado terá o nome hello.ko. Se um módulo module.ko for gerado a partir de 2 ficheiros fonte (file1.c e file2.c), as instruções a usar são: objm := module.o moduleobjs := file1.o file2.o

13 Compilar módulos Compilar e carregar um módulo m Se as fontes estiverem no directório ~/kernel26, o comando make a usar na geração do módulo será: make C ~/kernel26 M=`pwd` modules Este comando começa por mudar para o directório para indicado pela opção C. A opção M= faz a makefile regressar ao directório do módulo em causa, antes de construir o módulo alvo especificado pela variável objm module.o neste exemplo. O comando make anterior pode ser substituído por uma makefile:

14 Compilar e carregar um módulo m Compilar módulos # If KERNELRELEASE is defined, we've been invoked from the # kernel build system and can use its language. ifneq ($(KERNELRELEASE),) objm := hello.o # Otherwise we were called directly from the command # line invoke the kernel build system. else KERNELDIR?= /lib/modules/$(shell uname r)/build PWD := $(shell pwd) default: $(MAKE) C $(KERNELDIR) M=$(PWD) modules endif

15 Compilar módulos Compilar e carregar um módulo m Normalmente, esta makefile é lida 2 vezes. Primeiro localizase o directório com as fontes. Se o kernel alvo é diferente em execução, deve indicarse onde se encontra este directório com: A opção KERNELDIR= na linha de comandos. A variável de ambiente KERNELDIR. Uma linha da makefile em que se atribui um valor a KERNELDIR. A makefile evoca default: target, que executa o comando make pela 2ª vez. Na 2ª leitura, a makefile define objm e as makefiles geram o módulo alvo.

16 Carregar e remover módulos Compilar e carregar um módulo m Depois de o módulo estar construído, é preciso carregálo no kernel o programa insmod realiza esta tarefa. O insmod Faz o link dos símbolos por resolver com a tabela de símbolos. Aceita opções da linha de comandos. Atribui valores aos parâmetros do módulo antes de fazer o link com o kernel. Baseiase numa chamada ao sistema definida em kernel/module.c. A função sys_init_module Aloca memória para guardar o módulo (com vmalloc). Copia o código do módulo para essa zona de memória. Resolve as referências do módulo ao kernel usando a tabela de símbolos. Chama a função de inicialização do módulo. O programa rmmod permite remover módulos. O programa lsmod gera uma lista com os módulos carregados no kernel.

17 Compilar e carregar um módulo m Dependências da versão Os módulos estão fortemente ligados às estruturas de dados e funções de uma determinada versão. Num dos passos da construção, fazse o link entre o módulo em causa e o ficheiro vermagic.o. Este ficheiro objecto contém informação acerca : a sua versão, o compilador usado e algumas variáveis de configuração. Ao tentar carregar um módulo, a informação relativa ao kernel e ao módulo é comparada se não houver compatibilidade o módulo não é carregado surge uma mensagem de erro: > insmod hello.ko Error inserting './hello.ko': 1 Invalid module format

18 Compilar e carregar um módulo m Quando existe preocupaçao com a versão, deve usarse as definições de linux/version.h. Este ficheiro, incluído automaticamente ao usar linux/module.h, define as seguintes macros: UTS_RELEASE, LINUX_VERSION_CODE, KERNEL_VERSION(major,minor,release). Dependências da arquitectura alvo O código pode ser optimizado para um processador específico de modo a obter o melhor desempenho com a arquitectura alvo. Quando se carrega um módulo, o kernel verifica se as configurações relativas ao processador são compatíveis recorrendo a vermagic.o. Se o módulo tiver sido compilado com opções diferentes, não é carregado.

19 A tabela de símbolos s Já vimos que insmod resolve os símbolos por definir através da tabela de símbolos públicos. A tabela contém o endereço de itens globais, necessários para implementar drivers modulares. Ao carregar um módulo, os símbolos por ele exportados passam a fazer parte da tabela de símbolos. Exportamse símbolos quando eles forem úteis a outros módulos. Quando se usa módulos empilhados sobre outros módulos, é conveniente usar o programa modprobe. modprobe funciona de forma análoga a insmod mas além do módulo em causa, carrega todos os que lhe são necessários. Para exportar símbolos pode usarse as macros seguintes: EXPORT_SYMBOL(name); OU EXPORT_SYMBOL_GPL(name);

20 Questões preliminares A maior parte do código kernel inclui vários ficheiros header. É habitual um módulo usar as seguintes linhas: #include <linux/module.h> #include <linux/init.h> module.h contém definições de símbolos e funções necessários para carregar módulos. init.h é útil para e especificar as funções de inicialização e remoção. moduleparam.h permite passar parâmetros quando se carrega o módulo. O módulo deve especificar a licença que se aplica ao seu código: MODULE_LICENSE ("GPL"); Outras definições descritivas passíveis de incluir num módulo: MODULE_AUTHOR, MODULE_DESCRIPTION, MODULE_VERSION, MODULE_ALIAS e MODULE_DEVICE_TABLE.

21 Inicializar e desinstalar um módulo m A função de inicialização regista as facilidades oferecidas pelo módulo. Facilidade é uma funcionalidade nova, que pode ser acedida pelas aplicações. A definição da função de inicialização é sempre assim: static int init initialization_function (void) { /* Initialization code here */ } module_init (initialization_function); Uma função de inicialização deve ser declarada static não precisa ser visível no exterior do ficheiro em que é definida. O token init indica ao kernel que a função só é usada durante a inicialização. Para assinalar dados que só são usados durante a inicialização existe o token initdata.

22 Inicializar e desinstalar um módulo m É obrigatório utilizar a macro module_init. Esta macro adiciona ao código objecto do módulo a localização da sua função de inicialização. Existe uma função para registar cada facilidade oferecida pelo módulo. Os argumentos passados a essas funções são apontadores para estruturas de dados que descrevem a nova facilidade e o nome da facilidade a registar. A estrutura de dados contém apontadores para as funções que podem ser chamadas do módulo.

23 Inicializar e desinstalar um módulo m A função de remoção (cleanup) Qualquer módulo não trivial requer uma função de remoção. Esta função apaga os registos das interfaces e devolve os recursos ao sistema antes de o módulo ser removido. A definição da função é: static void exit cleanup_function (void) { /* Cleanupcodehere*/ } module_exit (cleanup_function); A função de remoção não devolve qualquer valor. O token exit indica que o código só é usado para remover o módulo. A macro module_exit indica ao kernel a localização da função de remoção.

24 Inicializar e desinstalar um módulo m Gestão de erros durante a inicialização O registo das facilidades no kernel pode falhar. Assim, o módulo deve verificar sempre os valores devolvidos, para saber se as operações requisitadas tiveram sucesso. Mesmo que ocorra um erro, o módulo deve disponibilizar as facilidades que lhe for possível. Se o módulo não puder ser carregado, deve anularse os registos efectuadas antes da falha. Para implementar a recuperação de erros é comum usar a instrução goto.

25 Inicializar e desinstalar um módulo m Gestão de erros durante a inicialização O código seguinte funciona correctamente se a inicialização falhar em alguma posição: int init my_init_function (void) { int err; /* registration takes a pointer and a name */ err = register_this(ptr1, "skull"); if (err) goto fail_this; err = register_that(ptr2, "skull"); if (err) goto fail_that; err = register_those(ptr3, "skull"); if (err) goto fail_those; return 0; /* success */ fail_those: unregister_that(ptr2, "skull"); fail_that: unregister_this(ptr1, "skull"); fail_this: return err; /* propagate the error */ }

26 Inicializar e desinstalar um módulo m Gestão de erros durante a inicialização Outra alternativa, que não requer instruções goto, consiste em saber o que foi registado até ao momento actual e chamar a função de remoção quando ocorrer um erro. O valor devolvido por my_init_function, err, é um código de erro. No Linux, os códigos de erro são números negativos definidos em <linux/errno.h>. A função de remoção dum módulo deve anular todos os registos efectuados pela função de inicialização: void exit my_cleanup_function (void) { unregister_those (ptr3, "skull"); unregister_that (ptr2, "skull"); unregister_this (ptr1, "skull"); return; }

27 Inicializar e desinstalar um módulo m Conflitos ao carregar módulos Deve terse em atenção que outras partes podem começar a utilizar as facilidades imediatamente após a conclusão do registo. Não se deve registar uma facilidade antes que toda a inicialização necessária ao seu funcionamento esteja concluída. Se a função de inicialização falhar, mas alguma parte já estiver a utilizar uma facilidade registada, não se deve anular a inicialização.

28 Módulos com parâmetros Alguns dos parâmetros necessários a um driver podem variar de sistema para sistema. Os valores dos parâmetros pode ser definidos na fase de carregar por insmod ou modprobe. Para demonstrar esta possibilidade, pode usarse a versão alterada do módulo Hello World o módulo hellop dos exemplos do livro LDD3. Neste exemplo foram adicionados 2 parâmetros: um valor inteiro (howmany) e uma string de caracteres (whom). Quando se carrega hellop, é enviada uma mensagem a whom howmany vezes. Este módulo é carregado com uma linha de comandos como: insmod hellop howmany=10 whom="mom" Antes que insmod possa alterar os parâmetros do módulo, o módulo tem que os disponibilizar.

29 Módulos com parâmetros Os parâmetros são declarados com a macro module_param, definida em moduleparam.h. module_param possui 3 parâmetros: o nome da variável, o seu tipo e uma máscara de permissões. hellop declara os seus parâmetros e disponibilizaos a insmod com seguinte código: static char *whom = "world"; static int howmany = 1; module_param(howmany, int, S_IRUGO); module_param(whom, charp, S_IRUGO); Os parâmetros dum módulo pode ser de inúmeros tipos: bool, invbool, charp, int, long, short, uint, ulong, ushort.

30 Módulos com parâmetros Também é permitido carregar módulos com parâmetros do tipo array, em que os valores são fornecidos com uma lista separada por vírgulas. Para declarar um parâmetros do tipo array usase: module_param_array (name, type, num, perm); O último campo de module_param/module_param_array é uma permissão. As alternativas possíveis neste campo encontramse em <linux/stat.h>. Exemplos: S_IRUGO define um parâmetro que pode ser lido de fora mas não pode ser alterado. S_IRUGO S_IWUSR permite que a root altere o parâmetro.

31 Drivers que funcionam no espaço o do utilizador Algumas das limitações de um driver em modo do utilizador são: As interrupções não estão disponíveis no espaço do utilizador. O acesso directo à memória só é possível fazendo mmapping de /dev/mem, e apenas um utilizador privilegiado o pode fazer. O acesso a portas de I/O só está disponível após evocar ioperm ou iopl. Nem todas as plataformas suportam estas chamadas ao sistema, ficando o acesso a /dev/port bastante lento. O tempo de resposta é elevado. Pior, se o driver tiver sido mudado para disco, o tempo de resposta é inaceitavelmente elevado.