5. Parte da camada de emulação -MI do Linux®

Esta seção fala sobre parte independente de máquina do Linuxulator. Ele cobre a infra-estrutura de emulação necessária para a emulação do Linux® 2.6, a implementação do TLS (thread local storage) (no i386) e os futexes. Então falamos brevemente sobre algumas syscalls.

5.1. Descrição do NPTL

Uma das principais áreas de progresso no desenvolvimento do Linux® 2.6 foi o threading. Antes do 2.6, o suporte ao threading Linux® era implementado na biblioteca linuxthreads. A biblioteca foi uma implementação parcial do threading POSIX®. A segmentação foi implementada usando processos separados para cada threading usando a syscall clone para permitir que eles compartilhem o espaço de endereço (e outras coisas). A principal fraqueza desta abordagem era que cada thread tinha um PID diferente, o tratamento de sinal era quebrado (da perspectiva pthreads), etc. O desempenho também não era muito bom (uso de sinais SIGUSR para sincronização de threads) , consumo de recursos do kernel, etc.) para superar esses problemas, um novo sistema de threading foi desenvolvido e denominado NPTL.

A biblioteca NPTL focou em duas coisas, mas uma terceira coisa apareceu, então é normalmente considerada parte do NPTL. Essas duas coisas eram a incorporação de threads em uma estrutura de processo e futexes. A terceira coisa adicional foi o TLS, que não é diretamente exigido pelo NPTL, mas toda a biblioteca de usuário do NPTL depende dele. Essas melhorias resultaram em muito melhor desempenho e conformidade com os padrões. O NPTL é uma biblioteca de threading padrão nos sistemas Linux® atualmente.

A implementação do FreeBSD Linuxulator se aproxima do NPTL em três áreas principais. O TLS, futexes e PID mangling, que serve para simular as threadings Linux®. Outras seções descrevem cada uma dessas áreas.

5.2. Infra-estrutura de emulação do Linux® 2.6

Estas seções tratam da maneira como as threadings Linux® são gerenciadas e como nós simulamos isso no FreeBSD.

5.2.1. Determinação de tempo de execução de emulação 2.6

A camada de emulação do Linux® no FreeBSD suporta a configuração de tempo de execução da versão emulada. Isso é feito via sysctl(8), a saber compat.linux.osrelease. A configuração dessa sysctl(8) afeta o comportamento de tempo de execução da camada de emulação. Quando definido como 2.6.x, ele configura o valor de linux_use_linux26 enquanto a configuração para algo mais o mantém não definido. Essa variável (mais variáveis por prisão do mesmo tipo) determina se a infraestrutura 2.6 (principalmente o PID) é usada no código ou não. A configuração da versão é feita em todo o sistema e isso afeta todos os processos Linux®. A sysctl(8) não deve ser alterada ao executar qualquer binário do Linux®, pois pode causar danos .

5.2.2. Processos e identificadores de threading Linux®

A semântica de threading Linux® é um pouco confusa e usa uma nomenclatura inteiramente diferente do FreeBSD. Um processo em Linux® consiste em uma struct task incorporando dois campos identificadores - PID e TGID. O PID não é um ID de processo, mas é um ID de thread. O TGID identifica um grupo de threads em outras palavras, um processo. Para o processo single-threaded, o PID é igual ao TGID.

A thread no NPTL é apenas um processo comum que acontece de ter TGID diferente de PID e ter um líder de grupo diferente de si mesmo (e VM compartilhada, é claro). Tudo o mais acontece da mesma maneira que em um processo comum. Não há separação de um status compartilhado para alguma estrutura externa como no FreeBSD. Isso cria alguma duplicação de informações e possível inconsistência de dados. O kernel Linux® parece usar a tarefa -> grupo de informações em alguns lugares e informações de tarefas em outros lugares e isso não é muito consistente e parece propenso a erros.

Cada threading NPTL é criada por uma chamada a syscall clone com um conjunto específico de flags (mais na próxima subseção). O NPTL implementa segmentação rígida de 1:1.

No FreeBSD nós emulamos threads NPTL com processos comuns do FreeBSD que compartilham espaço de VM, etc. e a ginástica PID é apenas imitada na estrutura específica de emulação anexada ao processo. A estrutura anexada ao processo se parece com:

struct linux_emuldata {
  pid_t pid;

  int *child_set_tid; /* in clone(): Child.s TID to set on clone */
  int *child_clear_tid;/* in clone(): Child.s TID to clear on exit */

