Emulación Linux(R) en FreeBSD

El API común de UNIX® define llamadas al sistema como forma de ejecutar comandos en el kernel desde espacio de usuario. La implementación más habitual es utilizar una interrupción o una instrucción especializada (como las instrucciones SYSENTER/SYSCALL en ia32). Las llamadas al sistema se definen mediante un número. Por ejemplo en FreeBSD, la llamada al sistema número 85 es la llamada al sistema de swapon(2) y la llamada al sistema número 132 es mkfifo(2). Algunas llamadas al sistema necesitan parámetros, que son pasados desde espacio de usuario a espacio de kernel de varias formas (dependiendo de la implementación). Las llamadas al sistema son síncronas.

Otra forma posible de comunicarse es mediante un trap. Los traps (trampas) ocurren de forma asíncrona después de que ocurra algún evento (división por cero, fallo de página, etc.). Un trap puede ser transparente para un proceso (error de página) o puede resultar en una reacción como enviar una señal (división por cero).

Hay otras API (System V IPC, memoria compartida, etc.) pero la API más importante es la señal. Las señales son enviadas por procesos o por el kernel y recibidas por procesos. Algunas señales pueden ser ignoradas o manejadas por una rutina proporcionada por el usuario, otras dan como resultado una acción predefinida que no se puede alterar ni ignorar.

Las instancias del kernel se procesan las primeras en el sistema (llamado init). Cada proceso en ejecución puede crear una copia idéntica a sí mismo utilizando la llamada al sistema fork(2). Se han introducido algunas versiones ligeramente modificadas de esta llamada pero la semántica es básicamente la misma. Cada proceso en ejecución se puede convertir en otro proceso utilizando la llamada al sistema exec(3). Se han introducido algunas modificaciones a esta llamada pero todas tienen básicamente el mismo propósito. Los procesos terminan sus vidas invocando la llamada al sistema exit(2). Cada proceso se identifica por un número único llamado PID. Cada proceso tiene definido un padre (identificado por su PID).

Los UNIX® tradicionales no definen ni un API ni una implementación para hilos, mientras que POSIX® define un API para hilos pero la implementación no está definida. Tradicionalmente había dos formas de implementar hilos. Manejarlos como procesos separados (modelo 1:1) o envolver todo el grupo de hilos en un proceso y manejar los hilos en espacio de usuario (modelo 1:N). Comparando las características principales de cada aproximación:

Hilos 1: 1

Hilos 1: N

+ hilos ligeros + el usuario puede modificar fácilmente la planificación - las llamadas al sistema necesitan estar recubiertas - no puede utilizar más de una CPU

FreeBSD es una versión tradicional de UNIX® en el sentido en el que divide la ejecución de los procesos en dos mitades: espacio de kernel y ejecución en espacio de usuario. Hay dos tipos de entradas al kernel para los procesos: una llamada al sistema y un trap. Sólo hay una forma de volver. En las siguientes secciones se describirán las tres puertas desde/hacia el kernel. Toda la descripción aplica a la arquitectura i386 ya que el Linuxulator sólo existe ahí pero el concepto es similar para otras arquitecturas. La información se ha tomado de [1] y del código fuente.

Linux® sigue el esquema tradicional UNIX® de dividir la ejecución de un proceso en dos partes: espacio de kernel y espacio de usuario. Al kernel se puede entrar de dos formas: vía trap o vía llamada al sistema. La vuelta se maneja de una sola forma. La descripción que sigue aplica a Linux® 2.6 en la arquitectura i386™. La información se ha obtenido de [2].

Aportado por: Attilio Rao <attilio@FreeBSD.org>

El conjunto de primitivas de sincronización de FreeBSD se basa en la idea de suministrar un número bastante grande de primitivas diferentes de manera que se pueda utilizar la mejor para cada situación particular y apropiada.

Desde un punto de vista de alto nivel, puede considerar tres tipos de primitivas de sincronización en el kernel de FreeBSD:

A continuación hay descripciones de las 3 familias. Para cada bloqueo, deberías consultar la página de manual vinculada (cuando sea posible) para obtener explicaciones más detalladas.

