On 3 November 2016 at 22:48, Brooke Wallace <bwall...@ramlabs.com> wrote: > Thanks again Peter, > > Is there anyway to mount an -initrd image to the host?
You can't directly mount it, because it's not a filesystem. But there are tools for manipulating initrd images: something like https://access.redhat.com/solutions/24029 should work at a very low level, and there's probably some higher-level tools as well. The same things that work for manipulating an initrd for your host system should work just as well on one for the guest. > I'm not interested in booting Windows, and don't require > a full blown Debian OS - in fact I would expect a busybox > image for an embedded device. A full OS is much easier to work with, because you don't have to keep recreating an embedded filesystem image every time you do anything, and you don't need to go through the pain of assembling and cross compiling lots of library dependencies for every program you want to use inside the VM. >From QEMU's point of view there's no difference, it's just running a kernel and some userspace programs, so you might as well pick the userspace that's easy to work with. (If you want an embedded fs image you could have a look at https://buildroot.org, but it's likely to be more work to get that running than just to use Debian.) > Then maybe an API or some docs providing a description > of how one is expected to modify the code (well > implementing plugins would be best) to emulate > their particular hardware. We deliberately don't have a plugin architecture. New board and device models should be implemented in QEMU's source tree and (ideally) upstreamed. The "how to add a new board or devices" is unfortunately still at the level of "look at one that was added recently and see how it was done". thanks -- PMM