Thursday, January 25, 2007

Bugzilla git mirror

Daniel was updating the bugzilla at and pinged me about setting up a git mirror for the bugzilla CVS repository so he could keep track of the customization changes. This makes a lot of sense since bugzilla is probably one of the most customized projects - at any rate, I haven't seen a deployment that hasn't had some tweaking, either bug-buddy integration, work-flow features, changes to make it work with the rest of the site infrastructure or just plain branding.

Whether or not the local changes are to be upstreamed, it makes a lot of sense to track them using git, since git was pretty much designed to handle the bunch-of-local-changes use case. And the git mirror is live, that is, it's updated twice a day, so if you plan to upstream your local changes, it's easy to get the latest upstream work and diff against that.

The git repo is browsable here and can be cloned using the command

git clone git://

Might be useful.

Monday, January 22, 2007


Leading up to FUDCon, I figured I should expand a bit on the "executive summary" from the previous post. Plymouth is the code name for the next generation RHGB (Red Hat Graphical Boot) effort, and as I hinted in the previous post, the key idea is to put the X server in the initramfs. I'll try to summarize the discussions that have led to this approach below.

A number of distros have an fbdev based graphical boot solution, and while these generally work reasonably well, the problems outweigh the benefits, even in the short term. First of all, we don't want to rely on and maintain two different code paths for mode setting. Mode setting is difficult, yet boring, so it's not like there's a lot of developer manpower in this area. All in all it makes sense to choose one code path and make sure that works.

Second, the fbdev drivers is a point of contention - on one hand they seem to work very well for embedded uses where you have a small PDA type of device with just one screen, on the other hand, the fbdev abstraction just doesn't scale to the requirements of a modern, multihead, monitor-hotplugged desktop. A more flexible kernel based mode setting might just happen and that is great, regardless of whose idea it was to begin with. But that is the longer term solution, and until that work materializes we need something better than the current RHGB, and ideally something that pulls in the right direction.

Since X has to work for desktop usage it only makes sense to bet the farm on the X modesetting code. This is what RHGB does, however, RHGB loses a lot of its punch when it's only started halfway through the boot sequence. Also, all the flickering as we go from grubs 640x480 graphical menu back to text mode, into the RHGB X server and then into the real X server doesn't exactly make for a nice experience. Which leads us to the idea of starting X as early as at all possible - in the initramfs.

Short of doing modesetting in the kernel, this is the earliest we can initialize the video card. Once the X server is running, the idea is to use this server throughout graphical boot, login screen and user session. This allows for controlled transitions between these phases as opposed to crazy flickering while your monitor goes in and out of sync a few times. Of course, a fair bit of integration work is required across the initramfs tool, init scripts, GDM and gnome-session (or KDM and ksession) for this to work. Another quirk is that starting the X server from the initramfs prevents us from unmounting, which keeps the 5M of unswappable memory around. We've been discussing shutting down the X server while keeping the mode set and then starting the real X server from the real root file system in a way such that it just "inherits" the mode already set.

Using the mayflower initramfs creator from Davids livecd-tools with this patch, I was able to create an initramfs that included the X server, the DDX driver and the necessary modules in just under 5M. Booting with this ram disk lets me get from grub to X in under 5 seconds on a typical desktop machine. As a proof on concept, that's pretty encouraging, but it's just the first tiny step towards implementing this idea.

Thursday, January 18, 2007


The last weekend of February I will be in Brussels for FOSDEM giving a talk about AIGLX. I will probably recycle some of my talk from XDevConf 2006, but a lot of has happened since then - with the memory manager work from the Tungsten Guys and anholts damage 1.1 work, we're a lot closer to redirected direct rendering.

And just now I signed up for FUDCon Boston 2007, where ajax and I will be doing a hacking/brainstorming session on graphical boot (aka "Death to RHGB"). Executive summary: X in the initrd!

First post!

Hah, I have a work blog. People have been nudging me to blog about my work on occasion and I've wanted to do so several times. My standing excuse have been that I don't want to clutter up my personal blog with work trivia and vice versa and I can't be bothered to figure out how to tag my posts. But it turns out it's as easy as just starting a separate blog. Gah.

So, what's going on work-wise these days. The last few days I've been severely side-tracked by the Adobe Reader 7.0.9 security errata, but hopefully that'll be over soon. Then it's back to FireWire, which is what I've been spending pretty much 100% of my time on the last couple of months. At Red Hat we'd like to ship and support FireWire, but the stability of the Linux FireWire stack has been hit and miss. Stefan Richter, the upstream maintainer, has been doing a great job of raising the quality level and keeping it stable lately, but longer term it's a dead end.

It turns out that this is fixable by writing a new stack. It's not as crazy as it sounds, a full-featured FireWire stack with a reasonable level of backwards compatibility is doable in less that 10k lines of code. I announced the first version of the stack back in December on LKML and we've been discussing the features and user space interfaces on the linux1394-devel list quite a bit. There's been a lot of great feedback and ideas from the Linux FireWire application developers out there, and people seem generally interested and positive. A storage-driver-only version of the stack is in the latest mm kernel and we're now shipping that patch in Fedora rawhide. Good times.