I am play­ing around with the patch­set “my” stu­dent gen­er­ated dur­ing this years GSoC (the code for all projects is avail­able from Google). In short, it gives you the pos­si­bil­ity to query from user­land, which optional ker­nel fea­tures are avail­able. I have let him mostly do those fea­tures, which are not so easy to detect from user­land, or where the detec­tion could trig­ger an autoload of a ker­nel mod­ule.

I let the out­put speak for him­self, first the out­put 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 ker­nel fea­tures which can be queried (obvi­ously I do not have all optional options enabled in the ker­nel which pro­duces this out­put). All of the fea­tures also have a descrip­tion, and it is easy to add more fea­tures. As an exam­ple I present what is nec­es­sary to pro­duce the kern.features.stack output:

./kern/subr_stack.c:FEATURE(stack, “Sup­port for cap­tur­ing ker­nel stack”);

There is also a lit­tle user­land appli­ca­tion (and a library inter­face) which allows to query sev­eral fea­tures from scripts/applications with the pos­si­bil­ity to pre­tend a fea­ture is not there (the require­ment for this was for ports; pre­tend­ing a fea­ture is there if it is not was ruled out because such run-time detec­tion is only nec­es­sary for things which have to run soon and pre­tend­ing some fea­ture is there while it is not will cause big prob­lems). Unfor­tu­nately the man page for the appli­ca­tion is not yet ready, but I’m sure you can fig­ure out how to use it.

The names of the fea­tures and the descrip­tion fol­lows an easy scheme, what is writ­ten down in NOTES is used as a name and a descrip­tion for the fea­ture (an excep­tion is geom_part_X, there we decided to use a com­mon theme (“GEOM par­ti­tion­ing class for XXX”) which is dis­tinct from the cor­re­spond­ing geom_X class). If you have com­plains about what is used in a spe­cific fea­ture, do not com­plain to him: change it in NOTES and the fea­ture will follow.

If you have ques­tions, sug­ges­tions, or some other inter­est to con­tact him, his FreeBSD address is kibab@. Feel free to encour­age him to go ahead with the next steps (fin­ish­ing the man page, split­ting up the patches into sen­si­ble pieces and pre­sent­ing them on appro­pri­ate mail­inglists for review).

I counted 18 projects which are given to FreeBSD in this years GSoC. For 3 of them I have some comments.

Very inter­est­ing to me is the project which is named Col­lec­tive lim­its on set of processes (a.k.a. jobs). This looks a bit like the Solaris contract/project IDs. If this project results in some­thing which allows the user­land to query which PID belongs to which set, than this allows some nice improve­ment for start scripts. For exam­ple at work on Solaris each appli­ca­tion is a mix of sev­eral projects (apache = “name:web” project, tom­cat = “name:app” project, Ora­cle DB = “name:ora” project). Our man­age­ment frame­work (writ­ten by a co-worker) allows to eas­ily do some­thing with those projects, a “show” dis­plays the prstat (sim­i­lar to top) info just for processes which belong to the project, a “kill” sends a kill-signal to all processes of the project, and so on. We could do some­thing sim­i­lar with our start scripts by declar­ing a name­space (FreeBSD:base:XXX / FreeBSD:ports:XXX?) and maybe num­ber space (depend­ing on the imple­men­ta­tion) as reserved and use it to see if processes which belong to a par­tic­u­lar script are still run­ning or kill them or whatever.

The other two projects I want to com­ment upon here are Com­plete libpkg and cre­ate new pkg tools and Com­plete Pack­age sup­port in the pkg_install tools and cleanup. Both projects ref­er­ence libpkg in their descrip­tion. I hope the men­tors of both projects pay some atten­tion to what is going on in the other project to not cause depen­den­cies/clashes between the students.

That I do not men­tion other projects does not mean that they are not inter­est­ing or sim­i­lar, it is just that I do not have to say some­thing valu­able about them…

Seems that I will actively men­tor again in this Google Sum­mer of Code (as opposed to just review the sub­mis­sions from stu­dents and/or act­ing as a fall-back mentor).

The project I will men­tor is the “Make optional ker­nel sub­sys­tems reg­is­ter them­selves via sysctl”-one from the FreeBSD ideas page.

The stu­dent already got into con­tact with me and it looks like he is moti­vated (he is already sub­scribed to sev­eral FreeBSD mail­inglists, which is not a require­ment we have in our GSoC docs).

I stum­bled over Google’s new RE engine. Unfor­tu­nately it is not han­dling back­ref­er­ences, so it is not a drop-in replace­ment for the reg­u­lar expres­sions code in FreeBSD. It has a POSIX mode, but this only seems to be enough for the egrep syn­tax. For peo­ple which need back­ref­er­ences, they refer to the Google Chrome’s RE engine irreg­exp which in turn ref­er­ences a paper from 2007 which is titled Reg­u­lar Expres­sion Match­ing Can Be Sim­ple And Fast.

The tech­niques in the paper can not be applied to the irreg­exp engine, but maybe could help to speed up awk, egrep and sim­i­lar programs.

I think it would be inter­est­ing to com­pare those recent devel­op­ments to what we have in FreeBSD, and if they are faster, to see if it is pos­si­ble to improve the FreeBSD imple­men­ta­tion based upon them (either by writ­ing new code, or by import­ing exist­ing code, depend­ing on the cor­re­spond­ing license and the lan­guage the code is writ­ten in).

Maybe a can­di­date for the GSoC?

The lin­ux­u­la­tor is synced on amd64 with i386 (since a while). This means TLS is work­ing now and we have the same (a lit­tle bit buggy) futexes.

Roman is slowly work­ing on the *at() com­mands. He also applied for the GSoC this year again. Kib is will­ing to men­tor (in case Roman gets a free seat in the SoC). I rejected the men­tor­ing posi­tion this time, as I don’t know if I will have enough time this sum­mer, but I hope I will be around.