Category Archives: Source

Alexander Leidinger » FreeBSD 2012-05-18 15:36:50

A while ago I committed the linuxulator D-Trace probes I talked about earlier. I waited a little bit for this announcement to make sure I have not broken anything. Nobody complained so far, so I assume nothing obviously bad crept in.

The >500 probes I committed do not cover the entire linuxulator, but are a good start. Adding new ones is straight forward, if someone is interested in a junior–kernel–hacker task, this would be one. Just ask me (or ask on emulation@), and I can guide you through it.

Share

Alexander Leidinger » FreeBSD 2012-04-25 19:15:28

In case you have not noticed yet, KDTRACE_HOOKS is now in the GENERIC kernel in FreeBSD-current. This means you just need to load the DTrace modules and can use DTrace with the GENERIC kernel.

In case you do not know what you can do with DTrace, take the time to have a look at the DTrace blog. It is worth any minute you invest reading it.

Share

Alexander Leidinger » FreeBSD 2012-04-15 18:43:03

This weekend I made some progress in the linuxulator:

  • I MFCed the reporting of some linux-syscalls to 9-stable and 8-stable.
  • I updated my linuxulator-dtrace patch to a recent -current. I already compiled it on i386 and arundel@ has it compiled on amd64. I counted more than 500 new DTrace probes. Now that DTrace rescans for SDT probes when a kernel module is loaded, there is no kernel panic anymore when the linux module is loaded after the DTrace modules and you want to use DTrace. I try to commit this at a morning of a day where I can fix things during the day in case some problems show up which I did not notice during my testing.
  • I created a PR for portmgr@ to repocopy a new linux_base port.
  • I set the expiration date of linux_base-fc4 (only used by 7.x and upstream way past its EoL) and all dependent ports. It is set to the EoL of the last 7.x release, which can not use a later linux_base port. I also added a comment which explains that the date is the EoL of the last 7.x release.

Share

New opportunities in the linuxulator

Last weekend I committed some dummy-syscalls to the linuxulator in FreeBSD-current. I also added some comments to syscalls.master which should give a hint which linux kernel had them for the first time (if the linux man–page I looked this up in is correct). So if someone wants to experiment with a higher compat.linux.osrelease than 2.6.16 (as it is needed for a CentOS based linux_base), he should now get some kernel messages about unimplemented syscalls instead of a silent failure.

There may be some low-hanging fruits in there, but I did not really verify this by checking what the dummy syscalls are supposed to do in linux and if we can easily map this to existing FreeBSD features. In case someone has a look, please send an email to emulation@FreeBSD.org.

Share

Static DTrace probes for the linuxulator updated

I got a little bit of time to update my 3 year old work of adding static DTrace probes to the linuxulator.

The changes are not in HEAD, but in my linuxulator-dtrace branch. The revision to have a look at is r230910. Included are some DTrace scripts:

  • script to check internal locks
  • script to trace futexes
  • script to generate stats for DTracified linuxulator parts
  • script to check for errors:
    • emulation errors (unsupported stuff, unknown stuff, …)
    • kernel errors (resource shortage, …)
    • programming errors (errors which can happen if someone made a mistake, but should not happen)

The programming-error checks give hints about userland programming errors respectively a hint about the reason of error return values due to resource shortage or maybe a wrong combination of parameters. An example error message for this case is “Application %s issued a sysctl which failed the length restrictions.nThe length passed is %d, the min length supported is 1 and the max length supported is %d.n�.

The stats-script (tailored specially to the linuxulator, but this can easily be extended to the rest of the kernel) can report about:

  • number of calls to a kernel function per executable binary (not per PID!): allows to see where an optimization would be beneficial for a given application
  • graph of CPU time spend in kernel functions per executable binary: together with the number of calls to this function this allows to determine if a kernel optimization would be beneficial / is possible for a given application
  • graph of longest running (CPU-time!) kernel function in total
  • timing statistics for the emul_lock
  • graph of longest held (CPU-time!) locks

