On Updating QEMU's bsd-user fork

 QEMU bsd-user

bsd-user is a 'user mode' emulation tool. It emulates FreeBSD's system calls on FreeBSD well, and $OTHER-BSD system calls elsewhere to varying degrees of success. It's primary mission has been to build FreeBSD packages using user-mode emulation to speed the process over using system mode. It speeds things up because the compilers and other huge CPU hogs can be built natively.

Of late, it has languished, A few years ago, I started to rebase it to the then-tip of qemu in the hopes of upstreaming. At the time, we'd forked off of qemu 1.0 or so. During this time the then-current qemu was 4.0. I got things rebased to around 3.1 before running out of steam. Rebasing patch trains of 1000 commits is hard, and trying to selectively squash commits wasn't much better.  So that's where things stalled. All bug fixes to qemu bsd-user had gone on in our own private branch.

Recently, I'd been asked about it again, so I started to dust things off. I got my name listed as the maintainer so I could push patches upstream a little more easily, and then started contributing by doing basic cleanup in the hopes of redoing 'logically' what had been done to split things up. Those efforts too have come to naught.

So, in one final act of desperation, I copied the 3.1-rebased bsd-user directory directly into qemu 6.0 and got it building. There were lots of little changes I needed, but nothing super huge. I've not done extensive testing, but the basics seem to work.

Trouble was, that diff was 35k lines. Too big to upstream in one go. So, I set out to see what could be done.

First, I labeled the 'yeet it up  to current' branch as 'blitz'. It's a fast hack to get something we can move forward on. In the future, releases and such will be cut from there until I can get it into the upstream tree. Blitz is the German word for 'fast' and has connotations of doing something quick and dirty well enough to move on.

Next, I created another branch from 6.0 called 'kaizen'. Kaizen is the Japanese business practice of continuous improvement. Find the most painful or most expensive part of your business, fix that and iterate. This branch I'll be putting 'diff reduction' patches for upstream, as well as start to move things over from blitz, starting with the loader. I've disconnected everything except x86 from this branch. In upstream qemu, bsd-user core dumps right away, so I'm not turning off anything that's working.

So the plan is that I'll focus on keeping x86 buildable, and get it working as quickly as I can and then add all the system calls from the blitz branch. I'll add them one group at a time, and do the reorgs and new file creation as well. I'll get these reviewed and upstreamed. Once all the system calls are in place, I'll start adding additional architectures as well, getting those patches reviewed too. Finally, I'll get the NetBSD and OpenBSD hosting stuff updated, as well as take a stab at updating their system call tables and seeing how well it works. The work that Stacey Son and others did tried to preserve all this, but it's been a long time since any of it was tested.

I have an agreement in principle with the qemu upstream to do all this work. So approximately monthly, I'll be landing a new branch with the latest diff reductions. I'll rebase kaizen and blitz after each drop and before I upstream. For the moment, this work will go into my gitlab fork (since it has all the CI setup on it) and from time to time I'll publish back to the github qemu-bsd-user repo. Be advised: both the blitz and kaizen branches will rebase often, so you may need to do weird things to update. Though, if you are tracking them with changes, please be in touch so we can coordinate work.

With luck, by this time next year, the kaizen and blitz branches will be nothing but a distant memory and we'll be on to keeping things up to date in qemu head, maybe with doing some refactoring with linux-user where it makes sense.