In case you have not noticed yet, KDTRACE_HOOKS is now in the GENERIC ker­nel in FreeBSD-cur­rent. This means you just need to load the DTrace mod­ules and can use DTrace with the GENERIC ker­nel.

In case you do not know what you can do with DTrace, take the time to have a look at the DTrace blog. It is worth any minute you invest read­ing it.

There is a huge dis­cus­sion going on on hackers@ about how FreeBSD is not suit­able for large instal­la­tions (any­more?). As of this writ­ing, the dis­cus­sion seems to get some discussion-clusters. We have some sub-topics which could lead to some good improvements.

One subtopic is the release engi­neer­ing. Some changes like a more guided approach of what should be merged to which branch, the fre­quency of releases and maybe some kind of long-term-branch(es). There is some dis­cus­sion to get maybe some joined-funding in some way from inter­ested par­ties to pay some­one to take care about long-term-branch(es).

Another subtopic is the way bugs are han­dled in our old bug­track­ing soft­ware and how patches go unno­ticed there.

And both of them are con­nected (parts more, parts less) by what can be done in a vol­un­teer project.

To me it looks like the pro­pos­als “just” need some refine­ments and some “vol­un­teers” to put value (this means man power and/or money) to what they said.

What I want to dis­cuss here is, how tools could help with mak­ing PRs/patches more vis­i­ble to devel­op­ers (there is already the pos­si­bil­ity to get emails from the small bugbuster-team about patches in PR data­base, but you have to ask them to get them) and how to make it more easy to get patches into FreeBSD.

Mak­ing bugs more vis­i­ble to developers

The obvi­ous first: We need a dif­fer­ent bug­track­ing sys­tem. We already know about it. There is (or was…) even some­one work­ing IIRC on an eval­u­a­tion of what could be done and how easy/hard it would be. I am not aware of any out­come, despite the fact that it is months (or even a year) since this was announced. I do not blame any­one here, I would like to get time to fin­ish some FreeBSD vol­un­teer work myself.

In my opin­ion this needs to be han­dled in a com­mer­cial way. Some­one needs to be offi­cially paid (with a dead­line) to pro­duce a result. Unfor­tu­nately there is the prob­lem that the require­ments are in a way, that peo­ple do not have to change their workflows/procedures.

IIRC peo­ple ask that they should be able to send a mail to the bug­tracker with­out the need for authen­ti­ca­tion. Per­son­ally I think the bug­track­ing issue is in a state where we need to change our workflows/procedures. It is con­ve­nient to get mails from the bug­tracker and only have to reply to the mail to add some­thing. On the other hand, if I report bugs some­where, and if I really care about the prob­lem res­o­lu­tion, I am will­ing login to what­ever inter­face to get this damn prob­lem solved.

Send­ing a prob­lem report from the sys­tem where I have the issue in an easy way is a very use­ful fea­ture. Cur­rently we have send-pr for this and it uses emails. This means it requires a work­ing email setup. As an user I do not care if the tool uses email or HTTP or HTTPS, I just want to have an easy way to sub­mit the prob­lem. I would not mind if I first have to do a “send-problem reg­is­ter me@tld” (once), “send-problem login me@tld” (once per system+user I want to send from) and then maybe a “send-problem tem­plate write_template_here.txt” (to get some tem­plate text to fill out), edit the tem­plate file and then run “send-problem send my_report.txt file1 file2 …”. That would be a dif­fer­ent work­flow, but still easy.

Email noti­fi­ca­tions are surely needed, but if I really care about a prob­lem, I can be both­ered to reg­is­ter first. So in my opin­ion, we need a dif­fer­ent bug­tracker des­per­ately enough that we need to drop our require­ments regard­ing our cur­rent workflow/procedures (even if it means we can not get a com­mand line way of sub­mit­ting bugs at all). The pri­mary goal of the soft­ware needs to be to make it easy to track and resolve bugs. The sub­mis­sion of bugs shall be not hard too. If I look at the state of the world as it is ATM, I would say a webin­ter­face with authen­ti­ca­tion is not a big bur­den to take if I really want to get my prob­lem fixed. Some com­mand line tool would be nice to have, but regard­ing the cur­rent state of our bug­tracker it needs to be optional instead of a hard requirement.