  struct linux_emuldata_shared *shared;

  int pdeath_signal; /* parent death signal */

  LIST_ENTRY(linux_emuldata) threads; /* list of linux threads */
};

O PID é usado para identificar o processo do FreeBSD que liga esta estrutura. child_se_tid e child_clear_tid são usadas para cópia do endereço TID quando um processo existe e é criado. O ponteiro shared aponta para uma estrutura compartilhada entre as threads. A variável pdeath_signal identifica o sinal de morte do processo pai e o ponteiro threads é usado para vincular essa estrutura à lista de threads. A estrutura linux_emuldata_shared se parece com:

struct linux_emuldata_shared {

  int refs;

  pid_t group_pid;

  LIST_HEAD(, linux_emuldata) threads; /* head of list of linux threads */
};

O refs é um contador de referência sendo usado para determinar quando podemos liberar a estrutura para evitar vazamentos de memória. O group_pid é para identificar o PID (=TGID) de todo o processo (=grupo de threads). O ponteiro threads é o cabeçalho da lista de threading no processo.

A estrutura linux_emuldata pode ser obtida a partir do processo usando em_find. O protótipo da função é:

struct linux_emuldata * em_find (struct proc *, int bloqueado);

Aqui, proc é o processo em que queremos a estrutura emuldata e o parâmetro locked determina se queremos ou não bloquear. Os valores aceitos são EMUL_DOLOCK e EMUL_DOUNLOCK. Mais sobre o bloqueio mais tarde.

5.2.3. Maqueando PID

Por causa da visão diferente descrita sabendo o que é um ID de processo e ID de thread entre o FreeBSD e o Linux® nós temos que traduzir a view de alguma forma. Nós fazemos isso pelo manuseio do PID. Isto significa que nós falsificamos o que um PID (=TGID) e um TID (=PID) é entre o kernel e o userland. A regra é que no kernel (no Linuxulator) PID=PID e TGID=grupo de id -> compartilhado e para userland nós apresentamos PID=shared -> group_pid e TID=proc -> p_pid. O membro PID da estrutura linux_emuldata é um PID do FreeBSD.

O acima afeta principalmente syscalls getyscl, getppid, gettid. Onde usamos PID/TGID, respectivamente. Em cópia de TIDs em child_clear_tid e child_set_tid copiamos o PID FreeBSD.

5.2.4. syscall Clone

A syscall clone é o modo como as threads são criadas no Linux®. O protótipo syscall é assim:

int linux_clone(l_int flags, void *stack, void *parent_tidptr, int dummy,
void * child_tidptr);

O parâmetro flags informa a syscall como exatamente os processos devem ser clonados. Como descrito acima, o Linux® pode criar processos compartilhando várias coisas independentemente, por exemplo, dois processos podem compartilhar file descriptors, mas não VM, etc. Ultimo byte do parametro flags é o sinal de saída do processo recém-criado. O parâmetro stack se não NULL diz, onde está a pilha de threading e se é NULL nós devemos copiar-na-escrita chamando a pilha de processos (isto é, faz a rotina normal de fork(2)). O parâmetro parent_tidptr é usado como um endereço para copiar o PID do processo (ou seja, o id do thread), uma vez que o processo esteja suficientemente instanciado, mas ainda não seja executável. O parâmetro dummy está aqui devido à convenção de chamada muito estranha desta syscall em i386. Ele usa os registradores diretamente e não deixa o compilador fazer o que resulta na necessidade de uma syscall falsa. O parâmetro child_tidptr é usado como um endereço para copiar o PID assim que o processo terminar de bifurcar e quando o processo terminar.

