SoC 2006 fin­ished (sound pro­ject com­mit­ted)

I com­mit­ted the stuff from the sound pro­ject just a few minutes ago. So the SoC 2006 has of­fi­cially ended for me (I just wait for the T-​Shirt now… 🙂 ).

This doesn’t mean I don’t care about the stuff any­more. I will com­mit fixes in case prob­lems show up and I’m also re­spons­ible in case my ex-​mentees have ques­tions or patches. It’s just that the of­fi­cial part is done now.

Happy bughunt­ing to all.

linuxolat­or SoC work com­mit­ted

I com­mit­ted most of Ro­mans work in the linuxolat­or to cur­rent. The new sy­scalls aren’t used un­til you run

sy­sctl com­pat.linux.osrelease=2.6.16

to switch back (after ex­it­ing all linux pro­grams) you just have to run

sy­sctl compat.linux.osrelease=2.4.2

But you have to do this on i386. Amd64 sup­port is not com­plete (and be­sides this, amd64 is still broken and nobody provided the nec­cessary de­bug­ging info to jhb@).

There are some known prob­lems with osrelease=2.6.16, e.g., prob­lems with fu­texes (vis­ible in acror­ead, real­play and skype), but some pro­grams already run without ob­vi­ous prob­lems (linux–fire­fox, linux-​opera).

Any re­ports about new prob­lems to netchild@ and rdivacky@ please. Re­views, de­bug­ging info and patches are wel­come too.

linuxolat­or day

A happy wel­come to Bor­is Sam­oro­dov to the ports com­mit­ters team (I’m his ment­or). This means I don’t have the bur­den to take care of the linuxolat­or in­fra­struc­ture in the Ports Col­lec­tion alone any­more. Yeah!

Today I com­mit­ted an­oth­er part of Roman’s work in the linuxolat­or SoC. Now we should get log mes­sages for the new miss­ing sy­scalls for real. We defin­it­ively need high level over­view doc­u­ments for sub­sys­tems.

COMPAT_​43, SoC and stuff

I just re­moved the COMPAT_​43 op­tion from the GENERIC ker­nel in cur­rent. This may res­ult in in­creased per­form­ance for some work­loads.

In the last days I also “ment­ored” a little bit my SoC stu­dents. Re­view­ing some changes, sug­gest­ing some im­rove­ments, com­mit­ting some stuff which is ready, dis­cuss­ing vari­ous things and so on.

And last but not least, I hope that the last bugs in the up­date to the new linux base port are ironed out on the ports build cluster (I did some com­mits in the last days).

Bikesheds, FC4 and SoC

The last week has seen some bikesheds. One of them was my com­mit of the doxy­gen in­fra­struc­ture for the ker­nel sub­sys­tems. Some people don’t like the way doxy­gen re­quires some markup tags in the com­ments, some people don’t think such API docs provide ad­di­tion­al value and some people fear that 3rd party de­velopers may use some func­tions which shouldn’t be used. I don’t re­peat the counter-​arguments of my­self and oth­er people here, but there are people out there which already make use of the cur­rent un­sat­is­fact­ory doxy­gen out­put and are happy about this in­fra­struc­ture. Luck­ily is was su­per­seeded by an­oth­er bikeshed (and gnn@ wants to work on doc­u­ment­ing a sub­sys­tem to show the be­ne­fits to those people which do not think yet, that this is a good idea). On a re­lated is­sue, I’m wait­ing on a repo copy of src/​sys/​doc to src/​tools (it’s one of two repo cop­ies I’m wait­ing for, ncvs@ seems to be bussy ATM). Some doc@ people think it is more ap­pro­pri­ate there.

The FC4 linux base port and the xorg based linux X11 libs port are sched­uled for test­ing in an ex­per­i­ment­al ports build run, we may see the switch of the de­fault linux base port in the not so dis­tant fu­ture. It seems Bor­is is work­ing on up­dates to the rest of the linuxolat­or in­fra­struc­ture in the Ports Col­lec­tion (gtk, …), so we may see a lot of up­dates there after the switch of the de­fault linux base port.

In the last days I also helped/​talked with my SoC stu­dents. Ro­man is play­ing a little bit with an amd64 tinder­box he got ac­cess to and as a res­ult he com­mit­ted sup­port for build­ing the linuxolat­or on amd64 as a mod­ule to per­force (call for test­ers: he did send a patch to emulation@, please give it a try if you own an amd64 box). Ry­an is cata­loging the IOCTL’s and their status (im­ple­men­ted, ob­sol­ete, …) in the FreeBSD wiki. I already pr­i­or­ized those he did so far, and gave some sug­ges­tions how to pro­ceed with the im­port­ant ones. This way he hasn’t to wait for me or Ar­iff when he is fin­ished with the cata­loging (be­ing a ment­or liv­ing in a dif­fer­ent time zone means you should be ahead of your stu­dent… be­ing ahead even be­fore he is able to asks ques­tions is … a boost for your own ego 😉 ).


