Mark McLoughlin

Havoc’s recent post on git was interesting because it shows how frustrating git can be if you try and treat it as “just another CVS”. From that perspective, git just seems like it’s just some bizarre way for kernel hackers to torture those who just want to get work done.

I turned that corner with git when I learned about “git-rebase -i” and came to the startling realisation that git’s history is editable. Basically, this allows you to change your workflow such that you can hack away at will, commit often and then rewrite the history of your hacking session so that you have a coherent set of patches/commits at the end of it with a useful changelog.

e.g. you can go from:

A1---B1---A2---A3---C1---B2---C2---C3

to:

A1---A2---A3---B1---B2---C1---C2---C3

or even:

A'---B'---C'

Using git rebasing, I found that I could use a similar workflow to using quilt with CVS, or mercurial with its patch queue (mq) extension. The revision history becomes less about tracking the progress of your work, and more a maleable mechanism for preparing patches before submitting upstream.

Red Hat Magazine has a nice article explaining all this, and I even picked up some new tricks to try out:

• git-merge –squash : merge a branch/tag into the current branch, but squash all the commits together as an uncommitted change to the working tree. When you go to commit the result, the changelog of all the merged commits is available in the commit message editor so you can munge them together into a useful changelog.
• git-cherry-pick –no-commit : apply the changes from a given commit to your working tree, but do not commit it. Could be used to achieve something similar to a squashed merge, but where you selectively merge only some of the commits.
• git-add –patch/–interactive : add some changes from the working tree to the index, but e.g. selectively add only some of the patch hunks from a given file. Allows you to make a bunch of changes to a file, but commit the changes as individual commits.

For the past couple of weeks, I’ve been helping out with the Fedora 9 pv_ops effort, specifically helping get the pv_ops based dom0 kernel going.

Well, following on from sct getting dom0 booting, I made a nice breakthrough this morning - a pv_ops dom0 booting a pv_ops domU:

$> dmesg | grep paravirt
Booting paravirtualized kernel on Xen
$> virsh create ./test-domu.xml
Domain Test created from ./test-domu.xml
$> virsh console Test | grep paravirt
Booting paravirtualized kernel on Xen

What’s this pv_ops business all about? Well, as Dan explained, for a long time we’ve been forward-porting Xensource’s (now 2.6.18 based) kernel tree in an effort to try and have our Xen kernel not lag behind Fedora’s bare-metal kernel. Now that the upstream kernel has gained the ability to run on Xen using pv_ops (but only as i386 DomU, currently) we’ve taken the decision to stop wasting our time forward porting Xensource’s tree and put all our focus into improving the feature set of pv_ops based Xen.

pv_ops itself is a set of hooks in the kernel so that support for running on different hypervisors can be cleanly added to the kernel, with the added bonus that the kernel can detect at runtime which hypervisor it is running on and adapt itself accordingly. This means that, in the long run, Xen support should be more akin to a device driver than a huge fork of the kernel.

(Note: for any others who ever to debug Xen’s booting of a guest, here’s a tiny Xen domain builder)

Thanks to Olav, I can post here again after nearly 10 months (!). Not that I had anything to say anyway

But for the past couple of months I’ve been writing about stuff like hiking, running and sailing on another blog and today’s tidbit is that I finished my first marathon yesterday.

Happy Finisher

Woo!

Dan I have been discussing how to “fix virtual networking”, not just Xen’s networking but also getting something sane wrt. QEMU/KVM etc.

Anyone interested should read this writeup. To discuss, libvirt-list is probably the best place.

QEMU has a number of really nice ways to set up networking for its guests. It can be a little bewildering to figure out how each of the options work, so I thought I’d write up what I found. Excuse the ‘orrid ascii art

If you’re wondering how to move your GNOME jhbuild from CVS now that the SVN migration has happened … here’s what I had to do.

• Checkout jhbuild from SVN:

    $> mkdir -p /gnome/head/svn && cd /gnome/head/svn
    $> svn co svn+ssh://markmc@svn.gnome.org/svn/jhbuild/trunk jhbuild
    $> make install
  

• Update ~/.jhbuildrc so that e.g.

    repos['svn.gnome.org'] = 'svn+ssh://markmc@svn.gnome.org/svn/'
    checkoutdir = '/gnome/head/svn'
  

• Copy /gnome/head/cvs/pkgs to /gnome/head/svn/pkgs so that you won’t have to download as many new tarballs
• Run jhbuild build

Note, this is with the gnome-2.18 moduleset. Things are still a little in flux right now.

Just back from a nice relaxing holiday and, at first, I was totally perplexed by all this talk of the Xen “absolute pointer” problem. “It’s just VNC”, I thought, “it can’t be that hard. It must be just a simple bug somewhere”.

The background is:

• In Xen guests we have a “xenfb” driver, which acts just like a normal framebuffer device as far as the Xserver is concerned, but the contents of the framebuffer is exported to Dom0 via XenBus and shared memory.
• Similarly, we have a “xenkbd” driver, which takes input events from Dom0 and makes them available to the Xserver.
• In Dom0, we have a little daemon which acts as a VNC server. It exports the framebuffer contents from the guest and injects input events into the guest.

The problem here is that pointer motion events arrive at the Xserver as if they came directly from hardware. And just like normal mouse events, they are relative - i.e. you move your mouse up X amount and across Y amount.

This is unusual, because a VNC server receives motion events with absolute co-ordinates and can normally warp the pointer to those exact co-ordinates.

What we have might not be too bad - we might be able to reliably control the absolute pointer position in X by injecting events with relative co-ordinates - except that these events are subject to acceleration. If we try and move the pointer by injecting an event that says “move 100 pixels to the right”, the Xserver may accelerate that and move it, say, 200 pixels (with a ratio of 2/1). So, Pete’s first going to come up with a quick hack to disable acceleration.

It’s still stupid to try and move the pointer to an absolute position by injecting relative pointer motion events, though. The ideal solution is that the pointer device in the Xen guest behaves just like a grapics tablet. We would pass the absolute pointer co-ordinates to the guest and the driver would pass those on to the Xserver as though it was tablet device.

We went to see The Wind That Shakes the Barley last night. I went along expecting some Michael Collins or Braveheart romanticised brit-bashing light entertainment, but no.

This one wasn’t easy to watch. It’s set during the Irish War of Independence and Irish Civil War which is only now about to drop out of living memory in Ireland. The emphasis isn’t so much on the fighting, but on the heartbreaking impact it had on families.

I like this comment on the IMDb page:

I saw this film at a private screening and found it difficult yet beautiful to watch.

…

This film is a template for what film makers can achieve with a small budget, dedicated performers and a timeless topic.

…

The sacrifices made 80 years ago still resonate today but the Republic of Ireland is now the third richest country in Europe. The question still debated is Was it Worth it? The question we ask is how’s Scotland and Wales doing?

I wrote up some notes on QEMU’s QCOW image format for anyone who might be interested.

I’ve posted description to the Fedora wiki about how we’re implementing the cached client part of Stateless Linux in FC6.

Pile onto the stateless-list if you want to yak about it.