O syscall prossegue definindo flags correspondentes dependendo dos flags passadas. Por exemplo, mapas CLONE_VM para RFMEM (compartilhamento de VM), etc. O único nit aqui é CLONE_FS e CLONE_FILES porque o FreeBSD não permite configurar isso separadamente, então nós o falsificamos não configurando RFFDG (copiando a tabela fd e outras informações fs) se qualquer uma delas estiver definida. Isso não causa nenhum problema, porque essas flags são sempre definidas juntas. Depois de definir as flags, o processo é bifurcado usando a rotina fork1 interna, o processo é instrumentado para não ser colocado em uma fila de execução, ou seja, não deve ser definido como executável. Depois que a bifurcação é feita, possivelmente reparamos o processo recém-criado para emular a semântica CLONE_PARENT. A próxima parte está criando os dados de emulação. Threads no Linux® não sinalizam seus processos pais, então nós definimos o sinal de saída como 0 para desabilitar isso. Depois que a configuração de child_set_tid e child_clear_tid é executada, habilitando a funcionalidade posteriormente no código. Neste ponto, copiamos o PID para o endereço especificado por parent_tidptr. A configuração da pilha de processos é feita simplesmente reescrevendo o registro do quadro de linha % esp (% rsp no amd64). A próxima parte é configurar o TLS para o processo recém-criado. Depois disso, a semântica vfork(2) pode ser emulada e, finalmente, o processo recém-criado é colocado em uma fila de execução e copiando seu PID para o processo pai através do valor de retorno clone é feito.

A syscall clone é capaz e de fato é usado para emulação de syscalls fork() e vfork(2). O glibc mais novo em um caso de kernel 2.6 usa o clone para implementar syscalls fork(2) e vfork(2).

5.2.5. Bloqueio

O bloqueio é implementado como per-subsystem porque não esperamos muita disputa sobre eles. Existem dois bloqueios: emul_lock usado para proteger a manipulação de linux_emuldata e emul_shared_lock usado para manipular linux_emuldata_shared. O emul_lock é um mutex bloqueador não tolerável, enquanto emul_shared_lock é um bloqueio travável sx_lock. Devido ao bloqueio por subsistema, podemos unir alguns bloqueios e é por isso que o em-find oferece o acesso sem bloqueio.

5.3. TLS

Esta seção trata do TLS também conhecido como armazenamento local de thread.

5.3.1. Introdução ao threading

Threads na ciência da computação são entidades com um processo que podem ser agendados independentemente de qualquer outro. As threads nos processos compartilham amplos dados de processos (file descriptors, etc.) mas também tem sua prŕopria pilha para seus próprios dados. Algumas vezes é preciso para um processamento amplo de dados dado uma thread. Imagine um nome de uma thread algo assim. A tradicional API de threading do UNIX®, pthreads prove um caminho para isso em pthread_key_create(3), pthread_setspecific(3) and pthread_getspecific(3) onde a thread pode criar uma chave para os dados da thread local pthread_getspecific(3) ou pthread_getspecific(3) para manipular esses dados. Você pode ver que esse não é o caminho mais confortavel que poderia ser usado. Então varios produtores de compiladores C/C++ introduziram um caminho melhor. Eles definiram uma nova chave modificadora de thread que especifica que a variavel é especifica de uma thread. Um novo método de acessar as variaveis foi desenvolvio como (ao menos no i386). O método pthreads tende a ser implementado no espaço de usuário como uma tabela de lookup trivial. A performance como uma solução não é muito boa. Então o novo método (no i386) registradores de segmentos para endereçar um segmento, onde a área do TLS é armazenada, então o atual acesso da variável de uma thread é apenas adicionada ao registrador de segmentos para o endereçamento via it. Os registradores de segmentos são usualmente %gs e %fs agindo como seletores de segmento. Toda thread tem sua própria área onde os dados da thread local são armazenados e o segmento deve ser carregado em toda troca de contexto. Esse método é muito rapido e usado em todo mundo em volta do UNIX® i386. Ambos FreeBSD e Linux® Implementam sua abordagem e seus resultados tem sido muito bons. Unico ponto negativo é ter que recarregar o segmento em toda troca de contexto que pode deixar o processo lento. FreeBSD tenta evitar essa sobrecarga usando apenas 1 descritor de segmento enquanto Linux® usa 3. Interessante que isso quase nunca usa mais que 1 descritor (apenas o Wine parece usar 2) então o Linux® paga esse preço desnecessário na troca de contexto.

5.3.2. Segmentos em i386

A arquitetura i386 implementa os então chamados segmentos.Um segmento é uma descrição de um espaço na memória. A base de endereço (baixa) na area da memória, o fim disso (teto), tipo, proteção, etc. A memória descrita por um segmento pode ser acessada usando um seletor de segmento (%cs, %ds, %ss, %es, %fs, %gs). Por exemplo, deixe nos supor que temos um segmento com base no endereço 0x1234 e comprimento e esse codigo:

mov %edx,%gs:0x10