Varias capas de emulación a veces requieren algunos datos adicionales por proceso. Puede administrar estructuras separadas (una lista, un árbol, etc.) que contienen estos datos para cada proceso, pero esto tiende a ser lento y consume memoria. Para solucionar este problema la estructura proc de FreeBSD contiene p_emuldata, que es un puntero vacío a algunos datos específicos de la capa de emulación. La entrada a este proc está protegida por el mutex proc.

La estructura proc de FreeBSD contiene una entrada p_sysent que identifica qué ABI está ejecutando este proceso. De hecho, es un puntero al sysentvec descrito arriba. Entonces, comparando este punto con la dirección donde se almacena la estructura sysentvec para la ABI dada podemos determinar si el proceso corresponde a nuestra capa de emulación. El código típicamente se parece a esto:

Como puedes ver, utilizamos el modificador __predict_true para colapsar el caso más común (proceso de FreeBSD) a una simple operación de retorno preservando así un alto rendimiento. Este código debería convertirse en una macro porque actualmente no es muy flexible, es decir no soportamos emulación Linux®64 o procesos Linux® A.OUT en i386.

El subsistema VFS de FreeBSD es muy complejo pero la capa de emulación de Linux® sólo usa una pequeña parte mediante una API bien definida. Puede operar con vnodes o con manejadores de ficheros. Vnode representa un nodo virtual, es decir es la representación de un nodo en VFS. Otra representación es un manejador de fichero que representa un fichero abierto desde la perspectiva de un proceso. Un manejador de fichero puede representar un socket o un fichero ordinario. Un manejador de fichero contiene un puntero a su vnode. Varios manejadores de fichero pueden apuntar al mismo vnode.

Linux® pasa los argumentos a las llamadas al sistema mediante registros (por eso está limitado a 6 parámetros en i386) mientras que FreeBSD utiliza la pila. La rutina prepsyscall de Linux® debe copiar los parámetros desde los registros a la pila. El orden de los registros es: %ebx, %ecx, %edx, %esi, %edi, %ebp. El truco es que esto es verdad sólo para la mayoría de las llamadas al sistema. Algunas (principalmente clone) utiliza un orden distinto pero se puede arreglar fácilmente introduciendo un parámetro dummy en el prototipo de linux_clone.

Cada llamada al sistema implementada en el Linuxulator debe tener su prototipo con varios flags en syscalls.master. La forma del archivo es:

La primera columna representa el número de llamada al sistema. La segunda columna es para proporcionar auditoría. La tercera columna representa el tipo de llamada al sistema. Es una de STD, OBSOL, NOPROTO o UNIMPL. STD es una llamada al sistema estándar con un prototipo e implementación completas. OBSOL es una llamada obsoleta que define sólo el prototipo. NOPROTO significa que la llamada al sistema está implementada en otro sitio así que no hay que añadir el prefijo del ABI, etc. UNIMPL significa que la llamada al sistema será sustituida por la llamada nosys (una llamada al sistema que tan sólo muestra un mensaje diciendo que la llamada no está implementada y que devuelve ENOSYS).

A partir de syscalls.master un script genera tres ficheros: linux_syscall.h, linux_proto.h y linux_sysent.c. linux_syscall.h contiene las definiciones de los nombres de las llamadas al sistema y sus valores numéricos, ejemplo:

linux_proto.h contiene definiciones de estructuras de argumentos de todas las llamadas al sistema, ejemplo:

Y finalmente, linux_sysent.c contiene una estructura que describe la tabla de entrada del sistema, utilizada para enviar una llamada al sistema, por ejemplo:

Como puedes ver linux_fork se implementa en el propio Linuxulator de modo que la definición de su tipo es STD y no tiene argumentos lo que se ve por la estructura de argumentos dummy. Por otro lado close es sólo un alias para la llamada close(2) real de FreeBSD de forma que no tiene una estructura de argumentos de linux asociada y en la tabla de entrada al sistema no tiene un prefijo "linux" ya que llama a la función close(2) real del kernel.

