Archive for the 'kernel' Category

Alexander Leidinger: Linuxulator D-Trace probes committed to current

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: linux_base-c6

Seems I forgot to announce that the linux_base-c6 is in the Ports Collection now. Well, it is not a replacement for the current default linux base, the linuxulator infrastructure ports are missing and we need to check if the kernel supports enough of 2.6.18 that nothing breaks.

TODO:

To my knowledge, nobody is working on anything of this. Anyone is welcome to have a look and provide patches.

Share

Alexander Leidinger: DTrace in GENERIC (-current)

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: Linuxulator progress

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

Alexander Leidinger: Sockets and nullfs: works now in –current

I just updated to a recent -current and tried the new nullfs. Sockets (e.g. the MySQL one) work now with nullfs. No need to have e.g. jails on the same FS and hardlink the socket to not need to use TCP in MySQL (or an IP at all for the jail).

Great work!

Share

Alexander Leidinger: 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

Alexander Leidinger: New CentOS linux_base for testing soonish

It seems my HOWTO create a new linux_base port was not too bad. There is now a PR for a CentOS 6 based linux_base port. I had a quick look at it and it seems that it is nearly usable to include into the Ports Collection (the SRPMs need to be added, but that can be done within some minutes).

When FreeBSD 8.3 is released and the Ports Collection open for sweeping commits again, I will ask portmgr to do a repo-copy for the new port and commit it. This is just the linux_base port, not the complete infrastructure which is needed to completely replace the current default linuxulator userland. This is just a start. The process of switching to a more recent linux_base port is a long process, and in this case depends upon enough support in the supported FreeBSD releases.

Attention: Anyone installing the port from the PR should be aware that using it is a highly experimental task. You need to change the linuxulator to impersonate himself as a linux 2.6.18 kernel (described in the pkg-message of the port), and the code in FreeBSD is far from supporting this. Anyone who wants to try it is welcome, but you have to run FreeBSD-current as of at least the last weekend, and watch out for kernel messages about unsupported syscalls. Reports to [email protected] please, not here on the webpage.

Share

Alexander Leidinger: 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

Alexander Leidinger: More drivers available in the FreeBSD-kernel doxygen docs

Yesterday I committed some more configs to generate doxygen documentation of FreeBSD-kernel drivers. I mechanically generated missing configs for subdirectories of src/sys/dev/. This means there is no dependency information included in the configs, and as such you will not get links e.g. to the PCI documentation, if a driver calls functions in the PCI driver (feel free to tell me about such dependencies).

If  you want to generate the HTML or PDF version of some subsystem, just go to src/tools/kerneldoc/subsys/ an run “make� to get a list of targets to build. As an example, “make dev_sound� will generate the HTML version for the sound system, “make pdf-dev_sound� generates the PDF version. The sound system is probably the most “nice� example, as it includes a page with TODO items, and has even some real API docs instead of just the call-graphs and such automatically generated information.

Some drivers already have (some) doxygen markup (I did just a quick grep for ‘/*[*!]’ to detect doxygen markup indicators, no idea about the coverage or quality), namely:

There is more documentation than only for those drivers, I just listed those as there are at least parts of doxygen documentation inside.

Share

Alexander Leidinger: 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

Alexander Leidinger: 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

Alexander Leidinger: 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

Alexander Leidinger: 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

Alexander Leidinger: 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

Alexander Leidinger: 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

Alexander Leidinger: 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

Alexander Leidinger: AQM/ECN in FreeBSD

After reading Jim Gettys investigations about the problems current buffer sizes of network equipment provoke (which may even have implications in the net neutrality debate), I had a look at which active queue management (AQM) algorithms with or without explicit congestion notification (ECN) FreeBSD supports.

It looks like there is not much implemented (if the best solution would be implemented, it would not matter how much there is, but unfortunately there is no best solution). Other systems offer more. RED is implemented, but even the inventor/researcher of RED thinks the algorithm needs some improvements (he is in the process of preparing a paper about this, as Jim Gettys reveals). Blue/SFBlue is not implemented (a more turnkey-solution than the current RED implementation). PID controller (which may or may not be something someone wants to use in this case… no idea about its pros/cons in this regard, but it is referenced in the AQM article on Wikipedia) is also not implemented.

Regarding ECN for FreeBSD you can find more or less no real documentation in the net (at least with a simple “ECN FreeBSD� search). It is implemented for the RED algorithm, but as the RED algorithm needs some tuning/setup, this is not a turnkey solution. There is a ECN related sysctl, but I do not have the impression that this is a turnkey-solution which magically generates ECN messages without using dummynet for AQM.

From my current understanding (but I think I do not know a lot about this topic) it looks like AQM is a feature most people would like to have activated by default (with an appropriate algorithm which does not need tuning to produce a good enough result). If this is correct, it is a shame that FreeBSD does not activate AQM with an algorithm which is not bad for most cases by default (with the option to change the algorithm and to disable completely). If my understanding is not correct, I would like to get a hit with the clue bat please.

Share

Alexander Leidinger: How big are the buffers in FreeBSD drivers?

Today I have read an interesting investigation and problem analysis from Jim Gettys.

It is a set of articles he wrote over several months and is not finished writing as of this writing (if you are deeply interested in it go and read them, the most interesting ones are from December and January and the comments to the articles are also contributing to the big picture). Basically he is telling that a lot of network problems users at home (with ADSL/cable or WLAN) experience  are because buffers in the network hardware or in operating systems are too big. He also proposes workarounds until this problem is attacked by OS vendors and equipment manufacturers.

Basically he is telling the network congestion algorithms can not do their work good, because the network buffers which are too big come into the way of their work (not reporting packet loss timely enough respectively try to not lose packets in situations where packet loss would be better because it would trigger action in the congestion algorithms).

He investigated the behavior of Linux, OS X and Windows (the system he had available). I wanted to have a quick look at the situation in FreeBSD regarding this, but it seems at least with my network card I am not able to see/find the corresponding size of the buffers in drivers in 30 seconds.

I think it would be very good if this issue is investigated in FreeBSD, and apart from maybe taking some action in the source also write some section for the handbook which explains the issue (one problem here is, that there are situations where you want/need to have such big buffers and as such we can not just downsize them) and how to benchmark and tune this.

Unfortunately I even have too much on my plate to even further look into this. :( I hope one of the network people in FreeBSD is picking up the ball and starts playing.

Share

Alexander Leidinger: 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

Alexander Leidinger: 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