Isso carregará o conteúdo do registro % edx na localização da memória 0x1244. Alguns registradores de segmento têm um uso especial, por exemplo % cs é usado para segmento de código e % ss é usado para o segmento de pilha, mas % fs e % gs geralmente não são usados. Os segmentos são armazenados em uma tabela GDT global ou em uma tabela LDT local. O LDT é acessado por meio de uma entrada no GDT. O LDT pode armazenar mais tipos de segmentos. LDT pode ser por processo. Ambas as tabelas definem até 8191 entradas.

5.3.3. Implementação no Linux® i386

Existem duas maneiras principais de configurar o TLS no Linux®. Pode ser definido ao clonar um processo usando a syscall clone ou ele pode chamar set_thread_area. Quando um processo passa a flag CLONE_SETTLS para clone, o kernel espera que a memória apontada pelo registrador % esi uma representação Linux® do espaço do usuário de um segmento, que é traduzido para a representação da máquina de um segmento e carregado em um slot GDT. O slot GDT pode ser especificado com um número ou -1 pode ser usado, o que significa que o próprio sistema deve escolher o primeiro slot livre. Na prática, a grande maioria dos programas usa apenas uma entrada de TLS e não se importa com o número da entrada. Nós exploramos isso na emulação e dependemos disso.

5.3.4. Emulação de TLS do Linux®

5.3.4.1. i386

O carregamento de TLS para o segmento atual acontece chamando set_thread_area enquanto o TLS é carregado para um segundo processo em clone é feito no bloco separado em clone. Essas duas funções são muito semelhantes. A única diferença é o carregamento real do segmento GDT, que acontece na próxima troca de contexto para o processo recém-criado, enquanto set_thread_area deve carregar isso diretamente. O código basicamente faz isso. Ele copia o descritor de segmento de formulário Linux® da área de usuário. O código verifica o número do descritor, mas como isso difere entre o FreeBSD e o Linux®, maquiamos um pouco. Nós suportamos apenas índices de 6, 3 e -1. O número 6 é genuíno do Linux®, 3 é genuíno do FreeBSD one e -1 significa uma auto seleção. Em seguida, definimos o número do descritor como constante 3 e copiamos isso para o espaço do usuário. Contamos com o processo em espaço de usuário usando o número do descritor, mas isso funciona na maior parte do tempo (nunca vi um caso em que isso não funcionou), como o processo em espaço de usuário normalmente passa em 1. Então, convertemos o descritor da classe do Linux® para um formulário dependente da máquina (isto é, independente do sistema operacional) e copie isto para o descritor de segmento definido pelo FreeBSD. Finalmente podemos carregá-lo. Atribuímos o descritor às threads PCB (bloco de controle de processo) e carregamos o segmento % gs usando load_gs. Este carregamento deve ser feito em uma seção crítica para que nada possa nos interromper. O caso CLONE_SETTLS funciona exatamente como este, apenas o carregamento usando load_gs não é executado. O segmento usado para isso (segmento número 3) é compartilhado para este uso entre os processos do FreeBSD e do Linux® para que a camada de emulação Linux® não adicione nenhuma sobrecarga sobre o FreeBSD.

5.3.4.2. amd64

A implementação do amd64 é semelhante à do i386, mas inicialmente não havia um descritor de segmento de 32 bits usado para esse propósito (por isso nem usuários nativos de TLB de 32 bits trabalhavam), então tivemos que adicionar esse segmento e implementar seu carregamento em cada troca de contexto (quando a flag sinalizando uso de 32 bits está definida). Além disso, o carregamento de TLS é exatamente o mesmo, apenas os números de segmento são diferentes e o formato do descritor e o carregamento diferem ligeiramente.

5.4. Futexes

5.4.1. Introdução à sincronização

Threads precisam de algum tipo de sincronização e POSIX® fornece alguns deles: mutexes para exclusão mútua, bloqueios de leitura/gravação para exclusão mútua com relação de polarização de leituras e gravações e variáveis de condição para sinalizar um mudança de status. É interessante observar que a API de thread POSIX® não tem suporte para semáforos. Essas implementações de rotinas de sincronização são altamente dependentes do tipo de suporte a threading que temos. No modelo puro 1:M (espaço de usuário), a implementação pode ser feita apenas no espaço do usuário e, portanto, ser muito rápida (as variáveis de condição provavelmente serão implementadas usando sinais, ou seja, não rápido) e simples. No modelo 1:1, a situação também é bastante clara - as threading devem ser sincronizadas usando as facilidades do kernel (o que é muito lento porque uma syscall deve ser executada). O cenário M:N misto combina apenas a primeira e a segunda abordagem ou depende apenas do kernel. A sincronização de threads é uma parte vital da programação ativada por threads e seu desempenho pode afetar muito o programa resultante. Benchmarks recentes no sistema operacional FreeBSD mostraram que uma implementação sx_lock melhorada gerou 40% de aceleração no ZFS (um usuário sx pesado), isso é algo in-kernel, mas mostra claramente quão importante é o desempenho das primitivas de sincronização. .