Apart from mak­ing it easy to track and resolve prob­lems, the soft­ware also needs to be able to make us aware of the biggest prob­lems. Now… you may ask what is a big prob­lem. Well… IMO it does not mat­ter to you what I think is big or small here. The per­son with a prob­lem needs to decide what is a big prob­lem to him. And peo­ple with the same prob­lem need to be able to tell that it is also a big prob­lem for them. So a fea­ture which allows to “vote” or “+1″ or “AOL” (or how­ever you want to call it) would allow to let users with prob­lems voice their opin­ion upon the rel­e­vance of the prob­lem to our user­base. This also means there needs to be a way to see the high­est voted prob­lems. An auto­matic mail would be best, but as above this is optional. If I as a devel­oper really care about this, I can be both­ered to login to a webin­ter­face (or maybe some­one vol­un­teers to make a copy & paste and send a mail… we need to be will­ing to rethink our procedures).

Get­ting patches more easy into a FreeBSD branch

It looks to me that this topic is requires a lit­tle bit more involve­ment from mul­ti­ple tools. In my opin­ion we need to switch to a dis­trib­uted ver­sion con­trol sys­tem. One which allows to eas­ily cre­ate my own branch of FreeBSD on my own hard­ware, and which allows to let other users use my branch eas­ily (if I want to allow other to branch from my branch). It also needs to be able to let me push my changes towards FreeBSD. Obvi­ously not directly into the offi­cial sources, but into some kind of stag­ing area. Other peo­ple should be able to have a look at this stag­ing area and be able to review what I did. They need to be able to make some com­ments for oth­ers to see, or give some kind of (multi-dimensional?-)rating for the patch (code qual­ity / works for me / does not work / …). Based upon the review/rating and maybe some auto­mated eval­u­a­tion (com­pile test / regres­sion test / bench­mark run) a com­mit­ter could push the patch into the offi­cial FreeBSD tree (ideal would be some auto­mated noti­fi­ca­tion sys­tem, a push but­ton solu­tion for inte­gra­tion and so on, but as above we should not be afraid if we do not get all the bells and whistles).

If we would have some­thing like this in place, cre­at­ing some kind of long-term-release branch could be used more eas­ily in a colab­o­ra­tive man­ner. Com­pa­nies which use the same long-term-release branch could sub­mit their back­ports of fixes/features this way. They also could see if sim­i­lar branches (there could be related but dif­fer­ent branches, like 9.4-security-fixes-only <= 9.4-official-errata-only <= 9.4-bugfixes <= 9.4-bugfixes-and-driverupdates <= …) could be merged to their in-house branch (and maybe con­se­quently push-back to the offi­cial branch they branched from if the patch comes from a dif­fer­ent branch).

It does not mat­ter here if we would cre­ate a fixed set of branches for each release, or if we only cre­ate some special-purpose branches based upon the phase of the moon (ide­ally we would cre­ate a lot of branches for every release, companies/users can cherry pick/submit what they want, and the sta­tus of a long-term-branch is solely based upon the inflow of patches and not by what the secu­rity team or release man­ager or a ran­dom devel­oper thinks it should be… but the real­ity will prob­a­bly be some­where in the middle).

I do not know if tools exists to make all this hap­pen, or which tools could be put together to make it hap­pen. I also did not men­tion on pur­pose tools I am aware of which already pro­vide (small) parts of this. These are just some ideas to think about. Inter­ested par­ties are invited to join the dis­cus­sion on hackers@ (which is far away from dis­cussing spe­cific tools or fea­tures), but you are also free to add some com­ments here.

