Veja o malloc(9). A alocação básica de memória é apenas ligeiramente diferente do seu userland equivalente. Mais notavelmente, malloc
() e free
() aceitam parâmetros adicionais conforme descrito na página do manual.
Um “malloc type” deve ser declarado na seção de declaração de um arquivo fonte, assim:
static MALLOC_DEFINE(M_GJOURNAL, "gjournal data", "GEOM_JOURNAL Data");
Para usar esta macro, os cabeçalhos sys/param.h
, sys/kernel.h
e sys/malloc.h
devem ser incluídos.
Existe outro mecanismo para alocar memória, o UMA (Universal Memory Allocator). Veja uma(9) para detalhes, mas ele é um tipo especial de alocador usado principalmente para alocação rápida de listas compostas de itens do mesmo tamanho (por exemplo, matrizes dinâmicas de estruturas).
Veja queue(3). Há MUITOS casos quando uma lista de coisas precisa ser mantida. Felizmente, essa estrutura de dados é implementada (de várias maneiras) por macros C incluídas no sistema. O tipo de lista mais usado é o TAILQ, porque é o mais flexível. É também aquele com os maiores requisitos de memória (seus elementos são duplamente vinculados) e também o mais lento (embora a variação de velocidade seja mais da ordem de várias instruções da CPU, portanto, ela não deve ser levada a sério).
Se a velocidade de recuperação de dados for muito importante, veja tree(3) e hashinit(9).
A estrutura bio
é usada para todas e quaisquer operações de Input/Output relativas ao GEOM. Ele basicamente contém informações sobre qual dispositivo ('provedor') deve satisfazer a solicitação, tipo de pedido, offset, comprimento, ponteiro para um buffer e um monte de sinalizadores “específicos do usuário” e campos que podem ajudar a implementar vários hacks.
O importante aqui é que os bio
s são tratados de forma assíncrona. Isso significa que, na maior parte do código, não há nenhum análogo as chamadas read(2) e write(2) que não retornam até que uma solicitação seja feita. Em vez disso, uma função fornecida pelo desenvolvedor é chamada como uma notificação quando a solicitação é concluída (ou resulta em erro).
O modelo de programação assíncrona (também chamado de “orientado a eventos”) é um pouco mais difícil do que o imperativo muito mais usado no userland (pelo menos leva um tempo para se acostumar com isso). Em alguns casos, as rotinas auxiliares g_write_data
() e g_read_data
() podem ser usadas, mas nem sempre. Em particular, elas não podem ser usadas quando um mutex é mantido; por exemplo, o mutex de topologia GEOM ou o mutex interno mantido durante as funções .start
() e .stop
().
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>.