Source string Read only

(itstool) path: sect3/programlisting

Context English State
<citerefentry><refentrytitle>vput</refentrytitle><manvolnum>9</manvolnum></citerefentry> - decrements the use count for a vnode and unlocks it
<citerefentry><refentrytitle>vrele</refentrytitle><manvolnum>9</manvolnum></citerefentry> - decrements the use count for a vnode
<citerefentry><refentrytitle>vref</refentrytitle><manvolnum>9</manvolnum></citerefentry> - increments the use count for a vnode
File handler operations
<function>fget</function> - given a thread and a file descriptor number it returns associated file handler and references it
<function>fdrop</function> - drops a reference to a file handler
<function>fhold</function> - references a file handler
<trademark class="registered">Linux</trademark> emulation layer -MD part
This section deals with implementation of <trademark class="registered">Linux</trademark> emulation layer in FreeBSD operating system. It first describes the machine dependent part talking about how and where interaction between userland and kernel is implemented. It talks about syscalls, signals, ptrace, traps, stack fixup. This part discusses i386 but it is written generally so other architectures should not differ very much. The next part is the machine independent part of the Linuxulator. This section only covers i386 and ELF handling. A.OUT is obsolete and untested.
Syscall handling
Syscall handling is mostly written in <filename>linux_sysvec.c</filename>, which covers most of the routines pointed out in the <literal>sysentvec</literal> structure. When a <trademark class="registered">Linux</trademark> process running on FreeBSD issues a syscall, the general syscall routine calls linux prepsyscall routine for the <trademark class="registered">Linux</trademark> ABI.
<trademark class="registered">Linux</trademark> prepsyscall
<trademark class="registered">Linux</trademark> passes arguments to syscalls via registers (that is why it is limited to 6 parameters on i386) while FreeBSD uses the stack. The <trademark class="registered">Linux</trademark> prepsyscall routine must copy parameters from registers to the stack. The order of the registers is: <varname>%ebx</varname>, <varname>%ecx</varname>, <varname>%edx</varname>, <varname>%esi</varname>, <varname>%edi</varname>, <varname>%ebp</varname>. The catch is that this is true for only <emphasis>most</emphasis> of the syscalls. Some (most notably <function>clone</function>) uses a different order but it is luckily easy to fix by inserting a dummy parameter in the <function>linux_clone</function> prototype.
Syscall writing
Every syscall implemented in the Linuxulator must have its prototype with various flags in <filename>syscalls.master</filename>. The form of the file is:
AUE_FORK STD { int linux_fork(void); }
AUE_CLOSE NOPROTO { int close(int fd); }
The first column represents the syscall number. The second column is for auditing support. The third column represents the syscall type. It is either <literal>STD</literal>, <literal>OBSOL</literal>, <literal>NOPROTO</literal> and <literal>UNIMPL</literal>. <literal>STD</literal> is a standard syscall with full prototype and implementation. <literal>OBSOL</literal> is obsolete and defines just the prototype. <literal>NOPROTO</literal> means that the syscall is implemented elsewhere so do not prepend ABI prefix, etc. <literal>UNIMPL</literal> means that the syscall will be substituted with the <function>nosys</function> syscall (a syscall just printing out a message about the syscall not being implemented and returning <literal>ENOSYS</literal>).
From <filename>syscalls.master</filename> a script generates three files: <filename>linux_syscall.h</filename>, <filename>linux_proto.h</filename> and <filename>linux_sysent.c</filename>. The <filename>linux_syscall.h</filename> contains definitions of syscall names and their numerical value, e.g.:
#define LINUX_SYS_linux_fork 2
#define LINUX_SYS_close 6
The <filename>linux_proto.h</filename> contains structure definitions of arguments to every syscall, e.g.:
struct linux_fork_args {
register_t dummy;
And finally, <filename>linux_sysent.c</filename> contains structure describing the system entry table, used to actually dispatch a syscall, e.g.:
{ 0, (sy_call_t *)linux_fork, AUE_FORK, NULL, 0, 0 }, /* 2 = linux_fork */
{ AS(close_args), (sy_call_t *)close, AUE_CLOSE, NULL, 0, 0 }, /* 6 = close */
As you can see <function>linux_fork</function> is implemented in Linuxulator itself so the definition is of <literal>STD</literal> type and has no argument, which is exhibited by the dummy argument structure. On the other hand <function>close</function> is just an alias for real FreeBSD <citerefentry><refentrytitle>close</refentrytitle><manvolnum>2</manvolnum></citerefentry> so it has no linux arguments structure associated and in the system entry table it is not prefixed with linux as it calls the real <citerefentry><refentrytitle>close</refentrytitle><manvolnum>2</manvolnum></citerefentry> in the kernel.
Dummy syscalls
The <trademark class="registered">Linux</trademark> emulation layer is not complete, as some syscalls are not implemented properly and some are not implemented at all. The emulation layer employs a facility to mark unimplemented syscalls with the <literal>DUMMY</literal> macro. These dummy definitions reside in <filename>linux_dummy.c</filename> in a form of <literal>DUMMY(syscall);</literal>, which is then translated to various syscall auxiliary files and the implementation consists of printing a message saying that this syscall is not implemented. The <literal>UNIMPL</literal> prototype is not used because we want to be able to identify the name of the syscall that was called in order to know what syscalls are more important to implement.
Signal handling
Signal handling is done generally in the FreeBSD kernel for all binary compatibilities with a call to a compat-dependent layer. <trademark class="registered">Linux</trademark> compatibility layer defines <function>linux_sendsig</function> routine for this purpose.
<trademark class="registered">Linux</trademark> sendsig
This routine first checks whether the signal has been installed with a <literal>SA_SIGINFO</literal> in which case it calls <function>linux_rt_sendsig</function> routine instead. Furthermore, it allocates (or reuses an already existing) signal handle context, then it builds a list of arguments for the signal handler. It translates the signal number based on the signal translation table, assigns a handler, translates sigset. Then it saves context for the <function>sigreturn</function> routine (various registers, translated trap number and signal mask). Finally, it copies out the signal context to the userspace and prepares context for the actual signal handler to run.


No matching activity found.

Browse all component changes

Things to check

Multiple failing checks

The translations in several languages have failing checks



The string uses three dots (...) instead of an ellipsis character (…)



English English
No related strings found in the glossary.

Source information

Source string comment

(itstool) path: sect3/programlisting

no-wrap, read-only
Source string location
String age
a year ago
Source string age
a year ago
Translation file
articles/linux-emulation.pot, string 209