Unfortunately this can not be committed to HEAD as-is. The DTrace SDT provider can not handle probes which are added to the kernel after the SDT provider is already loaded. This means that you either have to compile the linuxulator statically into the kernel, or you have to load the SDT kernel module after the linuxulator module is loaded. If you do not respect this, you get a kernel panic on first access of one of the providers in the linuxulator (AFAIR this includes listing the probes available in the kernel).

Share

X11 in a jail with NVidia hardware

Just before christmas I decided I will spend the “immense� amount of 40 EUR for a graphic card for a system which was without one. The system is supposed to replace my dying home-server. I already moved everything, except my Desktop-in-a-Jail (actually it is my home-cinema-jail).

The old system had a Radeon 9200SE, and it was enough for what I used it for. Now… for a few bucks you can get a lot more horsepower today. After looking around a little bit I decided to buy a NVidia card. I made this decision because it looks like I can get better driver support for it. So I got a GeForce GT 520 with 1 GB of RAM (I doubt I will be able to use that much RAM) and without a fan.

With the Radeon 9200SE I was not able to get the 3D stuff activated (at least in the jail, I did not try without), Xorg complains about a missing agpgart module but I have AGP in the kernel (no /dev/agpgart outside the jail). I did not spend time to investigate this, as the main purpose — playing movies — worked. Now with the NVidia card I decided to give the 3D part a try again.