La capa de emulación de Linux® no es completa ya que algunas llamadas al sistema no están implementadas de forma adecuada y otras no están implementadas en absoluto. La capa de emulación utiliza un método para marcar las llamadas al sistema no implementadas con la macro DUMMY. Estas definiciones dummy se encuentran en linux_dummy.c en la forma DUMMY(syscall), que luego se traduce a varios ficheros auxiliares de llamadas al sistema y cuya implementación consiste en imprimir un mensaje diciendo que la llamada no está implementada. El prototipo UNIMPL no se utiliza porque queremos ser capaces de identificar el nombre de la llamada al sistema que fue invocada con el fin de saber qué llamadas al sistema son importantes de implementar.

Esta rutina comprueba primero si la señal se ha instalado con un SA_SIGINFO en cuyo caso llama en su lugar a la rutina linux_rt_sendsig. Además, asigna (o reutiliza uno existente) un contexto de manejador de señal ya existente, luego crea una lista de argumentos para el manejador de señal. Traduce el número de señal basado en la tabla de traducción de señales, asigna un manejador, traduce sigset. Luego guarda contexto para la rutina sigreturn (varios registros, número de trap traducido y máscara de señal). Finalmente, copia el contexto de la señal al espacio de usuario y prepara el contexto para que se ejecute el manejador de señal real.

Esta rutina es similar a linux_sendsig, sólo es diferente la preparación del contexto de la señal. Añade siginfo, ucontext y algunas partes POSIX®. Podría ser interesante considerar si esas dos funciones podrían fusionarse en una sola con el beneficio de una menor duplicación de código y una posible ejecución de código más rápida.

Esta llamada al sistema se utiliza para la devolución desde controlador de señales. Realiza algunas comprobaciones de seguridad y restaura el contexto del proceso original. También desenmascara la señal en la máscara de señal de proceso.

La capa de emulación de Linux® en FreeBSD soporta la configuración del entorno de ejecución de la versión emulada. Esto se hace vía sysctl(8), en concreto compat.linux.osrelease. Establecer esta sysctl(8) afecta al comportamiento del entorno de ejecución de la capa de emulación. Cuando se establece a 2.6.x se establece el valor de linux_use_linux26 mientras que si se establece a otra cosa no se pone nada. Esta variable (más las variables correspondientes del mismo tipo por cada jail) determinan qué infraestructura 2.6 (principalmente PID mangling) se usa o no en el código. El establecimiento de la versión se realiza en todo el sistema y afecta a todos los procesos Linux®. sysctl(8) no se debería cambiar cuando un binario Linux® se está ejecutando ya que podría romper algo.

Las semánticas de los hilos en Linux® son un poco confusas y utilizan una nomenclatura completamente diferente a la utilizada en FreeBSD. Un proceso en Linux® consiste en una struct task que contiene dos campos identificadores PID y TGID. PID no es el ID del proceso sino el ID del hilo. El TGID identifica a un grupo de hilos o en otras palabras, a un proceso. Para procesos monohilo el PID es igual al TGID.

El hilo en NPTL es tan sólo un proceso ordinario que resulta que tiene un TGID que no es igual al PID y que tiene un líder de grupo que no es él mismo (y VM compartida etc. por supuesto). Todo lo demás sucede de la misma forma que en un proceso ordinario. No hay separación entre un estado compartido y una estructura externa como en FreeBSD. Esto crea algo de información duplicada y una posible inconsistencia de datos. El kernel de Linux® aparentemente utiliza la información de task→group en algunos sitios y la información de la tarea en otros sitios y no es muy consistente y es propensa a errores.

Cada hilo NPTL se crea mediante una llamada a la llamada al sistema clone con un conjunto específico de flags (más en la siguiente subsección). La librería NPTL implementa un mecanismo de hilos estricto 1:1.

En FreeBSD emulamos hilos NPTL con procesos FreeBSD ordinarios que comparten espacio VM, etc. y la gimnasia que se hace con el PID simplemente se imita en la estructura específica de emulación adjunta al proceso. La estructura adjunta al proceso se ve así:

