Category: General

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.

What Chris said. Go watch Eben’s talk, it really is worth it. I’m going to watch it again.

Chris had a nice quote, but you can skip randomly to any part and get other equally nice quotes.

“The patent has become a real estate entitlement, not based upon the social value it produces, but rather irrespective of the social harm it may induce.”

What I find most interesting about Mughsot is the team’s total and no-bullshit commitment to making new and interesting software which doesn’t suck.

I love the way they say their design process “isn’t a checklist of activites you must do – it’s an idea list, suggestions for how to work smarter”. I love the way they prototyped a photos feature using flickr but were willing to drop it again after trying it on real people. I love the way they lock themselves in a room, leaving their laptops behind, and give themselves the time to hash out ideas properly.

I hope Mugshot itself is a success. But, more than that, I hope they help change the way the rest of us make software.

As part of the work I’ve started doing on Stateless Linux, I’ve found myself hacking on device-mapper‘s snapshot support. It’s actually been really good fun to do a bit of kernel hacking again after such a long time … and this time I feel like I actually have some clue what I’m doing.

I’m really behind the times when it comes to all the new fangled revision control systems out there like bzr, git, mercurial, svn etc. – cvs and manual patch mangling is all I know.

So, when agk pointed me at quilt, I was a bit dubious at first but gave it a shot. It turned out to be a really simple and useful way of maintaining your own patchset in parallel with an upstream codebase.

Even though it’s a really simple tool, it seems to me to have some of the important advantages of other systems like distributed offline branches and change sets. If I had time to hack on GNOME again, I’d use quilt a lot for offline branches alongside CVS. It’s given me an appetite for looking at other systems too.

Aren’t discussions via blogs fun? 🙂

Federico: two points:

1. Using the new GObject instance private data API, rather than the private data scheme that GNOME hackers have always used, is a small optimization in itself – the private data is allocated in the same chunk as the object itself.

   As with all optimizations, you weigh up the benefit against the code obfuscation. In this case, I don’t think the GObject scheme makes the code more difficult to understand … especially since it’s likely to become as much of a second-nature idiom as the old scheme. It’s also one less opportunity to leak memory.

2. Using the GObject scheme, instance private data could have been added without the runtime hit you were seeing … even where the object structure couldn’t be extended without breaking ABI.

   To do so, you’d just go back to something similar to Owen’s initial suggestion for how the API should be used – in a static variable, you’d store the offset between the address of the object structure and the private data and use that offset for efficient access to the data. add_private() originally returned this offset, but it no longer does, so you’d need to calculate the offset in instance_init() – but it is guaranteed to be constant.

   Granted, that’s a nasty hack which would genuinely obfuscate the code … but at least it would actually be possible to add private data, whereas it wouldn’t be possible with the old scheme.

   Update: Tim points out that the offset to the private data isn’t constant across all instances – the offset will be larger for subtypes since the private data is allocated after all object data.