A melhor maneira de fazer o desenvolvimento do kernel é ter (pelo menos) dois computadores separados. Um deles conteria o ambiente de desenvolvimento e o código fonte, e o outro seria usado para testar o código recém escrito, inicializando por meio da rede e montando seu sistema de arquivo a partir do primeiro computador. Desta forma, se o novo código contiver erros e travar a máquina, isso não irá atrapalhar o código fonte (e nem nenhum outros dado “vivo”). O segundo sistema nem sequer requer um monitor adequado. Em vez disso, ele pode ser conectado por meio de um cabo serial ou KVM ao primeiro computador.
Mas, como nem todo mundo tem dois ou mais computadores à mão, há algumas coisas que podem ser feitas para preparar um sistema “vivo ” para desenvolver código para o kernel. Esta configuração também é aplicável para desenvolvimento em uma máquina virtual criada com o VMWare ou com o QEmu (a próxima melhor coisa depois de uma máquina de desenvolvimento dedicada).
Para qualquer programação do kernel, um kernel com a opção INVARIANTS
ativada é obrigatório. Então, digite estas linhas no seu arquivo de configuração do kernel:
options INVARIANT_SUPPORT options INVARIANTS
Para ter um maior nível de depuração, você também devrá incluir o suporte ao WITNESS, o qual irá alertá-lo sobre erros relacionados a bloqueios (locking):
options WITNESS_SUPPORT options WITNESS
Para depurar despejos de memória, é necessário um kernel com símbolos de depuração:
makeoptions DEBUG=-g
Com a maneira usual de instalar o kernel (make installkernel
) o kernel de depuração não será instalado automaticamente. Ele é chamado de kernel.debug
e fica localizado em /usr/obj/usr/src/sys/KERNELNAME/
. Por conveniência, deve ser copiado para /boot/kernel/
.
Outra conveniência é habilitar o depurador do kernel para que você possa examinar o panic do kernel quando isso acontece. Para isso, insira as seguintes linhas no seu arquivo de configuração do kernel:
options KDB options DDB options KDB_TRACE
Para que isso funcione, você pode precisar definir um sysctl (se ele não estiver ativado por padrão):
debug.debugger_on_panic=1
Kernel panics acontecerão, portanto, deve-se ter cuidado com o cache do sistema de arquivos. Em particular, ter o softupdates habilitado pode significar que a versão mais recente do arquivo pode ser perdida se um panic ocorrer antes de ser committed para armazenamento. Desativar o softupdates produz um grande impacto na performance e ainda não garante a consistência dos dados. A montagem do sistema de arquivos com a opção “sync” é necessária para isso. Para um compromisso, os atrasos do cache de softupdates podem ser encurtados. Existem três sysctl's que são úteis para isso (melhor ser configurado em /etc/sysctl.conf
):
kern.filedelay=5 kern.dirdelay=4 kern.metadelay=3
Os números representam segundos.
Para depurar os panics do kernel, os dumps do núcleo do kernel são necessários. Como um kernel panic pode tornar os sistemas de arquivos inutilizáveis, esse despejo de memória é primeiramente gravado em uma partição bruta. Normalmente, esta é a partição de swap. Essa partição deve ser pelo menos tão grande quanto a RAM física na máquina. Na próxima inicialização, o despejo é copiado para um arquivo normal. Isso acontece depois que os sistemas de arquivos são verificados e montados e antes que o swap seja ativado. Isto é controlado com duas variáveis /etc/rc.conf
:
dumpdev="/dev/ad0s4b" dumpdir="/usr/core
A variável dumpdev
especifica a partição de swap e dumpdir
informa ao sistema onde no sistema de arquivos ele deverá realocar o dump principal na reinicialização.
A gravação de core dumps é lenta e leva muito tempo, então se você tiver muita memória (>256M) e muitos panics, pode ser frustrante sentar e esperar enquanto isso é feito (duas vezes - primeiro para gravar para o swap, depois para realocá-lo para o sistema de arquivos). É conveniente limitar a quantidade de RAM que o sistema usará através de uma variável do /boot/loader.conf
:
hw.physmem="256M"
Se os panics são frequentes e os sistemas de arquivos são grandes (ou você simplesmente não confia em softupdates + background fsck), é aconselhável desligar o fsck em background através da variável /etc/rc.conf
:
background_fsck="NO"
Dessa forma, os sistemas de arquivos sempre serão verificados quando necessário. Observe que, com o fsck em segundo plano, um novo panic pode acontecer enquanto ele está verificando os discos. Novamente, a maneira mais segura é não ter muitos sistemas de arquivos locais, usando o outro computador como um servidor NFS.
Para o propósito de criar uma nova classe GEOM, um subdiretório vazio deve ser criado sob um diretório arbitrário acessível pelo usuário. Você não precisa criar o diretório do módulo em /usr/src
.
É uma boa prática criar Makefile
s para cada projeto de codificação não trivial, o que obviamente inclui módulos do kernel.
Criar o Makefile
é simples graças a um extenso conjunto de rotinas auxiliares fornecidas pelo sistema. Em suma, aqui está um exemplo de como um Makefile mínimo
para um módulo do kernel se parece:
SRCS=g_journal.c KMOD=geom_journal .include <bsd.kmod.mk>
Este Makefile
(com nomes de arquivos alterados) serve para qualquer módulo do kernel, e uma classe GEOM pode residir em apenas um módulo do kernel. Se mais de um arquivo for necessário, liste-o na variável SRCS
, separado com espaço em branco de outros nomes de arquivos.
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.