El PID se utiliza para identificar el proceso de FreeBSD que contiene esta estructura. Los campos child_se_tid y child_clear_tid se usan para hacer un copyout de la dirección del TID cuando un proceso sale y es creado. El puntero shared apunta a una estructura compartida entre los hilos. La variable pdeath_signal identifica la señal de morir del padre y el punto threads se utiliza para enlazar esta estructura a la lista de hilos. La estructura linux_emuldata_shared tiene este aspecto:

refs es un contador de referencias que se usa para determinar cuándo liberar la estructura para evitar pérdidas de memoria. group_id se usa para identificar el PID (=TGID) de todo el proceso (=grupo de hilos). El puntero threads es la cabecera de la lista de hilos en el proceso.

La estructura linux_emuldata se puede obtener a partir del proceso utilizando em_find. El prototipo de la función es:

Aquí, proc es el proceso del cual queremos la estructura emuldata y el parámetro locked determina si queremos o no bloquear. Los valores aceptados son EMUL_DOLOCK y EMUL_DOUNLOCK. Más acerca de esto después.

Puesto que hay una diferencia en la visión en cuanto a la idea de ID de proceso e ID de hilo entre FreeBSD y Linux® tenemos que traducir esa visión de algún modo. Lo hacemos modificando el PID. Esto significa que falseamos lo que son el PID (=TGID) y el TID (=PID) entre el kernel y el espacio de usuario. La regla básica es que en el kernel (en el Linuxulator) PID = PID y TGID = shared → group pid y que en espacio de usuario presentamos PID = shared → group_pid y TID = proc → p_pid. El miembro PID de la estructura linux_emuldata es un PID de FreeBSD.

Lo descrito arriba afecta principalmente a las llamadas al sistema getpid, getppid y gettid. Donde utilizamos PID/TGID respectivamente. Al hacer el copyout de los TID en child_clear_tid y child_set_tid copiamos hacia afuera el PID de FreeBSD.

La llamada al sistema clone es la forma en la que se crean hilos en Linux®. El prototipo de la llamada es como este:

El parámetro flags le dice a la llamada al sistema cómo se tiene que clonar el proceso exactamente. Como se ha descrito arriba, Linux® puede crear procesos compartiendo varias cosas de forma independiente, por ejemplo dos procesos pueden compartir descriptores de ficheros pero no VM, etc. El último byte del parámetro flags es la señal de salida del proceso recién creado. El parámetro stack si no es NULL indica dónde está la pila del hilo y si es NULL se supone que debemos hacer un copy-on-write de la pila del proceso que llama (es decir hacer lo que hace la rutina fork(2) normal). El parámetro parent_tidptr se usa como dirección para copiar hacia afuera el PID del proceso (es decir, el id del hilo) una vez que el proceso está suficientemente instanciado pero todavía no es ejecutable. El parámetro dummy está aquí por la convención de llamada tan extraña que tiene esta llamada al sistema en i386. Usa los registros directamente y deja que lo haga el compilador por lo que se necesita una llamada al sistema dummy. El parámetro child_tidptr se usa como dirección para copiar hacia afuera el PID una vez que el proceso ha terminado de crearse y cuando el proceso sale.

