Source string Read only

(itstool) path: sect3/para
1626/16260
Context English State
Implementation
The implementation is done by altering the <citerefentry><refentrytitle>namei</refentrytitle><manvolnum>9</manvolnum></citerefentry> routine (described above) to take additional parameter <varname>dirfd</varname> in its <literal>nameidata</literal> structure, which specifies the starting point of the pathname lookup instead of using the current working directory every time. The resolution of <varname>dirfd</varname> from file descriptor number to a vnode is done in native *at syscalls. When <varname>dirfd</varname> is <literal>AT_FDCWD</literal> the <varname>dvp</varname> entry in <literal>nameidata</literal> structure is <literal>NULL</literal> but when <varname>dirfd</varname> is a different number we obtain a file for this file descriptor, check whether this file is valid and if there is vnode attached to it then we get a vnode. Then we check this vnode for being a directory. In the actual <citerefentry><refentrytitle>namei</refentrytitle><manvolnum>9</manvolnum></citerefentry> routine we simply substitute the <varname>dvp</varname> vnode for <varname>dp</varname> variable in the <citerefentry><refentrytitle>namei</refentrytitle><manvolnum>9</manvolnum></citerefentry> function, which determines the starting point. The <citerefentry><refentrytitle>namei</refentrytitle><manvolnum>9</manvolnum></citerefentry> is not used directly but via a trace of different functions on various levels. For example the <function>openat</function> goes like this:
openat() --&gt; kern_openat() --&gt; vn_open() -&gt; namei()
For this reason <function>kern_open</function> and <function>vn_open</function> must be altered to incorporate the additional <varname>dirfd</varname> parameter. No compat layer is created for those because there are not many users of this and the users can be easily converted. This general implementation enables FreeBSD to implement their own *at syscalls. This is being discussed right now.
Ioctl
The ioctl interface is quite fragile due to its generality. We have to bear in mind that devices differ between <trademark class="registered">Linux</trademark> and FreeBSD so some care must be applied to do ioctl emulation work right. The ioctl handling is implemented in <filename>linux_ioctl.c</filename>, where <function>linux_ioctl</function> function is defined. This function simply iterates over sets of ioctl handlers to find a handler that implements a given command. The ioctl syscall has three parameters, the file descriptor, command and an argument. The command is a 16-bit number, which in theory is divided into high 8 bits determining class of the ioctl command and low 8 bits, which are the actual command within the given set. The emulation takes advantage of this division. We implement handlers for each set, like <function>sound_handler</function> or <function>disk_handler</function>. Each handler has a maximum command and a minimum command defined, which is used for determining what handler is used. There are slight problems with this approach because <trademark class="registered">Linux</trademark> does not use the set division consistently so sometimes ioctls for a different set are inside a set they should not belong to (SCSI generic ioctls inside cdrom set, etc.). FreeBSD currently does not implement many <trademark class="registered">Linux</trademark> ioctls (compared to NetBSD, for example) but the plan is to port those from NetBSD. The trend is to use <trademark class="registered">Linux</trademark> ioctls even in the native FreeBSD drivers because of the easy porting of applications.
Debugging
Every syscall should be debuggable. For this purpose we introduce a small infrastructure. We have the ldebug facility, which tells whether a given syscall should be debugged (settable via a sysctl). For printing we have LMSG and ARGS macros. Those are used for altering a printable string for uniform debugging messages.
Conclusion
Results
As of April 2007 the <trademark class="registered">Linux</trademark> emulation layer is capable of emulating the <trademark class="registered">Linux</trademark> 2.6.16 kernel quite well. The remaining problems concern futexes, unfinished *at family of syscalls, problematic signals delivery, missing <function>epoll</function> and <function>inotify</function> and probably some bugs we have not discovered yet. Despite this we are capable of running basically all the <trademark class="registered">Linux</trademark> programs included in FreeBSD Ports Collection with Fedora Core 4 at 2.6.16 and there are some rudimentary reports of success with Fedora Core 6 at 2.6.16. The Fedora Core 6 linux_base was recently committed enabling some further testing of the emulation layer and giving us some more hints where we should put our effort in implementing missing stuff.

Loading…

None

New source string

FreeBSD Doc / articles_linux-emulationEnglish

New source string 3 months ago
Browse all component changes

Things to check

Long untranslated

The string was not translated for a long time

Reset

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect3/para
Labels
No labels currently set.
Flags
read-only
Source string location
article.translate.xml:2392
Source string age
3 months ago
Translation file
, string 356