If you have an Athlon or Xeon processor, go into usr/src/test/sysperf, do make, and the resulting /tmp/mem1 program will probably give interesting results, which you can then post to the kernel mailing list. A caveat from Matt Dillon:

“Note however that you have to manually edit which copy tests it does since it bus fault if you try to run the XMM (SSE2) test on a machine without SSE2 :-)”

It’s been very quiet, but that’s because people are really, really busy working on DragonFly features. Here’s a roundup:

- Devon H. O’Dell and others are still working on the installer, promtped by Hiten Pandya. The code for this is available via cvsweb, including the very interesting design notes. (It has diagrams, so it must be good.)

- Hiten Pandya and Joerg Sonnenberger are updating the device subsystem to match FreeBSD 5.x. (I don’t have a lot of details on this; they’re busy!)

- Matt Dillon is writing a paper with FreeBSD’s Alan Cox detailing the performance improvements of certain pipe optimizations; he’s been doing various benchmarks for data. He’s also been working on AMD64-specific code, which he’s planning to commit soon.

- I may as well toss this in too: Jeffrey Hsu has been quietly and steadily changing the networking system. I don’t often mention his patches because he’s working at a level that’s quite beyond my ability to summarize.

Devon already noted this in comments on the last post, but a screenshot (not a prototype) of his installer work is at http://sitetronics.com/current.png.

Devon H. O’Dell has been working on an installer. This is a prototype, not a screenshot.

The libcaps interprocess communication is now functional, though not implemented. Matt Dillon wrote how this could be worked up, which I am reporting wholesale:
More…

Sascha Wildner submitted a whole bunch of changes to vidcontrol(1); among other things, the colors/modes you can set in your terminal are more flexible, and it handles problems a lot better. This hasn’t been committed yet, and I usually don’t mention code until it’s in, but Sascha posted some nice photos of some of the possible modes:

C64-style
640×200, 8×8 font
320×200, 16px font

There’s a new ‘known good’ installation ISO on the dragonflybsd.org download page.

Devon H. O’Dell has been creating a whole set of premade packages for DragonFly. Instead of working with ports/dfports, you can pkg_add these file directly.

Matt Dillon’s changed the UPDATING document, separating the “Upgrade from FreeBSD” and the “Upgrade DragonFly” sections into separate passages.

Devon H. O’Dell has made vector-based versions of the DragonFly logo, available as PNG, EPS, and SVG.

‘esmith’ linked to another project that handles devices, used in Linux: “User-Space System Device Enumeration” (uDSE).

Looking for things to do? Here’s Hiten Pandya’s list of possible merges from FreeBSD. There’s a lot of tasks there of varying length and difficulty, so if you feel like trying something out, go for it and post your patch to the dragonfly.submit list.

Jonathon McKitrick asked about “last known stable” tags, and the June release date for 1.0. Matt Dillon replied that a known stable tag will appear once the networking code is stable, and that a late June release is still planned

‘esmith’ asked about udev/hotplug in contrast to FreeBSD-5′s devfs, listing these links for more info.

http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
http://kerneltrap.org/node/view/1893
http://www.gentoo.org/doc/en/udev-guide.xml

Eirik Nygaard has suggested using Eivind Eklund’s etcmerge (available in ports/sysutils/etcmerge) to handle the upgrade process. Here’s etcmerge itself and the man page, for the curious.

Joerg Sonnenberger is merging some FreeBSD 5.x changes to kobj, which changes the ABI. This means rebuild all modules on your next kernel build. That includes your nvidia driver, too, if you have it.

Matt Dillon found that using short-form names in /etc/fstab would cause the DNS resolver to return “host not found”, even if there was just a timeout (which should result in “try again”) when first looking up that name. This is now fixed. If you found you could not mount NFS volumes at boot, but they worked when done manually after boot, this should fix it.

Jeremy Almey alerted me to the DragonFly Wikipedia entry that he maintains – a good summary of the project, including one of the better explanations of tokens and the LWKT that I’ve seen.

Andre Nathan asked for links on SSI (Single System Image), since that’s DragonFly’s pie-in-the-sky goal. Walt gave a link to Larry McVoy’s paper (Linux-specific) on the subject.

Now there’s NetBSD quarterly reports, too. Seems like reader-friendly BSD reports is a good idea, eh?

Matt Dillon’s posted about the namecache work he plans to be doing now; his summary is included here.
More…

Ivan Voras has finished his benchmark of a system running FreeBSD, NetBSD, DragonFly and Linux. DragonFly does quite well, coming unsurprisingly close to the leader – FreeBSD 4.x. The difference would probably be more pronounced on a multiprocessor system, which wasn’t used in these benchmarks.

Stack smashing protection, also known as ProPolice, is now on by default when using gcc3. (It’s already been on by default for gcc2 for some time now.)

For those of us from FreeBSDland, the kernel upgrade process is (well, recently) solidified to a number of steps including mergemaster. Matt Dillon noted that the DragonFly upgrading process is thus:

(update via cvsup)
cd /usr/src
make buildworld
make buildkernel KERNCONF=<kernel config file>
make installkernel KERNCONF=<kernel config file>
make installworld
make upgrade

The “make upgrade” step replaces mergemaster, and should be relatively faster. Credit for this goes to Sascha Wildner for asking for clarification on the dragonfly.bugs mailing list.

Matt Dillon posted this little note on how to get a kernel crash dump, which seems a good idea to archive – this may be useful again:

The best way is to get a kernel crash dump. If your swap area (typically ad0s1b) is large enough to accomodoate main memory, then ‘dumpon /dev/ad0s1b’ (and put ‘dumpdev=/dev/ad0s1b’ in your /etc/rc.conf), and then when it crashed and drops into DDB> type ‘panic’ and hit return twice and it should hopefully generate a crash dump.

For the crash dump to be really useful having the kernel.debug for the kernel that you are running is important. kernel.debug is built automatically when you buildkernel, but only the stripped ‘kernel’ version is actually installed. kernel.debug should still be sitting in the kernel build object directory which is usually /usr/obj/usr/src/sys/<KERNELNAME> (if you used ‘buildkernel’ to build your kernel).

An earlier conversation about threading here, which generated a bit of discussion, has a comment from a Sun employee who authored one of the cited papers. It seems strange to turn a comment into news, but it’s a nice resolution.

Max Okumoto posted a link to a paper describing the Container Shipping I/O System, which may be similar to the XIO system proposed by Matt.