La llamada al sistema en sí procede estableciendo los flags correspondientes dependiendo de los flags que se le hayan pasado. Por ejemplo, CLONE_VM se corresponde con RFMEM (compartir VM), etc. El único detalle aquí son CLONE_FS y CLONE_FILES porque FreeBSD no permite establecerlos por separado por lo que lo falseamos al no establecer RFFDG (la copia de la tabla de descriptores de fichero y otra información de sistemas de ficheros) si alguno de los dos está definido. Esto no causa problemas porque esos dos flags siempre se establecen juntos. Después de establecer los flags el proceso se bifurca utilizando la rutina interna fork1, se insta a que el proceso no sea puesto en una cola de ejecución, es decir no se establece como ejecutable. Después de terminar el bifurcado posiblemente establezcamos el padre al nuevo proceso creado para emular la semántica de CLONE_PARENT. La siguiente parte es crear los datos de emulación. Los hilos en Linux® no señalizan a sus padres de forma que establecemos la señal exit a 0 para desabilitar esto. Después se establecen child_set_tid y child_clear_tid activando esta funcionalidad posteriormente en el código. En este punto copiamos el PID hacia afuera en la dirección especificada por parent_tidptr. La configuración de la pila del proceso se realiza simplemente reescribiendo el registro de marco de hilo %esp (%rsp en amd64). La siguiente parte es configurar TLS para el proceso recién creado. Después de esto ya se pueden emular las semánticas de vfork(2) y finalmente el proceso creado se pone en una cola de ejecución y se copia su PID en el proceso padre mediante el valor de retorno de clone.

La llamada al sistema clone es capaz y de hecho se usa para emular las llamadas al sistema clásicas fork(2) y vfork(2). Versiones nuevas de glibc funcionando con kernels 2.6 usan clone para implementar las llamadas a fork(2) y vfork(2).

El mecanismo de bloqueo se implementa por cada subsistema porque no esperamos en ellos mucha contención. Hay dos locks: emul_lock se usa para manipular de forma segura linux_emuldata y emul_shared_lock se usa para manipular linux_emuldata_shared. emul_lcok es un mutex con el que no se puede dormir mientras que emul_shared_lock es un sx_lock con el que se puede dormir. Debido al mecanismo de bloqueo por subsistema podemos juntar algunos locks y por eso em_find proporciona acceso sin necesidad de bloqueos.

Los hilos en ciencias de la computación son entidades en un proceso que pueden ser planificadas de forma independiente al resto de hilos. Los hilos de un proceso comparten muchos datos del proceso (descriptores de fichero, etc) pero también tienen su propia pila para sus propios datos. Algunas veces hay necesidad para tener datos de nivel de proceso pero específicos para un determinado hilo. Imagina el nombre de un hilo en ejecución o algo así. El API de hilos tradicional de UNIX®, pthreads proporciona un método para hacerlo mediante pthread_key_create(3), pthread_setspecific(3) y pthread_getspecific(3) donde un hilo puede crear una clave para el dato local del hilo y manipular ese dato mediante pthread_getspecific(3) o pthread_getspecific(3). Se definió una nueva palabra clave que especifica que una variable es específica de un hilo. Puedes ver que esta no es la forma más cómoda de conseguir este objetivo. De forma que varios creadores de compiladores de C/C++ introdujeron un mecanismo mejor. También se desarrolló un nuevo método para acceder a dichas variables (al menos en i386). El método de pthreads se suele implementar en espacio de usuario como una tabla de búsqueda trivial. El rendimiento de esta solución no es muy bueno. El nuevo método utiliza registros de segmento (en i386) para direccionar un segmento donde se almacena el área TLS de forma que el acceso real a la variable del hilo consisten en añadir el registro del segmento a la dirección y acceder mediante ella. Los registros de segmento son normalmente %gs y %fs y actúan como selectores de segmentos. Cada hilo tiene su propia área donde se almacenan lo datos locales al hilo y el segmento se tiene que cargar en cada cambio de contexto. Este método es muy rápido y se utiliza casi en exclusiva en el mundo i386 de UNIX®. Tanto FreeBSD como Linux® implementan esta aproximación y se obtienen muy buenos resultados. El único problema es la necesidad de recargar el segmento en cada cambio de contexto lo que puede hacer los cambios de contexto más lentos. FreeBSD intenta evitar esta sobrecargar utilizando sólo 1 descriptor de segmento para esto mientras que Linux® utiliza 3. Algo interesante es que prácticamente nada utiliza más de 1 descriptor (sólo Wine parece utilizar 2) de forma que Linux® para un precio innecesario por los cambios de contexto.

