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

As part of this I already com­mit­ted the UFS/FFS related FEATURE macros which where devel­oped by kibab@ dur­ing the Google Sum­mer of Code 2010. The net­work/ALTQ related FEATURE macros are in the hands of bz@, he already reviewed them and wants to com­mit them (with some changes) as part of his improve­ments of parts of the net­work related code.

The GEOM related FEATURE macros I just send some min­utes 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 every­thing is com­mit­ted, it should look a bit like this if queried from user­land (not all fea­tures are shown, those are just the ones which are enabled in the ker­nel 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

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…

Every men­tor in the GSoC has a dif­fer­ent way of han­dling stu­dents. Here is what I do.

The stu­dent intro­duced him­self to me as requested by our soc-admins in the ini­tial mail to our stu­dents. He looked up in which time­zone I am (pub­lic info) and pre­sented his time­zone (and rough loca­tion) to me. That is nice. He also offered dif­fer­ent com­mu­ni­ca­tion chan­nels (basi­cally EMail and IM).

I con­firmed what he looked up, and pre­sented what I did in the past GSoC in which I par­tic­i­pated so that he has an idea if am new to the game or not. I told him that quick/short ques­tions are bet­ter asked via IM, while long expla­na­tions or ques­tions are bet­ter han­dled via EMail. I also gave him a rough overview when he can expect quick answers from me and when I am not available.

Fol­low­ing are some ques­tions I asked him, so that I get an impres­sion about what to expect and that I can plan a bit (some of those may already be told in stu­dent appli­ca­tion, but I pre­fer to have every­thing in one place):

• From when to when do you intent to spend how much time for the GSoC?
• Any hol­i­days / non-availability planned dur­ing the GSoC?
• Any university-stuff (exams/lessons/…) dur­ing this time (the uni has higher pri­or­ity than the GSoC for Google)?
• Any­thing else in par­al­lel of the GSoC (some paid work, tak­ing care about ill (grand-)parents, …)?
• At what level of knowl­edge do you see your­self regard­ing computer-science/programming/OS-concepts (rel­a­tive to other stu­dents and rel­a­tive to the topic)?
• How do you want to start about the project (where do you want to start, what do you intent to do… just a quick overview… a bit more than say­ing “I add X”, but not as far as copy&paste of code examples)?

More impor­tant than that (IMO), is to give an idea what is expected from the student:

• you have FreeBSD–cur­rent installed (on a real PC or in a vir­tual machine)
• you give me a report about the sta­tus each week (“did noth­ing” is also a valid report, it gives me the info that you are still alive and did not lose inter­est in the GSoC)
• if your sched­ule changes in a sig­nif­i­cant way, give me a lit­tle noti­fi­ca­tion (e.g. “I can not do any­thing next week”)
• if you spend more than 30 min­utes with a prob­lem, pre­pare an email with the prob­lem descrip­tion; if this prepa­ra­tion did not solve your prob­lem, send me the mail (if you solve the prob­lem 5 min­utes later, no prob­lem, I pre­fer to get a mail too much than to have you stuck with some­thing for an incred­i­ble amount of time)

A men­tor does not know every­thing, off course, so the stu­dent should be sub­scribed to hackers@ and current@, and if there is a spe­cific list which matches good to the project he is work­ing on, then to this mail­ing list too. This allows the men­tor to tell the stu­dent to send a mail with the ques­tions to one of those lists with­out much prepa­ra­tion to receive all answers.

Another help­ful resource is the FreeBSD ker­nel cross-reference. For some peo­ple my doxy­gen gen­er­ated docs of parts of the FreeBSD ker­nel may be help­ful (put unfor­tu­nately not a lot of doxygen-markup is within our source code).

I also told that he shall pre­pare him­self that I will ask him to send a ref­er­ence to a patch of his work long enough before the GSoC ends to an appro­pri­ate mail­ing list, and that com­ments from there regard­ing changes he must or shall do are not some­thing bad, but a way to improve the result and/or his skills.

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).