Os programas em threading devem ser escritos com o mínimo de contenção possível em bloqueios. Caso contrário, em vez de fazer um trabalho útil, a threading apenas espera em um bloqueio. Devido a isso, os programas encadeados mais bem escritos mostram pouca contenção de bloqueios.

5.4.2. Introdução a Futexes

O Linux® implementa a segmentação 1:1, ou seja, tem de utilizar primitivas de sincronização no kernel. Como afirmado anteriormente, programas encadeados bem escritos possuem pouca contenção de bloqueio. Assim, uma sequência típica poderia ser executada como dois contador de referência de mutex de aumento/redução atômico, que é muito rápido, conforme apresentado pelo exemplo a seguir:

pthread_mutex_lock(&mutex);
....
pthread_mutex_unlock(&mutex);

O threading 1:1 nos força a executar dois syscalls para as chamadas mutex, o que é muito lento.

A solução que o Linux® 2.6 implementa é chamada de futexes. Futexes implementam a verificação de contenção no espaço do usuário e chama primitivas do kernel apenas em um caso de contenção. Assim, o caso típico ocorre sem qualquer intervenção do kernel. Isso produz uma implementação de primitivas de sincronização razoavelmente rápida e flexível.

5.4.3. API do Futex

A syscall do futex é assim:

int futex(void *uaddr, int op, int val, struct timespec *timeout, void *uaddr2, int val3);

Neste exemplo uaddr é um endereço do mutex no espaço do usuário, op é uma operação que estamos prestes a executar e os outros parâmetros têm significado por operação.

Futexes implementam as seguintes operações:

  • FUTEX_WAIT

  • FUTEX_WAKE

  • FUTEX_FD

  • FUTEX_REQUEUE

  • FUTEX_CMP_REQUEUE

  • FUTEX_WAKE_OP

5.4.3.1. FUTEX_WAIT

Esta operação verifica que no endereço uaddr o valor val é gravado. Se não, EWOULDBLOCK é retornado, caso contrário, a thread é enfileirada no futex e é suspensa. Se o argumento timeout for diferente de zero, ele especificará o tempo máximo para a suspensão, caso contrário, a suspensão será infinita.

5.4.3.2. FUTEX_WAKE

Esta operação tem um futex em uaddr e acorda os primeiros futexes val enfileirados neste futex.

5.4.3.3. FUTEX_FD

Esta operação associa um descritor de arquivo com um determinado futex.

5.4.3.4. FUTEX_REQUEUE

Esta operação pega threads val enfileirados no futex em uaddr, acorda-os e pega as próximas threads val2 e enfileira-os no futex em uaddr2.

5.4.3.5. FUTEX_CMP_REQUEUE

Essa operação faz o mesmo que FUTEX_REQUEUE, mas verifica se val3 é igual a val primeiro.

5.4.3.6. FUTEX_WAKE_OP

Esta operação executa uma operação atômica em val3 (que contém algum outro valor codificado) e uaddr. Então, ele acorda threads val em futex em uaddr e se a operação atômica retornar um número positivo, ele ativa os threadings val2 em futex em uaddr2.

As operações implementadas em FUTEX_WAKE_OP:

  • FUTEX_OP_SET

  • FUTEX_OP_ADD

  • FUTEX_OP_OR

  • FUTEX_OP_AND

  • FUTEX_OP_XOR

Nota:

Não existe um parâmetro val2 no protótipo do futex. O val2 é obtido do parâmetro struct timespec *timeout para as operações FUTEX_REQUEUE, FUTEX_CMP_REQUEUE e FUTEX_WAKE_OP.

5.4.4. Emulação de Futex no FreeBSD

A emulação de futex no FreeBSD é retirada do NetBSD e posteriormente estendida por nós. Ele é colocado nos arquivos linux_futex.c e linux_futex.h. A estrutura futex se parece com:

