From Joshua Coombs:

          _  _
 _________|  |_________
(_________\  /_________)
(_________/  \_________)
       __/|  |\__
          |  |

Slow going

We had some power outages/surges here because of a windstorm, and my UPS didn’t handle it well, along with other local network equipment. So, I’ll be slow with news posts until I get my internal network in better working order.

MBWTest added

I’ll quote Matt Dillon’s entry cause I’m working late:

” The MBWTest program (/tmp/mbw1) attempts to figure out the L1 and L2 cache sizes and measures L1, L2, and non-cached linear memory bandwidth.”

Matt Dillon’s schedule

This week Matt Dillon is doing:

  • lwkt_token and IPI code optimization
  • GCC 3.x (just for support of the next item)
  • 64 bit AMD64 support
… and networking code with Jeff Hsu.

For those of you late to the party and wondering why his work schedule is spotlighted, Matt Dillon is the originator of the DragonFly project, and is doing much heavy lifting.

FreeBSD-5 boot

Matt Dillon’s added boot code from FreeBSD 5 – this allows AMD64 and ELF64 support. He also pushed in new linker code and some (not yet enabled) support for UFS2.

Use installkernel and installworld as part of your build process, and you should be fine with these changes. However, you will manually have to copy /usr/src/sys/boot/i386/loader/loader.rc to /boot.

There’s been a lot of new code lately – that’s good!


Jeroen Ruigrok supplied these links about patent issues with Cisco’s VRRP during a thread about importing OpenBSD’s CARP as part of pf.


Build from scratch

Matt Dillon’s reorganizing some of the header files; if you build a new kernel anytime soon, make sure you build from scratch using ‘config -r’, as some of the old header files have now vanished.

Network changes starting

Jeffrey Hsu and Matt Dillon’s network changes are being committed – the first third is in, according to a commit by Matt.

Matt describes the plan thusly:

“Basically the goal of this work is to isolate and serialize PCBs in specific threads in order to (A) not have to lock them and (B) improve cache locality for ISR processing loops as well as for data. Isolating a network PCB means dealing with the points where the PCB talks to other parts of the system. There are three points where this happens:

  • incoming packets go through preprocessing (e.g. IP) before
    being routed to the target protocol & PCB (e.g. TCP and UDP).

  • user syscalls operate on PCBs
  • timers and such initiate work related to particular PCBs”

I wish I knew what a PCB was.