La arquitectura i386 implementa los llamados segmentos. Un segmento es una descripción de un área de memoria. La dirección base (abajo) del área de memoria, el final (techo), tipo, protección, etc. Se puede acceder a la memoria descrita por un segmento utilizando un registro de selección de segmento (%cs, %ds, %ss, %es, %fs, %gs). Por ejemplo supongamos que tenemos un segmento cuya dirección base es 0x1234 y también tenemos su longitud y este código:

Esto cargará el contenido del registro %edx en la ubicación de memoria 0x1244. Algunos registros de segmento tienen un uso especial, por ejemplo %cs se utiliza para el segmento de código y %ss se utiliza para el segmento de pila pero %fs y %gs generalmente no se utilizan. Los segmentos se almacenan en una tabla GDT global o en una tabla LDT local. Se accede a LDT a través de una entrada en el GDT. El LDT puede almacenar más tipos de segmentos. LDT puede ser por proceso. Ambas tablas definen hasta 8191 entradas.

Hay dos formas principales de establecer TLS en Linux®. Se puede establecer cuando se clona un proceso con la llamada al sistema clone o se puede llamar a set_thread_area. Cuando un proceso para el flag CLONE_SETTLS a clone, el kernel espera que la memoria apuntada por el registro %esi sea una representación en espacio de usuario de un segmento Linux® que se traduce a la representación máquina de un segmento y se carga en una entrada de la GDT. La entrada de la GDT se puede especificar con un número o se puede usar -1 que significa que el sistema puede escoger la primera entrada que encuentre libre. En la práctica, la gran mayoría de programas utilizan sólo una entrada TLS y no se preocupan acerca del número de la misma. Aprovechamos esto en la emulación y de hecho dependemos de ello.

Los hilos necesitan algún tipo de sincronización y POSIX® proporciona algunos de ellos: mutex para exclusión mutua, locks de lectura y escritura para exclusión mutua con una proporción sesgada de lecturas y escrituras y variables de condición para señalar un cambio de estado. Es interesante notar que la API de hilos de POSIX® carece de soporte para semáforos. Esas implementaciones de rutinas de sincronización dependen en gran medida del tipo de soporte de hilos que tenemos. En el modelo puro 1:M (espacio de usuario), la implementación se puede realizar únicamente en el espacio de usuario y, por lo tanto, es muy rápida (las variables de condición probablemente terminarán implementándose mediante señales, es decir, no tan rápido) y simple. En el modelo 1:1, la situación también es bastante clara: los hilos deben sincronizarse utilizando las primitivas del kernel (lo cual es muy lento porque se debe realizar una llamada al sistema). El escenario mixto M:N simplemente combina el primer y segundo enfoque o se basa únicamente en el kernel. La sincronización de hilos es una parte vital de la programación habilitada para hilos y su rendimiento puede afectar mucho al programa resultante. Pruebas de rendimiento recientes en el sistema operativo FreeBSD mostraron que una implementación mejorada de sx_lock producía un 40% de aceleración en ZFS (un usuario intensivo de sx), esto es algo dentro del kernel pero muestra claramente cuán importante es el rendimiento de las primitivas de sincronización.

Los programas multihilo se deberían escribir con la menor contención posible. De otro modo en lugar de hacer trabajo útil el hilo simplemente espera en un bloqueo. Como resultado los programas mejores escritos muestran poca contención en bloqueos.

Linux® implementa multihilo 1:1, es decir tiene que utilizar primitivas de sincronización dentro del kernel. Como se ha dicho antes, un programa bien escrito tiene poca contención. Así que una secuencia típica se podría realizar como dos incrementos/decrementos de contadores de referencia mutex atómicos, lo que es muy rápido, como se muestra en el siguiente ejemplo:

El modelo 1:1 nos obliga a realizar dos llamadas al sistema para esas llamadas mutex, lo cual es muy lento.

La solución que implementa Linux® 2.6 se llama futexes. Los futexes implementan la comprobación de la contención en espacio de usuario y llaman al kernel sólo en caso de contención. Por lo tanto el caso típico tiene lugar sin intervención del kernel. Esto ofrece una implementación de primitivas de sincronización razonablemente rápidas y flexibles.

La llamada al sistema futex se ve así:

