dbaio
None
The locking is implemented to be per-subsystem because we do not expect a lot of contention on these. There are two locks: <literal>emul_lock</literal> used to protect manipulating of <literal>linux_emuldata</literal> and <literal>emul_shared_lock</literal> used to manipulate <literal>linux_emuldata_shared</literal>. The <literal>emul_lock</literal> is a nonsleepable blocking mutex while <literal>emul_shared_lock</literal> is a sleepable blocking <literal>sx_lock</literal>. Because ofDue to the per-subsystem locking we can coalesce some locks and that is why the em find offers the non-locking access.
There are currently two ways to implement threading in FreeBSD. The first way is M:N threading followed by the 1:1 threading model. The default library used is M:N threading (<literal>libpthread</literal>) and you can switch at runtime to 1:1 threading (<literal>libthr</literal>). The plan is to switch to 1:1 library by default soon. Although those two libraries use the same kernel primitives, they are accessed through different API(es). The M:N library uses the <literal>kse_*</literal> family of syscalls while the 1:1 library uses the <literal>thr_*</literal> family of syscalls. Because ofDue to this, there is no general concept of thread ID shared between kernel and userspace. Of course, both threading libraries implement the pthread thread ID API. Every kernel thread (as described by <literal>struct thread</literal>) has td tid identifier but this is not directly accessible from userland and solely serves the kernel's needs. It is also used for 1:1 threading library as pthread's thread ID but handling of this is internal to the library and cannot be relied on.
The locking is implemented to be per-subsystem because we do not expect a lot of contention on these. There are two locks: <literal>emul_lock</literal> used to protect manipulating of <literal>linux_emuldata</literal> and <literal>emul_shared_lock</literal> used to manipulate <literal>linux_emuldata_shared</literal>. The <literal>emul_lock</literal> is a nonsleepable blocking mutex while <literal>emul_shared_lock</literal> is a sleepable blocking <literal>sx_lock</literal>. Because ofDue to the per-subsystem locking we can coalesce some locks and that is why the em find offers the non-locking access.
There are currently two ways to implement threading in FreeBSD. The first way is M:N threading followed by the 1:1 threading model. The default library used is M:N threading (<literal>libpthread</literal>) and you can switch at runtime to 1:1 threading (<literal>libthr</literal>). The plan is to switch to 1:1 library by default soon. Although those two libraries use the same kernel primitives, they are accessed through different API(es). The M:N library uses the <literal>kse_*</literal> family of syscalls while the 1:1 library uses the <literal>thr_*</literal> family of syscalls. Because ofDue to this, there is no general concept of thread ID shared between kernel and userspace. Of course, both threading libraries implement the pthread thread ID API. Every kernel thread (as described by <literal>struct thread</literal>) has td tid identifier but this is not directly accessible from userland and solely serves the kernel's needs. It is also used for 1:1 threading library as pthread's thread ID but handling of this is internal to the library and cannot be relied on.
Aaron
Generally, as <trademark class="registered">Linux</trademark> develops we would like to keep up with their development, implementing newly added syscalls. Splice comes to mind first. Some already implemented syscalls are also heavily crippled, for example <function>mremap</function> and others. Some performance improvements can also be made, finer grained locking and others.
Generalmente, como <trademark class="registered">Linux</trademark> desarrolla nos gustaría mantenernos al día con su desarrollo, implementando syscalls recién agregadas. El empalme viene a la mente primero. Algunas llamadas al sistema ya implementadas también están muy paralizadas, por ejemplo <function>mremap</function> y otros. También se pueden realizar algunas mejoras de rendimiento, bloqueo de grano más fino y otros.
The other possible goal is to share our code with NetBSD and DragonflyBSD. NetBSD has some support for 2.6 emulation but its far from finished and not really tested. DragonflyBSD has expressed some interest in porting the 2.6 improvements.
El otro objetivo posible es compartir nuestro código con NetBSD y DragonflyBSD. NetBSD tiene algo de soporte para la emulación 2.6 pero está lejos de estar terminado y no se ha probado realmente. DragonflyBSD ha expresado cierto interés en portar las mejoras 2.6.