MIDI sup­port in -cur­rent

I just com­mit­ted the old–new midi code ftom tan­imura and matk.Yur­iy Tsibizov (of emu10kx fame) in­teg­rated it in­to cur­rent. I think it wil need a lot of work un­til it’s really ma­ture, but as long as it isn’t in the tree, nearly nobody will have a look at it.

We need a main­tain­er for this!

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


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

The ker­nel sub­sys­tem API doc­u­ment­a­tion gen­er­a­tion frame­work.

I com­mit­ted the ker­nel sub­sys­tem API doc­u­ment­a­tion gen­er­a­tion frame­work. It al­lows to gen­er­ate the API doc­u­ment­a­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 without com­ments and blank lines). Here’s an ex­ample of such a con­fig:

PROJECT_​NAME = “FreeBSD ker­nel sound device code”
EXTRACT_​ALL = YES # for un­doc­u­mented src, no warn­ings en­abled
INPUT = $(DOXYGEN_SRC_PATH)/dev/sound/

GENERATE_​TAGFILE = dev_sound/dev_sound.tag
TAGFILES = dev_pci/dev_pci.tag=../../dev_pci/html \
@INCLUDE = common-​Doxyfile

The frame­work is con­figured 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 oth­er sub­sys­tems are wel­come):

  • cam
  • crypto
  • dev_​pci
  • dev_​sound
  • dev_​usb
  • geom
  • i4b
  • kern
  • lib­kern
  • linux
  • net80211
  • net­graph
  • net­in­et
  • netinet6
  • ne­tipsec
  • open­crypto
  • vm

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

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.