Ad­di­tional FEATURE mac­ros on the way

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

As part of this I already com­mit­ted the UFS/​FFS re­lated FEATURE mac­ros which where de­veloped by kibab@ dur­ing the Google Sum­mer of Code 2010. The net­work/​ALTQ re­lated FEATURE mac­ros are in the hands of bz@, he already re­viewed them and wants to com­mit them (with some changes) as part of his im­prove­ments of parts of the net­work re­lated code.

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

If everything is com­mit­ted, it should look a bit like this if quer­ied from user­land (not all fea­tures are shown, those are just the ones which are en­abled in the ker­nel in one of my ma­chines):

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

StumbleUponXINGBalatarinBox.netDiggGoogle GmailNetvouzPlurkSiteJotTypePad PostYahoo BookmarksVKSlashdotPocketHacker NewsDiigoBuddyMarksRedditLinkedInBibSonomyBufferEmailHatenaLiveJournalNewsVinePrintViadeoYahoo MailAIMBitty BrowserCare2 NewsEvernoteMail.RuPrintFriendlyWaneloYahoo MessengerYoolinkWebnewsStumpediaProtopage BookmarksOdnoklassnikiMendeleyInstapaperFarkCiteULikeBlinklistAOL MailTwitterGoogle+PinterestTumblrAmazon Wish ListBlogMarksDZoneDeliciousFlipboardFolkdJamespotMeneameMixiOknotiziePushaSvejoSymbaloo FeedsWhatsAppYouMobdiHITTWordPressRediff MyPageOutlook.comMySpaceDesign FloatBlogger PostApp.netDiary.RuKindle ItNUjijSegnaloTuentiWykopTwiddlaSina WeiboPinboardNetlogLineGoogle BookmarksDiasporaBookmarks.frBaiduFacebookGoogle ClassroomKakaoQzoneSMSTelegramRenrenKnownYummlyShare/​Save

Ker­nel fea­tures patch­set (from GSoC 2010)

I am play­ing around with the patch­set “my” stu­dent gen­er­ated dur­ing this years GSoC (the code for all pro­jects is avail­able from Google). In short, it gives you the pos­sib­il­ity to query from user­land, which op­tional ker­nel fea­tures are avail­able. I have let him mostly do those fea­tures, which are not so easy to de­tect from user­land, or where the de­tec­tion could trig­ger an auto­load of a ker­nel mod­ule.

I let the out­put speak for him­self, first the out­put be­fore his patch­set:

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

And now with his patch­set:

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 quer­ied (ob­vi­ously I do not have all op­tional op­tions en­abled in the ker­nel which pro­duces this out­put). All of the fea­tures also have a de­scrip­tion, and it is easy to add more fea­tures. As an ex­ample I present what is ne­ces­sary to pro­duce the kern.features.stack out­put:

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

There is also a little user­land ap­plic­a­tion (and a lib­rary in­ter­face) which al­lows to query sev­eral fea­tures from scripts/​applications with the pos­sib­il­ity to pre­tend a fea­ture is not there (the re­quire­ment for this was for ports; pre­tend­ing a fea­ture is there if it is not was ruled out be­cause such run-​time de­tec­tion is only ne­ces­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). Un­for­tu­nately the man page for the ap­plic­a­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 de­scrip­tion fol­lows an easy scheme, what is writ­ten down in NOTES is used as a name and a de­scrip­tion for the fea­ture (an ex­cep­tion is geom_​part_​X, there we de­cided to use a com­mon theme (“GEOM par­ti­tion­ing class for XXX”) which is dis­tinct from the cor­res­pond­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 fol­low.

If you have ques­tions, sug­ges­tions, or some other in­terest to con­tact him, his FreeBSD ad­dress is kibab@. Feel free to en­cour­age him to go ahead with the next steps (fin­ish­ing the man page, split­ting up the patches into sens­ible pieces and present­ing them on ap­pro­pri­ate mailing­lists for re­view). :-)

In­ter­est­ing pro­jects in the GSoC

I coun­ted 18 pro­jects which are given to FreeBSD in this years GSoC. For 3 of them I have some com­ments.

Very in­ter­est­ing to me is the pro­ject which is named Col­lect­ive lim­its on set of pro­cesses (a.k.a. jobs). This looks a bit like the Sol­aris contract/​project IDs. If this pro­ject res­ults in some­thing which al­lows the user­land to query which PID be­longs to which set, than this al­lows some nice im­prove­ment for start scripts. For ex­ample at work on Sol­aris each ap­plic­a­tion is a mix of sev­eral pro­jects (apache = “name:web” pro­ject, tom­cat = “name:app” pro­ject, Or­acle DB = “name:ora” pro­ject). Our man­age­ment frame­work (writ­ten by a co-​worker) al­lows to eas­ily do some­thing with those pro­jects, a “show” dis­plays the prstat (sim­ilar to top) info just for pro­cesses which be­long to the pro­ject, a “kill” sends a kill-​signal to all pro­cesses of the pro­ject, and so on. We could do some­thing sim­ilar with our start scripts by de­clar­ing a namespace (FreeBSD:base:XXX /​ FreeBSD:ports:XXX?) and maybe num­ber space (de­pend­ing on the im­ple­ment­a­tion) as re­served and use it to see if pro­cesses which be­long to a par­tic­u­lar script are still run­ning or kill them or whatever.

