Yesterday I committed some more configs to generate doxygen documentation of FreeBSD-kernel drivers. I mechanically generated missing configs for subdirectories of src/sys/dev/. This means there is no dependency information included in the configs, and as such you will not get links e.g. to the PCI documentation, if a driver calls functions in the PCI driver (feel free to tell me about such dependencies).
IfÂ you want to generate the HTML or PDF version of some subsystem, just go to src/tools/kerneldoc/subsys/ an run â€œmakeâ€? to get a list of targets to build. As an example, â€œmake dev_soundâ€? will generate the HTML version for the sound system, â€œmake pdf-dev_soundâ€? generates the PDF version. The sound system is probably the most â€œniceâ€? example, as it includes a page with TODO items, and has even some real API docs instead of just the call-graphs and such automatically generated information.
Some drivers already have (some) doxygen markup (I did just a quick grep for â€˜/*[*!]â€™ to detect doxygen markup indicators, no idea about the coverage or quality), namely:
Some days ago I got a mail from portmgr@ that my iconv patch that I sent to them for a portbuild test, failed. The patch added BSD iconv to the base system while leaving the Ports Collection intact, letting the ports just use GNU libiconv. I would like to do the import in two phases, first just importing it while still using GNU libiconv in ports, then extend knobs in the following way: USE_ICONV could be set to yes, gnu or libc. In the first case WANT_ICONV would determine what to use, gnu or libc. In the second case the port would always use GNU libiconv and in the third case, just BSD iconv. I looked at the problem and noticed that some ports detect that we have iconv in libc and thus they try to use that but then fail because of a missing GNU feature. I tried to solve the problem from two ways: forcing ports more to use GNU libiconv and adding the missing feature to BSD iconv. Yesterday I sent the new patch to portmgr@ and now I’m waiting for their response.
Apart from the iconv portbuild run, some time ago there was also a BSD grep portbuild run. It went almost fine, just very few ports failed. I didn’t have time to look at it until yesterday and I identified a bug. BSD grep didn’t handle correctly the case where -v and multiple -e options were specified. I’ve fixed the problem, merged some changes from the OpenBSD and the freegrep repositories and today I’ve also sent a new patch to portmgr@ for BSD grep. Let’s hope there won’t be any regressions and we can commit it very soon. This should be successful because there have been multiple portbuild tests and I have fixed all problems that were identified. However, the BSD iconv patch is more experimental, I don’t know what to expect there but I hope there won’t be serious problems… Now I’ll get back to my IRIX jobs SoC project, although I made these patches during buildworld/buildkernel runs so I didn’t have to neglect that one in the meantime.