Since Ro­man wanted to cre­ate his linuxolat­or branch in per­force, I had to make my­self fa­mil­i­ar with per­force too, to be able to an­swer his ques­tions. I learned my first steps in per­force by cre­at­ing the sound branch (I’m ment­or­ing Ry­an to­geth­er with Ar­iff). Cre­at­ing the branch was not hard, but I man­aged to fail in some way… I used the wrong user­name part for Ryan’s branch name (“rbeas­ley” in­stead of “ry­anb”). I think this means I shouldn’t trust my memory and double-​check such facts in the fu­ture. Since it’s only a namespace is­sue to not have con­flicts when sev­er­al people want to cre­ate branches with the same name (but a dif­fer­ent se­mant­ic of what has to be done there), I don’t think it mat­ters.

Ro­man hadn’t as much “luck” than I had. He for­got to add a „/​“ in an im­port­ant place which res­ul­ted in files like “…_​linuxolatoramd64/​…” in­stead of “…_​linuxolator/​amd64/​…” while branch­ing. While ICQ is nice to dis­cuss some­thing in real-​time over large dis­tances, you can’t look over the shoulder of someone. Mea culpa (stu­dents which are ex­cited and eager to try some­thing… I think I re­mem­ber how this feels 😉 ). He is resolv­ing this as I write this.

While I see some be­ne­fits in the way per­force is work­ing (seems to al­low some power­ful things we can’t do with CVS), I have to say the per­form­ance sucks when cre­at­ing branches (I did it at home via DSL and a com­pressed ssh tun­nel to the per­force serv­er, not on freefall where it should have been much faster). But I didn’t cre­ated a FreeBSD branch with CVS, so maybe CVS sucks more when do­ing this. 🙂

In­ter­est­ing Sum­mer for FreeBSD

Now that we have (or “soon will have”) an of­fi­cial FreeBSD blog, I de­cided to give this kind of elec­tron­ic and pub­lic di­ary a try. At least to re­port the status and pro­gress of some FreeBSD re­lated pro­jects I’m in­volved in.

A lot happened in the last days. We’re past the dead­line of the Google Sum­mer of Code rat­ing pro­cess and now the lucky stu­dents are chosen. It wasn’t easy. We had more than 120 pro­pos­als (out of ~6400). From those we where will­ing to ment­or 40 – 50 (based upon our re­sources and the qual­ity of the pro­pos­als). Google gran­ted 14 to us (a big thank you to Google!). I ex­pect an of­fi­cial an­nounce­ment “soon”. Hope­fully some of those stu­dents Google wasn’t able to fund are will­ing to work with us re­gard­less of the money, there are a lot of very nice pro­pos­als (I will add some items to the ideas list based upon them later). We’re at least will­ing to provide the same amount of ment­or­ship as if they where se­lec­ted.

I will work with two stu­dents. One of them will work on syncing the OSS API from re­cent re­leases from 4Front with our sound sys­tem. The oth­er one will work on im­prov­ing the linuxolat­or. I will an­nounce this on the cor­res­pond­ing mailing­lists after the of­fi­cial an­nounce­ment. ATM we need to do some ad­min­is­trat­ive stuff (hand­ing out ac­cess to the wiki and per­force, set­ting up email ali­ases, …).

I already mailed some gen­er­al guides to the stu­dents (note to ment­ors: it’s in the wiki on the “hid­den” and re­stric­ted to ment­ors SoC page). For the sound stuff I don’t have a nice TODO list, but luck­ily the stu­dent already in­vest­ig­ated the 4Front stuff for the pro­pos­al and is eager to start the work (ba­sic­ally this gives us the user­land in­ter­face for multi-​channel mix­er sup­port). Re­gard­ing the linuxolat­or im­prove­ments the stu­dent has a little bit less luck. I com­piled a nice TODO list which is based upon his own pro­pos­al and all the vari­ous things I know about the linuxolat­or (PR’s, mes­sages on emulation@, private con­ver­sa­tions, things we no­ticed while work­ing on the up­date of the linux base to a re­cent Fe­dora Core, …). I will be im­pressed if he man­ages to do everything on the TODO list (don’t worry, he knows that not everything has to be done to de­clare “suc­cess” to Google).

Both of them may be can­did­ates for a com­mit bit (not with­in the SoC, but maybe later), both are eager to do the work, in­ter­ested, mo­tiv­ated, and don’t need hand-​holding.

Fur­ther news in the area of the sound sys­tem: Ar­iff told me he is work­ing on multi-​channel and en­di­aness issues/​support, and I may be able to com­mit two more sound drivers to the tree. One driver is the emu10kx driver cur­rently avail­able in the Ports Col­lec­tion, and the oth­er one is a driver for some envy24 chips. Cur­rently I’m in con­tact with the au­thor of the emu10kx driver and a vo­lun­teer who wants to im­prove an ex­ist­ing envy24 driver (au­thor of the driver con­tac­ted; since it’s BSD li­censed, this is a “don’t be evil” ac­tion).

And some news re­gard­ing the user­land part of the linuxolat­or: We’re wait­ing for a repo-​copy form linux_​base-​fc3 to linux_​base-​fc4. It seems FC4 is com­pat­ible enough so that we can dir­e­clty move from Red­Hat 8 to FC 4. FC 5 is out of the game for a while, it doesn’t want to run with the old linux ker­nel ver­sion our linuxolat­or an­nounces. Chan­ging the ver­sion via the sy­sctl doesn’t help (prob­ably be­cause of the changed se­mant­ic of the linux clone sy­scall between 2.4.x and 2.6.x), so it has to wait un­til the linuxolat­or SoC fin­ishes.