The other two pro­jects 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 pro­jects ref­er­ence libpkg in their de­scrip­tion. I hope the ment­ors of both pro­jects pay some at­ten­tion to what is go­ing on in the other pro­ject to not cause dependencies/​clashes between the stu­dents.

That I do not men­tion other pro­jects does not mean that they are not in­ter­est­ing or sim­ilar, it is just that I do not have to say some­thing valu­able about them…

HOWTO mentor in the GSoC (ini­tial com­mu­nic­a­tion with the stu­dent)

Every mentor in the GSoC has a dif­fer­ent way of hand­ling stu­dents. Here is what I do.

The stu­dent in­tro­duced him­self to me as re­ques­ted by our soc–ad­mins in the ini­tial mail to our stu­dents. He looked up in which timezone I am (pub­lic info) and presen­ted his timezone (and rough loc­a­tion) to me. That is nice. He also offered dif­fer­ent com­mu­nic­a­tion chan­nels (ba­sic­ally EMail and IM).

I con­firmed what he looked up, and presen­ted what I did in the past GSoC in which I par­ti­cip­ated 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 ex­plan­a­tions or ques­tions are bet­ter handled via EMail. I also gave him a rough over­view when he can ex­pect quick an­swers from me and when I am not avail­able.

Fol­low­ing are some ques­tions I asked him, so that I get an im­pres­sion about what to ex­pect and that I can plan a bit (some of those may already be told in stu­dent ap­plic­a­tion, but I prefer to have everything in one place):

  • From when to when do you in­tent to spend how much time for the GSoC?
  • Any hol­i­days /​ non-​availability planned dur­ing the GSoC?
  • Any uni­ver­sity–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 know­ledge do you see your­self re­gard­ing computer-​science/​programming/​OS-​concepts (re­l­at­ive to other stu­dents and re­l­at­ive to the topic)?
  • How do you want to start about the pro­ject (where do you want to start, what do you in­tent to do… just a quick over­view… a bit more than say­ing “I add X”, but not as far as copy&paste of code ex­amples)?

More im­port­ant than that (IMO), is to give an idea what is ex­pec­ted from the stu­dent:

  • you have FreeBSD–cur­rent in­stalled (on a real PC or in a vir­tual ma­chine)
  • you give me a re­port about the status each week (“did noth­ing” is also a valid re­port, it gives me the info that you are still alive and did not lose in­terest in the GSoC)
  • if your sched­ule changes in a sig­ni­fic­ant way, give me a little no­ti­fic­a­tion (e.g. “I can not do any­thing next week”)
  • if you spend more than 30 minutes with a prob­lem, pre­pare an email with the prob­lem de­scrip­tion; if this pre­par­a­tion did not solve your prob­lem, send me the mail (if you solve the prob­lem 5 minutes later, no prob­lem, I prefer to get a mail too much than to have you stuck with some­thing for an in­cred­ible amount of time)

A mentor does not know everything, 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 pro­ject he is work­ing on, then to this mail­ing list too. This al­lows the mentor to tell the stu­dent to send a mail with the ques­tions to one of those lists without much pre­par­a­tion to re­ceive all an­swers.

An­other help­ful re­source is the FreeBSD ker­nel cross-​reference. For some people my doxy­gen gen­er­ated docs of parts of the FreeBSD ker­nel may be help­ful (put un­for­tu­nately not a lot of doxy­gen–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 be­fore the GSoC ends to an ap­pro­pri­ate mail­ing list, and that com­ments from there re­gard­ing changes he must or shall do are not some­thing bad, but a way to im­prove the res­ult and/​or his skills.

Ment­or­ing again in the GSoC

Seems that I will act­ively mentor again in this Google Sum­mer of Code (as op­posed to just re­view the sub­mis­sions from stu­dents and/​or act­ing as a fall-​back mentor).

The pro­ject I will mentor is the “Make op­tional ker­nel sub­sys­tems re­gister them­selves via sy­sctl”-one from the FreeBSD ideas page.

The stu­dent already got into con­tact with me and it looks like he is mo­tiv­ated (he is already sub­scribed to sev­eral FreeBSD mailing­lists, which is not a re­quire­ment we have in our GSoC docs).