KS2009: Generic device trees

The lack of a device tree has made emulating new boards extremely fiddly. A board is essentially a collection of devices. So the lack of variety in hardware peripheral emulation is a _symptom_ of what I'm talking about. Bringing up the symptom as an objection to the proposed solution seems weird to me.

You've missed the point at a more fundamental level: QEMU currently isn't about kernels, it's about userspace. It has "a hard drive", "a network card", "a sound card", and so on. Doesn't currently matter which, they're just there to do a job by connecting the emulated environment to the host. They're not there to regression test your drivers.

Once you've booted into a working userspace, you can run (even natively build) a PPC version of arbitrary packages on a standard laptop. A developer can regression test their software on various different targets from a cron job or from a coffee shop, without needing to drag a half-dozen different hardware boxes around.

And you can point an upstream package maintainer at a tarball like http://impactlinux.com/code/firmware/downloads/binaries/s... and tell them: download that, extract it, execute the "./run-emulator.sh" script, cd /home, wget your source tarball from the internet and build it in there, and then do THIS to reproduce the problem I'm seeing on arm. (The fact they didn't have an arm environment in which to reproduce the problem? No longer an issue, here's one that runs under qemu.)

That's useful today.

Adding device tree support would make it useful in additional contexts, able to more closely emulate a wider range of boards out there. Then it could _start_ being a good thing to regression test kernels against, at some point in the future.

Rob