En este ejemplo uaddr es una dirección del mutex en espacio de usuario, op es una operación que estamos a punto de realizar y los otros parámetros tienen significados por operación.

Los Futexes implementan las siguientes operaciones:

La emulación de futex en FreeBSD ha sido importada de NetBSD y después extendida por nosotros. Se encuentra en los ficheros linux_futex.c y linux_futex.h. La estructura futex tiene este aspecto:

Y la estructura waiting_proc es:

Durante el desarrollo del kernel 2.6.16 de Linux® se añadieron las llamadas al sistema *at. Esas llamadas (openat por ejemplo) funcionan igual que sus pares sin at con la pequeña diferencia del parámetro dirfd. Este parámetro cambia con el fichero dado sobre el que se va a realizar la llamada al sistema. Cuando el parámetro filename es absoluto dirfd es ignorado pero cuando la ruta al fichero es relativa, entra en juego. El parámetro dirfd es un directorio relativo al cual se comprueba la ruta relativa. El parámetro dirfd es un descriptor de fichero de algún directorio o AT_FDCWD. Por ejemplo la llamada al sistema openat podría ser así:

Esta infraestructura es necesaria para evitar condiciones de carrera cuando se abren ficheros fuera del directorio de trabajo actual. Imagina un proceso que consiste en dos hilos, hilo A e hilo B. El hilo A realiza open(./tmp/foo/bah., flags, mode) y antes de volver es desalojado y se ejecuta el hilo B. El hilo B no se preocupa por las necesidades del hilo A y renombra o elimina /tmp/foo/. Tenemos una condición de carrera. Para evitar esto podemos abrir /tmp/foo y utilizarlo como dirfd en la llamada al sistema openat. Esto permite al usuario implementar directorios de trabajo por hilo.

La familia *at de llamadas al sistema de Linux® contiene: linux_openat, linux_mkdirat, linux_mknodat, linux_fchownat, linux_futimesat, linux_fstatat64, linux_unlinkat, linux_renameat, linux_linkat, linux_symlinkat, linux_readlinkat, linux_fchmodat y linux_faccessat. Todas se implementan utilizando la rutina modificada nami(9) y una sencilla capa de envoltorio.

La interfaz ioctl es bastante frágil debido a su genericidad. Tenemos que tener en cuenta que los dispositivos difieren entre Linux® y FreeBSD, por lo que se debe tener cuidado para que la emulación de ioctl funcione correctamente. El manejo de ioctl se implementa en linux_ioctl.c, donde se define la función linux_ioctl. Esta función simplemente itera sobre conjuntos de manejadores ioctl para encontrar un manejador que implemente un comando dado. La llamada al sistema ioctl tiene tres parámetros, el descriptor de archivo, el comando y un argumento. El comando es un número de 16 bits, que en teoría se divide en 8 bits altos que determinan la clase del comando ioctl y 8 bits bajos, que son el comando real dentro del conjunto dado. La emulación aprovecha esta división. Implementamos controladores para cada conjunto, como sound_handler o disk_handler.Cada controlador tiene un comando máximo y un comando mínimo definido, que se utiliza para determinar qué controlador se utiliza. Hay leves problemas con este enfoque porque Linux® no usa la división de conjuntos de manera consistente, por lo que a veces los ioctls de un conjunto diferente están dentro de un conjunto al que no deberían pertenecer (ioctls genéricos SCSI dentro del conjunto cdrom, etc.). FreeBSD actualmente no implementa muchos ioctls de Linux® (en comparación con NetBSD, por ejemplo) pero el plan es portarlos de NetBSD. La tendencia es usar ioctls de Linux® incluso en los controladores nativos de FreeBSD debido a la fácil migración de las aplicaciones.

Cada llamada al sistema debería ser depurable. Para ello introducimos una pequeña infraestructura. Tenemos la función ldebug, que indica si una llamada al sistema determinada debe depurarse (configurable mediante un sysctl). Para imprimir tenemos macros LMSG y ARGS. Se utilizan para alterar una cadena imprimible para mensajes de depuración uniformes.