struct futex {
  void *f_uaddr;
  int f_refcount;

  LIST_ENTRY(futex) f_list;

  TAILQ_HEAD(lf_waiting_paroc, waiting_proc) f_waiting_proc;
};

E a estrutura waiting_proc é:

struct waiting_proc {

  struct thread *wp_t;

  struct futex *wp_new_futex;

  TAILQ_ENTRY(waiting_proc) wp_list;
};
5.4.4.1. futex_get / futex_put

Um futex é obtido usando a função futex_get, que busca uma lista linear de futexes e retorna o encontrado ou cria um novo futex. Ao liberar um futex do uso, chamamos a função futex_put, que diminui um contador de referência do futex e, se o refcount chegar a zero, ele é liberado.

5.4.4.2. futex_sleep

Quando um futex enfileira uma thread para dormir, ele cria uma estrutura working_proc e coloca essa estrutura na lista dentro da estrutura do futex, então apenas executa um tsleep(9) para suspender a threading. O sleep pode ser expirado. Depois de tsleep(9) retornar (a thread foi acordada ou expirou) a estrutura working_proc é removida da lista e é destruído. Tudo isso é feito na função futex_sleep. Se nós formos acordados de futex_wake nós temos wp_new_futex setado então nós dormimos nele. Desta forma, um novo enfileiramento é feito nesta função.

5.4.4.3. futex_wake

Acordar uma thread em sleep em uma futex é performado na função futex_wake. Primeiro nesta função nós imitamos o comportamento estranho do Linux®, onde ele acorda N threads para todas as operações, a única exceção é que as operações REQUEUE são executadas em threads N+1. Mas isso geralmente não faz diferença, pois estamos acordando todos as threads. Em seguida na função no loop nós acordamos n threads, depois disso nós checamos se existe um novo futex para requeuering. Se assim for, nós enfileiramos novamente até n2 threads no novo futex. Isso coopera com o futex_sleep.

5.4.4.4. futex_wake_op

A operação FUTEX_WAKE_OP é bastante complicada. Primeiro nós obtemos dois futexes nos endereços uaddr e uaddr2 e então executamos a operação atômica usando val3 e uaddr2. Então os waiters val no primeiro futex são acordados e se a condição de operação atômica se mantém, nós acordamos o waiter val2 (ex timeout) no segundo futex.

5.4.4.5. operação atômica futex

A operação atômica usa dois parâmetros encoded_op e uaddr. A operação codificada, codifica a operação em si, comparando valor, argumento de operação e argumento de comparação. O pseudocódigo da operação é como este:

oldval = *uaddr2
*uaddr2 = oldval OP oparg

E isso é feito atomicamente. Primeiro, uma cópia do número em uaddr é executada e a operação é concluída. O código manipula falhas de página e, se nenhuma falha de página ocorrer, oldval é comparado ao argumento cmparg com o comparador cmp.

5.4.4.6. Bloqueio Futex

A implementação do Futex usa duas listas de lock que protegndo sx_lock e locks globais (Giant ou outra sx_lock). Cada operação é executada bloqueada desde o início até o final.

5.5. Implementação de várias syscalls

Nesta seção, descreverei algumas syscalls menores que merecem destaque, pois sua implementação não é óbvia ou as syscalls são interessantes de outro ponto de vista.

5.5.1. *na família de syscalls

Durante o desenvolvimento do kernel 2.6.16 do Linux®, os *at syscalls foram adicionados. Essas syscalls (openat, por exemplo) funcionam exatamente como suas contrapartes sem-menos, com a pequena exceção do parâmetro dirfd. Este parâmetro muda onde o arquivo dado, no qual a syscall deve ser executado, está. Quando o parâmetro filename é absoluto dirfd é ignorado, mas quando o caminho para o arquivo é relativo, ele é checado. O parâmetro dirfd é um diretório relativo ao qual o nome do caminho relativo é verificado. O parâmetro dirfd é um file descriptor de algum diretório ou AT_FDCWD. Então, por exemplo, a syscall openat pode ser assim:

file descriptor 123 = /tmp/foo/, current working directory = /tmp/

openat(123, /tmp/bah\, flags, mode)	/* opens /tmp/bah */
openat(123, bah\, flags, mode)		/* opens /tmp/foo/bah */
openat(AT_FDWCWD, bah\, flags, mode)	/* opens /tmp/bah */
openat(stdio, bah\, flags, mode)	/* returns error because stdio is not a directory */