The recent Phoronix bench­mark which com­pared a release can­di­date of FreeBSD 9 with Ora­cle Linux Server 6.1 cre­ated a huge dis­cus­sion in the FreeBSD mail­inglists. The rea­son was that some peo­ple think the num­bers pre­sented there give a wrong pic­ture of FreeBSD. Partly because not all bench­mark num­bers are pre­sented in the most promi­nent page (as linked above), but only at a dif­fer­ent place. This gives the impres­sion that FreeBSD is infe­rior in this bench­mark while it just puts the focus (for a rea­son, accord­ing to some peo­ple) on a dif­fer­ent part of the bench­mark (to be more spe­cific, blog­bench is doing disk reads and writes in par­al­lel, FreeBSD gives higher pri­or­ity to writes than to reads, FreeBSD 9 out­per­forms OLS 6.1 in the writes while OLS 6.1 shines with the reads, and only the reads are pre­sented on the first page). Other com­plaints are that it is told that the default install was used (in this case UFS as the FS), when it was not (ZFS as the FS).

The author of the Phoronix arti­cle par­tic­i­pated in parts of the dis­cus­sion and asked for spe­cific improve­ment sug­ges­tions. A FreeBSD com­mit­ter seems to be already work­ing to get some issues resolved. What I do not like per­son­ally, is that the arti­cle is not updated with a remark that some things pre­sented do not reflect the real­ity and a retest is necessary.

As there was much talk in the thread but not much obvi­ous activ­ity from our side to resolve some issues, I started to improve the FreeBSD wiki page about bench­mark­ing so that we are able to point to it in case some­one wants to bench­mark FreeBSD. Oth­ers already chimed in and improved some things too. It is far from per­fect, some more eyes — and more impor­tantly some more fin­gers which add con­tent — are needed. Please go to the wiki page and try to help out (if you are afraid to write some­thing in the wiki, please at least tell your sug­ges­tions on a FreeBSD mail­inglist so that oth­ers can improve the wiki page).

What we need too, is a wiki page about FreeBSD tun­ing (a first step would be to take the man-page and con­vert it into a wiki page, then to improve it, and then to feed back the changes to the man-page while keep­ing the wiki page to be able to cross ref­er­ence parts from the bench­mark­ing page).

I already told about this in the thread about the Phoronix bench­mark: every­one is wel­come to improve the sit­u­a­tion. Do not talk, write some­thing. No mat­ter if it is an improve­ment to the bench­mark­ing page, tun­ing advise, or a tool which inspects the sys­tem and sug­gests some tun­ing. If you want to help in the wiki, cre­ate a First­name­Last­name account and ask a FreeBSD comit­ter for write access.

A while ago (IIRC we have to think in months or even years) there was some frame­work for auto­matic FreeBSD bench­mark­ing. Unfor­tu­nately the author run out of time. The frame­work was able to install a FreeBSD sys­tem on a machine, run some spec­i­fied bench­mark (not much bench­marks where inte­grated), and then install another FreeBSD ver­sion to run the same bench­mark, or to rein­stall the same ver­sion to run another bench­mark. IIRC there was also some DB behind which col­lected the results and maybe there was even some way to com­pare them. It would be nice if some­one could get some time to talk with the author to get the frame­work and set it up some­where, so that we have a con­trolled envi­ron­ment where we can do our own bench­marks in an auto­matic and repeat­able fash­ion with sev­eral FreeBSD versions.

I com­mit­ted the v4l2 sup­port into the lin­ux­u­la­tor (in 9–cur­rent). Part of this was the import of the v4l2 header from linux. We have the per­mis­sion to use it (like the v4l one), it is not licensed via GPL. This means we can use it in FreeBSD native dri­vers, and they are even allowed to be com­piled into GENERIC (but I doubt we have a dri­ver which could pro­vide the v4l2 inter­face in GENERIC).

The code I com­mit­ted is “just” the glue-code which allows to use FreeBSD native devices which pro­vide a v4l2 inter­face (e.g. multimedia/pwcbsd or multimedia/webcamd) from linux pro­grams.

Thanks to nox@ for writ­ing the glue code.

After a quick dis­cus­sion with nox@ I made a copy&paste of his “VDR is com­mit­ted now”-mail into the FreeBSD wiki. I also re-styled some small parts of it to fit bet­ter into the wiki. It is not per­fect, but already usable. Now inter­ested peo­ple can go and improve the docs there.

Thanks to Juer­gen for all his work in this area!