Re: Test environment for non-native archs

[aep <aep@exys.org>]

> This seems to be possible with qemu's support for exporting a virtual
> 9p share to the guest OS, but I haven't yet determined if it's
> possible to boot directly with the 9p share as the root fs,

user mode linux has humfs, but it's not in mainline. Instead there's 
hostfs, which is broken by design.
I can never get the uml patches working so i didn't look further.

What i researched instead was if you could run boot inside virtualbox 
from a vboxsf.
A kernel with initrd with the vboxsf stuff can access the "folders", 
but it isn't booting because their vfs does permissions wrong.

The virtualbox build system makes me angry, so i didn't try fixing it.
Since you're using a debian, maybe the buildsystem works for you and 
you can just hack the relevant parts in.
I think it's a matter of making couple more rpc calls to the hostdriver 
and mapping "stat" in the guest to the host.



On Sat, 26 May 2012 23:18:40 -0400, Rich Felker wrote:
> Hi,
>
> I've been thinking a bit about further testing of ARM (for which I
> don't have a native environment) and ports to other systems, and
> realized that to be able to efficiently mix working on the native 
> host
> and virtual target system (e.g. doing most of the compiling on the
> host), it's going to be desirable to have the Linux running under 
> qemu
> using part of the host's filesystem as its root fs, instead of having
> a filesystem image.
>
  or whether
> it's going to require a separate initial fs image and switch/pivot
> root afterwards (as you can tell, I'm not very familiar with this 
> sort
> of setup).
>
> Anyone know the answer, or have some recipes I could use?
>
> Rich