Esta infra-estrutura é necessária para evitar corridas ao abrir arquivos fora do diretório de trabalho. Imagine que um processo consiste em duas threads, thread A e thread B. Thread A emite open (./tmp/foo/bah., Flags, mode) e antes de retornar ele se antecipa e a thread B é executada. A thread B não se preocupa com as necessidades da thread A e renomeia ou remove o /tmp/foo/. Nós temos uma corrida. Para evitar isso, podemos abrir o /tmp/foo e usá-lo como dirfd para a syscall openat. Isso também permite que o usuário implemente diretórios de trabalho por thread.

A família do Linux® de *at syscalls contém: linux_openat, linux_mkdirat, linux_mknodat, linux_fchownat, linux_futimesat, linux_fstatat64, linux_unlinkat, linux_renameat, linux_linkat , linux_symlinkat, linux_readlinkat, linux_fchmodat e linux_faccessat. Tudo isso é implementado usando a rotina modificada namei(9) e a simples camada de quebra automática.

5.5.1.1. Implementação

A implementação é feita alterando a rotina namei(9) (descrita acima) para obter o parâmetro adicional dirfd no sua estrutura nameidata , que especifica o ponto inicial da pesquisa do nome do caminho, em vez de usar o diretório de trabalho atual todas as vezes. A resolução de dirfd do número do file descriptor para um vnode é feita em *at syscalls nativo. Quando dirfd é AT_FDCWD, a entrada dvp na estrutura nameidata é NULL, mas dirfd é um número diferente, obtemos um arquivo para este file descriptor, verificamos se este arquivo é válido e se há vnode anexado a ele, então obtemos um vnode. Então nós verificamos este vnode por ser um diretório. Na rotina real namei(9) simplesmente substituímos a variável dvp vnode pela variável dp na função namei(9), que determina o ponto de partida. O namei(9) não é usado diretamente, mas através de um rastreamento de diferentes funções em vários níveis. Por exemplo, o openat é assim:

openat() --> kern_openat() --> vn_open() -> namei()

Por esse motivo, kern_open e vn_open devem ser alterados para incorporar o parâmetro dirfd adicional. Nenhuma camada de compatibilidade é criada para esses, porque não há muitos usuários disso e os usuários podem ser facilmente convertidos. Esta implementação geral permite ao FreeBSD implementar suas próprias *at syscalls. Isso está sendo discutido agora.

5.5.2. Ioctl

A interface ioctl é bastante frágil devido à sua generalidade. Nós temos que ter em mente que os dispositivos diferem entre Linux® e FreeBSD, então alguns cuidados devem ser aplicados para fazer o trabalho de emulação de ioctl corretamente. O manuseio ioctl é implementado em linux_ioctl.c, onde a função linux_ioctl é definida. Esta função simplesmente itera sobre conjuntos de manipuladores ioctl para encontrar um manipulador que implementa um dado comando. A syscall ioctl tem três parâmetros, o file descriptor, comando e um argumento. O comando é um número de 16 bits, que, em teoria, é dividido em alta classe determinante de 8 bits do comando ioctl e 8 bits baixos, que são o comando real dentro do conjunto dado. A emulação aproveita essa divisão. Implementamos manipuladores para cada conjunto, como sound_handler ou disk_handler. Cada manipulador tem um comando máximo e um comando mínimo definido, que é usado para determinar qual manipulador é usado. Existem pequenos problemas com esta abordagem porque Linux® não usa a divisão definida consistentemente, por isso as ioctls para um conjunto diferente estão dentro de um conjunto ao qual não devem pertencer (ioctls genéricos SCSI dentro do cdrom conjunto, etc.). O FreeBSD atualmente não implementa muitos ioctls do Linux® (comparado ao NetBSD, por exemplo), mas o plano é portar os do NetBSD. A tendência é usar o ioctls Linux® mesmo nos drivers nativos do FreeBSD, devido à fácil portabilidade dos aplicativos.

5.5.3. Depuração

Cada syscall deve ser debugável. Para isso, introduzimos uma pequena infra-estrutura. Nós temos o recurso ldebug, que informa se uma dada syscall deve ser depurada (configurável através de um sysctl). Para impressão, temos as macros LMSG e ARGS. Essas são usadas para alterar uma string imprimível para mensagens uniformes de depuração.

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>.