I just com­mit­ted the old-new midi code ftom tan­imura and matk.Yuriy Tsi­bi­zov (of emu10kx fame) inte­grated it into cur­rent. I think it wil need a lot of work until it’s really mature, but as long as it isn’t in the tree, nearly nobody will have a look at it.

We need a main­tainer for this!

I will try to fix pan­ics and LOR’s, but I will not extend dri­vers to use it. The emu10k1 and the cmi dri­vers already have sup­port. The emu10kx dri­ver will also make use of it when it enters the tree.

Since Roman wanted to cre­ate his lin­ux­o­la­tor branch in per­force, I had to make myself famil­iar with per­force too, to be able to answer his ques­tions. I learned my first steps in per­force by cre­at­ing the sound branch (I’m men­tor­ing Ryan together with Ariff). 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 (“rbeasley” instead of “ryanb”). I think this means I shouldn’t trust my mem­ory and double-check such facts in the future. Since it’s only a name­space issue to not have con­flicts when sev­eral peo­ple want to cre­ate branches with the same name (but a dif­fer­ent seman­tic of what has to be done there), I don’t think it matters.

Roman hadn’t as much “luck” than I had. He for­got to add a ‘/’ in an impor­tant place which resulted in files like “…_linuxolatoramd64/…” instead 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 shoul­der of some­one. Mea culpa (stu­dents which are excited and eager to try some­thing… I think I remem­ber how this feels ). He is resolv­ing this as I write this.

While I see some ben­e­fits in the way per­force is work­ing (seems to allow some pow­er­ful things we can’t do with CVS), I have to say the per­for­mance sucks when cre­at­ing branches (I did it at home via DSL and a com­pressed ssh tun­nel to the per­force server, 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 doing this.

I com­mit­ted the ker­nel sub­sys­tem API doc­u­men­ta­tion gen­er­a­tion frame­work. It allows to gen­er­ate the API doc­u­men­ta­tion of a sub­sys­tem (with doxy­gen) just by adding a short con­fig file (around 22 lines with com­ments and blank lines, maybe 14 lines with­out com­ments and blank lines). Here’s an exam­ple of such a config:

—snip—
PROJECT_NAME = “FreeBSD ker­nel sound device code“
OUTPUT_DIRECTORY = $(DOXYGEN_DEST_PATH)/dev_sound/
EXTRACT_ALL = YES # for undoc­u­mented src, no warn­ings enabled
INPUT = $(DOXYGEN_SRC_PATH)/dev/sound/

GENERATE_TAGFILE = dev_sound/dev_sound.tag
TAGFILES = dev_pci/dev_pci.tag=../../dev_pci/html
dev_usb/dev_usb.tag=../../dev_usb/html
@INCLUDE_PATH = $(DOXYGEN_INCLUDE_PATH)
@INCLUDE = common-Doxyfile
—snip—

The frame­work is con­fig­ured to not only gen­er­ate the HTML ver­sion, but also a PDF ver­sion.

Sub­sys­tems for which docs are gen­er­ated cur­rently (con­figs for other sub­sys­tems are welcome):

• cam
• crypto
• dev_pci
• dev_sound
• dev_usb
• geom
• i4b
• kern
• libkern
• linux
• net80211
• net­graph
• netinet
• netinet6
• netipsec
• open­crypto
• vm

Peo­ple which want to help doc­u­ment­ing the code may want to have a look at the spe­cial com­mands doxy­gen under­stands.

Now that we have (or “soon will have”) an offi­cial FreeBSD blog, I decided to give this kind of elec­tronic and pub­lic diary a try. At least to report the sta­tus and progress of some FreeBSD related projects I’m involved in.

A lot hap­pened in the last days. We’re past the dead­line of the Google Sum­mer of Code rat­ing process and now the lucky stu­dents are cho­sen. It wasn’t easy. We had more than 120 pro­pos­als (out of ~6400). From those we where will­ing to men­tor 40 – 50 (based upon our resources and the qual­ity of the pro­pos­als). Google granted 14 to us (a big thank you to Google!). I expect an offi­cial announce­ment “soon”. Hope­fully some of those stu­dents Google wasn’t able to fund are will­ing to work with us regard­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 pro­vide the same amount of men­tor­ship as if they where selected.

I will work with two stu­dents. One of them will work on sync­ing the OSS API from recent releases from 4Front with our sound sys­tem. The other one will work on improv­ing the lin­ux­o­la­tor. I will announce this on the cor­re­spond­ing mail­inglists after the offi­cial announce­ment. ATM we need to do some admin­is­tra­tive stuff (hand­ing out access to the wiki and per­force, set­ting up email aliases, …).

I already mailed some gen­eral guides to the stu­dents (note to men­tors: it’s in the wiki on the “hid­den” and restricted to men­tors SoC page). For the sound stuff I don’t have a nice TODO list, but luck­ily the stu­dent already inves­ti­gated the 4Front stuff for the pro­posal and is eager to start the work (basi­cally this gives us the user­land inter­face for multi-channel mixer sup­port). Regard­ing the lin­ux­o­la­tor improve­ments the stu­dent has a lit­tle bit less luck. I com­piled a nice TODO list which is based upon his own pro­posal and all the var­i­ous things I know about the lin­ux­o­la­tor (PR’s, mes­sages on emulation@, pri­vate con­ver­sa­tions, things we noticed while work­ing on the update of the linux base to a recent Fedora Core, …). I will be impressed if he man­ages to do every­thing on the TODO list (don’t worry, he knows that not every­thing has to be done to declare “suc­cess” to Google).

Both of them may be can­di­dates for a com­mit bit (not within the SoC, but maybe later), both are eager to do the work, inter­ested, moti­vated, and don’t need hand-holding.

Fur­ther news in the area of the sound sys­tem: Ariff told me he is work­ing on multi-channel and endi­aness issues/support, and I may be able to com­mit two more sound dri­vers to the tree. One dri­ver is the emu10kx dri­ver cur­rently avail­able in the Ports Col­lec­tion, and the other one is a dri­ver for some envy24 chips. Cur­rently I’m in con­tact with the author of the emu10kx dri­ver and a vol­un­teer who wants to improve an exist­ing envy24 dri­ver (author of the dri­ver con­tacted; since it’s BSD licensed, this is a “don’t be evil” action).

And some news regard­ing the user­land part of the lin­ux­o­la­tor: We’re wait­ing for a repo-copy form linux_base-fc3 to linux_base-fc4. It seems FC4 is com­pat­i­ble enough so that we can dire­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 lin­ux­o­la­tor announces. Chang­ing the ver­sion via the sysctl doesn’t help (prob­a­bly because of the changed seman­tic of the linux clone syscall between 2.4.x and 2.6.x), so it has to wait until the lin­ux­o­la­tor SoC finishes.