AMD announced what would become x86-64 in 1999, and the first CPU was shipped in 2003.

A few years later, we released the first version of our email gateway. At that time, many 1U servers and network appliances used the new “Pentium M” processor, thanks to its energy efficiency. It was 32-bit. That’s how our 10-year-long 32-bit legacy began…

A few months ago, we got tired of having to build, test and release two different binary images of each release; one 32-bit (called i386) and another 64-bit (called amd64). To see what kind of systems were out there, we added the following code to the product, to detect 64-bit CPUs (even though the CPU was running 32-bit software) and displayed a warning on the first page of the web admin, if a 32-bit CPU was detected.

bool cpu_has_64bit_support() {
        uint32_t regs[4];
        do_cpuid(0x80000000, regs);
        if (regs[0] < 0x80000001)
                return false;
        do_cpuid(0x80000001, regs);
        if (regs[3] & 0x20000000)
                return true;
        return false;
}

Only a handful customers got back to us, saying that they say the warning, asking what was up. Some had 64-bit CPUs, but were running virtual machines on old hosts (for example VMware ESX3) which had a per-VM setting for enabling 64-bit. Other were still running old network appliances with Pentium M, and we encouraged them to go virtual instead (as most companies today have a virtual machine environment).

Satisfied about the results, we researched the different methods for migrating all users to 64-bit. First of all, we made sure that the 32-bit FreeBSD’s first-strage boot loader (that we use for updating in our dual-partition scheme) could load a 64-bit kernel/loader, which it could, fortunately. Then, we had to decide when to convert all the machine-dependent data (PostgreSQL database, RRD, etc). We finally decided to do the migration in “one step”; doing the data conversion during boot of the 64-bit release (only one 64-bit release will contain the migration code; 3.2-r10). By shipping that specific “migration” release with 32-bit compatibility libraries and a 32-bit version of PostgreSQL and other programs, we can dump the data to SQL, XML, etc and then to an import. Once migrated, the customer need to update once more, in order to get to the latest 64-bit release. We make sure that no systems are “bricked” by doing the cpu_has_64bit_support() check in the updated program before downloading the update.

A few weeks ago, we finally released the “32-to-64-bit migration release” (in the form of 3.2-r10) on a request basis, and it will released for everyone (with a CPU that detects as 64-bit) in a week or so.