|
Message-ID: <b5560ed4ee5d156056e560e5aab91f97@exys.org> Date: Sun, 03 Jun 2012 13:15:54 +0200 From: aep <aep@...s.org> To: <musl@...ts.openwall.com> Subject: Re: Test environment for non-native archs > 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.