Jon Bernard

ruining the internet, one post at a time

Metertools

Lately I’ve been investigating power management on hypervisors and virtual machines. I’m measuring energy consumption using a wattsup pro power meter connected to a Nahalem-based server.

The meter manufacturer provides software to read the power data from Windows, but doesn’t offer support for any other platforms. I was given a copy of metertools, a linux command-line utility to read the data off the meter. Some googling showed that this software was once public but the source link is broken. So I did what any free-software loving individual would do, I uploaded a copy to GitHub.

[source on github]

Python Dæmons!

I’ve been working on a product for Granola lately called granola-stats. It’s a program that allows servers, and otherwise non graphical environments, to upload energy savings to an account on the website. This allows users to track their energy savings across desktops and servers from the same interface. During development, I ended up implementing a Daemon class in python.

[source on github]

PEP 3134 contains a complete description of how a proper python daemon should be implemented, but doesn’t provide a usable implementation. Other online sources contained snippets and examples of “simple” daemons but all were lacking required functionality in some way. My version is certainly not perfect, but it handles many of the important pieces of daemonizing in a Unix environment and is working well so far.

New GPG Key

I’ve recently set up a new GPG key, and will be transitioning away from my old one. I have done this in order to migrate to a larger RSA key and stronger hash functions, and NOT due to any known key compromise. The old key will continue to be valid for some time, but future correspondence should use the new one wherever possible.

I have created a transition document and signed it with both keys.

Don't Clobber Your Registers

I recently needed to call the cpuid instruction from some C++ code. This is well documented on wikipedia and everything went fine until I hit a snag moving the code from x86_64 to i386.

It seems that %ebx is the PIC register for i386, and so you must take care to not clobber it when calling cpuid. This is accompolished by explictly saving and restoring the register before and after the call to cpuid. An additional step is required to tell gcc that %ebx will not be clobbered by the call to cpuid. The last lines of assembly define which registers were potentially clobbered so gcc can generate appropriate code. By manually saving and restoring %ebx, it can be saftely omitted from that list. I did not find any information documenting this specifically, so here it is! The following code returns the result of cpuid and runs on both x86_64 and i386.

void
cpuid(int regs[4], int cpuid_leaf)
{
        int eax, ebx, ecx, edx;
        asm volatile (
#if defined(__i386__)
             "pushl %%ebx;\n\t"
#endif
             "movl %4, %%eax;\n\t"
             "cpuid;\n\t"
             "movl %%eax, %0;\n\t"
             "movl %%ebx, %1;\n\t"
             "movl %%ecx, %2;\n\t"
             "movl %%edx, %3;\n\t"
#if defined(__i386__)
             "popl %%ebx;\n\t"
#endif
             :"=m" (eax), "=m" (ebx), "=m" (ecx), "=m" (edx)
             :"r" (cpuid_leaf)
             :"%eax",
#if !defined(__i386__)
             "%ebx",
#endif
             "%ecx", "%edx");

        regs[0] = eax;
        regs[1] = ebx;
        regs[2] = ecx;
        regs[3] = edx;
}

For additional information, I found Sam Hocovar’s post to be quite informative.

I'm going to DebConf 10

Im going to DebConf10

I just received word from @joeyhess that I’ve been sponsored to attend this years DebConf in New York City.

DebConf (short for Debian Conference) is the annual Debian developers meeting, an event filled with coding parties, discussions and workshops - all of them highly technical in nature. It will be held in New York City, USA, August 1-7, 2010.

Super excited!