After adding the NVidia device entries to the jail, and a little bit of fighting with the Xorg-HAL interaction, I got a working desktop. The biggest problem to verify that 3D is working was, that I did not had xdriinfo installed. After installing it, I noticed that it does not work with the NVidia driver.  :-(   Next stop nvidia-settings: runs great, displays a nice FreeBSD+NVidia logo, and … tells me that OpenGL is configured. Hmmm… OK, but I want to see it!

As I decided to switch from Gnome to KDE 4 at  the same time (I was using KDE when it was at V 0.x, switched to Gnome as it looked nicer to me, and now I switch back after reading all the stuff in the net that KDE 4 is “better� than Gnome 3), I was a little bit out of knowledge how to see the 3D stuff in action. So I quickly went to the settings and searched for something which looks like it may use 3D. To my surprise, it was already using 3D stuff. Nice. I fully realized how nice, when playing a video and using Alt-Tab to switch windows: the video was playing full speed scaled down in the window-switcher-thumbnail-view.

That was too easy. I am happy about it.

Now that I have a working setup of X11-in-a-jail for Radeon and GeForce cards, I want to cleanup my changes to the kernel and the config files (devfs.rules) and have a look to get this committed. A big part of this work is probably writing documentation (most probably in the wiki).

I still want to see some fancy 3D stuff now. I tried to install x11-clocks/glclock, but the build fails with an undefined reference to ‘glPolygonOffsetEXT’. :-( Any recommendation for a fancy 3D display? My priority is on “fancy/nice� with as less violence as possible. Most probably I will look at it once and then deinstall it again, so it should be available in the Ports Collection (or included in KDE 4).

Share

(Free)BSD inside Android

Today I was looking into the OpenSource licenses which are displayed for Android (2.3.4). There are several files which come with a BSD license.

During looking at it, I noticed that the libm has the copyright of several FreeBSD people. I did not had an in-deep look if this is because they took the FreeBSD libm, or if this is because parts of the FreeBSD libm where adopted by other BSD projects.

What I noticed is, that some special characters are not displayed correctly. For example the name Dag-Erling Smørgrav looks mangled in the display of the license inside the phone (I hope it is displayed better in my blog). His name is not the only problem case, there are also other characters which are not rendered as expected.

This does not really look professional.

Share

Linuxulator explained (for developers): adding ioctls directly to the kernel

After giving an overview of the in-kernel basics of the Linuxulator, I want now to describe how to add support for new ioctls to the Linuxulator.

Where are the files to modify?

The platform independent code for the ioctls is in SRC/sys/compat/linux/linux_ioctl.c. The defines to have names for the ioctl values are in SRC/sys/compat/linux/linux_ioctl.h.

How to modify them?

First of all create a new header which will contain all the structures, named values and macros for those new ioctls. As written above, the ioctl values (e.g. #define LINUX_VIDIOC_ENCODER_CMD 0x564d /* 0xc028564d */) do not belong there, they shall be added to linux_ioctl.h. During the course of adding support for ioctls, you will need this new header. Add it in the SRC/sys/compat/linux/ directory, and prefix the name with a linux_. It would be good to decide on a common tag here (referenced as yourtag in the following), and stay with it. Use it wherever you need to have some specific name for the ioctl-set you want to add. In this case it would result in linux_yourtag.h (or even linux_ioctl_yourtag.h, depending if this is used for something very specific to the ioctls, or some generic linux feature) as the name of the header file. This was not done in the past, so do not expect that the names inside the linux_ioctl.c file will be consistent to this naming scheme, but it is never too late to correct mistakes of the past (at least in Open Source software development).

Now add this header to linux_ioctl.c (you need to include compat/linux/linux_yourtag.h). After that add the ioctl values to linux_ioctl.h. As can be seen above, the defines should be named the same as on linux, but with a LINUX_ prefix (make sure they where not defined before somewhere else). The ioctl values need to be the same hex values as in Linux, off course. Sort them according to their hex value. When you added all, you need to add two more defines. The LINUX_IOCTL_yourtag_MIN and LINUX_IOCTL_yourtag_MAX ones. The MIN-one needs to be an alias for the first (sorted according to the hex value) ioctl you added, and MAX needs to be an alias for the last (again, sorted according to the hex value) ioctl you added.

The next step is to let the Linuxulator know that it is able to handle the ioctls in the LINUX_IOCTL_yourtag_MIN to LINUX_IOCTL_yourtag_MAX range. Search the static linux_ioctl_function_t section of linux_ioctl.c and add such a variable for your ioctl set. The name of the variable should be something like linux_ioctl_yourtag.

Similar for the handler-definition for this. Search the static struct linux_ioctl_handler section and add a yourtag_handler. Set it to { linux_ioctl_yourtag, LINUX_IOCTL_yourtag_MIN, LINUX_IOCTL_yourtag_MAX }. To make this handler known to the Linuxulator, you need to add it to the DATA_SET section. Add DATA_SET(linux_ioctl_handler_set, yourtag_handler) there.

Now the meat, the function which handles the ioctls. You already defined it as linux_ioctl_function_t, but now you need to write it. The outline of it looks like this:

static int
linux_ioctl_yourtag(struct thread *td, struct linux_ioctl_args *args)
{
        struct file *fp;
        int error;
        switch (args->cmd & 0xffff) {
        case LINUX_an_easy_ioctl:
                break;
        case LINUX_a_not_so_easy_ioctl:
                /* your handling of the ioctl */
                fdrop(fp, td);
                return (error);
        /* some more handling of your ioctls */
        default:
       return (ENOIOCTL);
        }
        error = ioctl(td, (struct ioctl_args *)args);
        return (error);
}

An easy ioctl in the switch above is an ioctl where you do not have to do something but can pass the ioctl through to FreeBSD itself. The not so easy ioctl case is an ioctl where you need to do e.g. a fget(td, args->fd, &fp). This is just an example, there are also other possibilities where you need to do additional stuff before the return, or where you do not pass the ioctl to FreeBSD. A typical example of what needs to be done here is to copy values from linux structures to FreeBSD structures (and the other way too), or to translate between 64bit and 32bit. Linux programs on amd64 are 32bit executables and 32bit structures/pointers. To make this work on amd64, you need to find a way to map between the two. There are examples in the kernel where this is already the case. The more prominent examples in the 64bit<->32bit regard are the v4l and v4l2 ioctls.

The tedious part is to research if a translation has to be done and if yes what needs to be translated how. When this is done, most of the work is not so hard. The linux_yourtag.h should contain the structures you need for this translation work.

It is also possible to add ioctls in a kernel module, but this is not subject to this description (I will update this posting with a link to it when I get time to write about it).

Share

(Free)BSD inside Android

Today I was looking into the OpenSource licenses which are displayed for Android (2.3.4). There are several files which come with a BSD license.

During looking at it, I noticed that the libm has the copyright of several FreeBSD people. I did not had an in-deep look if this is because they took the FreeBSD libm, or if this is because parts of the FreeBSD libm where adopted by other BSD projects.

What I noticed is, that some special characters are not displayed correctly. For example the name Dag-Erling Smørgrav looks mangled in the display of the license inside the phone (I hope it is displayed better in my blog). His name is not the only problem case, there are also other characters which are not rendered as expected.

This does not really look professional.

Share

v4l2 support in the linuxulator now in 8-stable

I MFCed the v4l2 support in the linuxulator to 8–stable. This allows now to use v4l2–webcams in skype/flash on 8-stable too.

Share

Video4Linux2 sup­port in FreeBSD (linuxulator)

I com­mit­ted the v4l2 sup­port into the lin­ux­u­la­tor (in 9-current). Part of this was the import of the v4l2 header from linux. We have the per­mis­sion to use it (like the v4l one), it is not licensed via GPL. This means we can use it in FreeBSD native dri­vers, and they are even allowed to be com­piled into GENERIC (but I doubt we have a dri­ver which could pro­vide the v4l2 inter­face in GENERIC).

The code I com­mit­ted is “just� the glue-code which allows to use FreeBSD native devices which pro­vide a v4l2 inter­face (e.g. multimedia/pwcbsd or multimedia/webcamd) from linux programs.

Thanks to nox@ for writing the glue code.

Share

DTrace probes for the Linuxulator updated

If someone had a look at the earlier post about DTrace probes for the Linuxulator: I updated the patch at the same place. The difference between the previous one is that some D-scripts are fixed now to do what I meant, specially the ones which provide statistics output.

Share

New DTrace probes for the linuxulator

I forward ported my DTrace probes for the FreeBSD linuxulator from a 2008-current to a recent –current. I have not the complete FreeBSD linuxulator covered, but a big part is already done. I can check the major locks in the linuxulator, trace futexes, and I have a D-script which yells at a lot of errors which could happen but should not.

Some of my D-scripts need some changes, as real-world testing showed that they are not really working as expected. They can get overwhelmed by the amount of speculation and dynamic variables (error message: dynamic variable drops with non-empty dirty list). For the dynamic variables problem I found a discussion on the net with some suggestions. For the speculation part I expect similar tuning-possibilities.

Unfortunately the D-script which checks the internal locks fails to compile. Seems there is a little misunderstanding on my side how the D-language is supposed to work.

I try to get some time later to have a look at those problems.

During my development I stumbled over some generic DTrace problems with the SDT provider I use for my probes:

  • If you load the Linux module after the SDT module, your system will panic as soon as you want to access some probes, e.g. “dtrace –lâ€? will panic the system. Loading the Linux module before the SDT module prevents the panic.
  • Unloading the SDT module while the Linux module with the SDT probes is still loaded panics the system too. Do not unload the Linux module if you run with my patch.

According to avg@ those are known problems, but I think nobody is working on this. This is bad, because this means I can not commit my current patchset.

If someone wants to try the new DTrace probes for the linuxulator, feel free to go to http://www.Leidinger.net/FreeBSD/current-patches/ and download linuxulator-dtrace.diff. I do not offer a working hyperlink here on purpose, the SDT bugs can hurt if you are not careful, and I want to make the use of this patch a strong opt-in because of this. If the patch hurts you, it is your fault, you have been warned.

Share

HOWTO: creating your own updated linux RPM for the FreeBSD linuxulator

Background info

The FreeBSD linux compatibility environment currently uses RPMs from Fedora 10. Unfortunately Fedora 10 is end of life since a while. For one of the RPMs (the pango one) we where aware of a security vulnerability. As we do not know if it is feasible to update the linuxulator ports to something more recent, I decided to setup a VM with Fedora 10 and generate a new RPM for the linux-f10-pango port. Thanks to Luchesar V. ILIEV for explaining me how to do this.

Setup of the VM

I used VirtualBox 4.0.4 on a Solaris 10 x86 machine. I configured a fixed size disk of 16 GB and kept the default network setup (after installing the guest tools / kernel modules I switched to virtio, as I was not able to do anything useful besides a ping) and RAM size. The CD/DVD drive was configured to use the image of the full Fedora 10 DVD for i386 systems.

Setup of Fedora 10

Booting the VM from the DVD leads to the graphical Fedora 10 install software (after chosing to install a new system on the console). There I accepted all the defaults, except for the software to install. I deselected the Office and Productivity group and selected the Software Development group. When I was asked if I want to install some additional RPMs I had a look at the complete list and installed some I thought are necessary. I do not remember anymore which ones I chose, but everything which looks related to RPM building is a good candidate.

After a while the install will be finished and you can boot into the new system (eject the DVD from the drive before reboot). After reboot chose to install the Guest Additions in the menu of the VM. This should mount the ISO image in the VM. As root execute the file for Linux. This will build some kernel modules for better integration (e.g. seamless integration of the mouse between your desktop and the VM). At this point I rebooted and configured virtio as the NIC. I also had to configure the network settings by hand, as the GUI tool did not safe all the settings correctly.

Update and install of required RPMs

After the VM was up and the network configured, I updated the entire system (chose System Update in the menu). To update the pango port, I had to install the libthai-devel RPM. I had the RPM for it (and all the files I need to build a new pango RPM) already downloaded, so I did a “yum install /path/to/rpm�. At this point I was ready to create the RPM build environment.

The RPM build environment

As a normal user I executed the command rpmdev-setuptree which creates the directory rpmbuild and populates it with some directories. Now you just need to find a suitable .spec file and put it into rpmbuild/SPECS, put the sources (and maybe patches referenced in the .spec file) into rpmbuild/SOURCES, and you are ready to go (I patched pango.spec for a more recent pango version, basically just changing the version numbers). If you want to have a custom packager and vendor attribute in the RPM, you can add a line for each to ~/.rpmmacros, e.g. %packager yournamehere and %vendor whateverisappropriate. I used my @FreeBSD.org EMail address as the packager, and FreeBSD as the vendor.

Building a RPM

I used rpmbuild –ba –target i386-redhat-linux-gnu –clean rpmbuild/SPECS/pango.spec to build the new pango RPM. If everything is OK, the resulting RPMs (a source RPM, a devel RPM, a debuginfo RPM and the RPM for the binaries) are in rpmbuild/RPMS and rpmbuild/SRPMS. For a FreeBSD port we just need the source RPM (to comply to the (L)GPL) and the RPM for the binaries.

Additional info

The i386-redhat-linux-gnu string which is used for the –target option of the rpmbuild command is what seems to be used to build the Fedora 10 RPMs. After building pango, the RPM has i686-pc-linux-gnu in some filenames instead (the default value for this setup). The binaries seem to be compiled for i386, so there should be no problem even for old systems.

Share

Additional FEATURE macros on the way

It seems I have a bit of free time now to take care about some FreeBSD related things.

As part of this I already committed the UFS/FFS related FEATURE macros which where developed by kibab@ during the Google Summer of Code 2010. The network/ALTQ related FEATURE macros are in the hands of bz@, he already reviewed them and wants to commit them (with some changes) as part of his improvements of parts of the network related code.

The GEOM related FEATURE macros I just send some minutes ago to geom@ for review. All the rest went out to hackers@ for review. The rest in this case is related to AUDIT, CAM, IPC, KTR, MAC, NFS, NTP, PMC, SYSV and a few other things.

If everything is committed, it should look a bit like this if queried from userland (not all features are shown, those are just the ones which are enabled in the kernel in one of my machines):

kern.features.scbus: 1
kern.features.geom_vol: 1
kern.features.geom_part_bsd: 1
kern.features.geom_part_ebr_compat: 1
kern.features.geom_part_ebr: 1
kern.features.geom_part_mbr: 1
kern.features.kposix_priority_scheduling: 1
kern.features.kdtrace_hooks: 1
kern.features.ktrace: 1
kern.features.invariant_support: 1
kern.features.compat_freebsd7: 1
kern.features.compat_freebsd6: 1
kern.features.pps_sync: 1
kern.features.stack: 1
kern.features.sysv_msg: 1
kern.features.sysv_sem: 1
kern.features.sysv_shm: 1
kern.features.posix_shm: 1
kern.features.ffs_snapshot: 1
kern.features.softupdates: 1
kern.features.ufs_acl: 1

Share

The FreeBSD-linuxulator explained (for developers): basics

The last post about the Linuxulator where I explained the Linuxulator from an user point of view got some good amount of attention. Triggered by a recent explanation of the Linuxulator errno stuff to a fellow FreeBSD developer I decided so see if more developers are interested in some more info too…

The syscall vector

In sys/linux/linux_sysvec.c is all the basic setup to handle Linux “system stuff� in FreeBSD. The “system stuff� is about translating FreeBSD errnos to Linux errnos, about translating FreeBSD signals to Linux signales, about handling Linux traps, and about setting up the FreeBSD system vector (the kernel structure which contains all the data to identify when a Linux program is called and to be able to lookup the right kernel functions for e.g. syscalls and ioctls).

There is not only one syscall vector, there is one for a.out (struct sysentvec linux_sysvec) and one for ELF (struct sysentvec elf_linux_sysvec) binaries (at least on i386, for other architectures it may not make sense to have the a.out stuff, as they maybe never seen any a.out Linux binary).

The ELF AUX args

When an ELF image is executed, the Linuxulator adds some runtime information (like pagesize, uid, guid, …) so that the userland can query this information which is not static at build-time easily. This is handled in the elf_linux_fixup function(). If you see some error messages about missing ELF notes from e.g. glibc, this is the place to add this information to. It would not be bad from time to time to have a look what Linux is providing and missing pieces there. FreeBSD does not has an automated way of doing this, and I am not aware of someone who regularly checks this. There is a little bit more info about ELF notes available in a message to one of the FreeBSD mailing lists, it also has an example how to read out this data.

Traps

Linux and FreeBSD do not share the same point of view how a trap shall be handled (SIGBUS or SIGSEGV), the corresponding decision making is handled in translate_traps() and a translation table is available as _bsd_to_linux_trapcode.

Signals

The values for the signal names are not the same in FreeBSD and Linux. The translation tables are called linux_to_bsd_signal and bsd_to_linux_signal. The translation is a feature of the syscall vector (= automatic).

Errnos

The values for the errno names are not the same in FreeBSD and Linux. The translation table is called bsd_to_linux_errno. Returning an errno in one of the Linux syscalls will trigger an automatic translation from the FreeBSD errno value to the Linux errno value. This means that FreeBSD errnos have to be returned (e.g. FreeBSD ENOSYS=78) and the Linux program will receive the Linux value (e.g. Linux ENOSYS=38, and as the Linux kernel returns negative errnos, the linux program will get –38).

If you see somewhere an “-ESOMETHING� in the Linuxulator code, this is either a bug, or some clever/tricky/dangerous use of the sign-bit to encode some info (e.g. in the futex code there is a function which returns –ENOSYS, but the sign-bit is used as an error indicator and the calling code is responsible to translate negative errnos into positive ones).

Syscalls

The Linux syscalls are defined similar to the FreeBSD ones. There is a mapping table (sys/linux/syscalls.master) between syscall numbers and the corresponding functions. This table is used to generate code (“make sysent� in sys//linux/) which does what is necessary.

Share

Kernel features patchset (from GSoC 2010)

I am playing around with the patchset “my� student generated during this years GSoC (the code for all projects is available from Google). In short, it gives you the possibility to query from userland, which optional kernel features are available. I have let him mostly do those features, which are not so easy to detect from userland, or where the detection could trigger an autoload of a kernel module.

I let the output speak for himself, first the output before his patchset:

kern.features.compat_freebsd7: 1
kern.features.compat_freebsd6: 1
kern.features.posix_shm: 1

And now with his patchset:

kern.features.compat_freebsd6: 1
kern.features.compat_freebsd7: 1
kern.features.ffs_snapshot: 1
kern.features.geom_label: 1
kern.features.geom_mirror: 1
kern.features.geom_part_bsd: 1
kern.features.geom_part_ebr: 1
kern.features.geom_part_ebr_compat: 1
kern.features.geom_part_mbr: 1
kern.features.geom_vol: 1
kern.features.invariant_support: 1
kern.features.kdtrace_hooks: 1
kern.features.kposix_priority_scheduling: 1
kern.features.ktrace: 1
kern.features.nfsclient: 1
kern.features.nfsserver: 1
kern.features.posix_shm: 1
kern.features.pps_sync: 1
kern.features.quota: 1
kern.features.scbus: 1
kern.features.softupdates: 1
kern.features.stack: 1
kern.features.sysv_msg: 1
kern.features.sysv_sem: 1
kern.features.sysv_shm: 1
kern.features.ufs_acl: 1

With his patches we have a total of 84 kernel features which can be queried (obviously I do not have all optional options enabled in the kernel which produces this output). All of the features also have a description, and it is easy to add more features. As an example I present what is necessary to produce the kern.features.stack output:

./kern/subr_stack.c:FEATURE(stack, “Support for capturing kernel stack�);

There is also a little userland application (and a library interface) which allows to query several features from scripts/applications with the possibility to pretend a feature is not there (the requirement for this was for ports; pretending a feature is there if it is not was ruled out because such run-time detection is only necessary for things which have to run soon and pretending some feature is there while it is not will cause big problems). Unfortunately the man page for the application is not yet ready, but I’m sure you can figure out how to use it.

The names of the features and the description follows an easy scheme, what is written down in NOTES is used as a name and a description for the feature (an exception is geom_part_X, there we decided to use a common theme (“GEOM partitioning class for XXX�) which is distinct from the corresponding geom_X class). If you have complains about what is used in a specific feature, do not complain to him: change it in NOTES and the feature will follow.

If you have questions, suggestions, or some other interest to contact him, his FreeBSD address is kibab@. Feel free to encourage him to go ahead with the next steps (finishing the man page, splitting up the patches into sensible pieces and presenting them on appropriate mailinglists for review). :-)

Share

ZFS and NFS / on-disk-cache

In the FreeBSD mailinglists I stumbled over  a post which refers to a blog-post which describes why ZFS seems to be slow (on Solaris).

In short: ZFS guarantees that the NFS client does not experience silent corruption of data (NFS server crash and loss of data which is supposed to be already on disk for the client). A recommendation is to enable the disk-cache for disks which are completely used by ZFS, as ZFS (unlike UFS) is aware of disk-caches. This increases the performance to what UFS is delivering in the NFS case.

There is no in-deep description of what it means that ZFS is aware of disk-caches, but I think this is a reference to the fact that ZFS is sending a flush command to the disk at the right moments. Letting aside the fact that there are disks out there which lie to you about this (they tell the flush command finished when it is not), this would mean that this is supported in FreeBSD too.

So everyone who is currently disabling the ZIL to get better NFS performance (and accept silent data corruption on the client side): move your zpool to dedicated (no other real FS than ZFS, swap and dump devices are OK) disks (honest ones) and enable the disk-caches instead of disabling the ZIL.

I also recommend that people which have ZFS already on dedicated (and honest) disks have a look if the disk-caches are enabled.

Share

v4l support in the linuxulator MFCed to 8-stable

I merged the v4l translation layer into the linuxulator of 8-stable. As in –current, this just means that linux apps (like Skype) can now use FreeBSD native devices which conform to the v4l ABI. The port multimedia/webcamd provides access to some webcams (or DVB hardware) via the v4l ABI.

People which want to test the linuxulator part should first make sure a native FreeBSD application has no problem accessing the device.

Share

WITH_CTF is really usable now

I just committed a patch which makes WITH_CTF usable now.

Yes, you could use it before, but you had to remember to specify it at each build. Now you can add it to your kernel config (via makeoptions), and then you can forget about it.

Thanks to jhb and imp for review and suggestions.