Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)

I can think of some reasons for a non-native file service that is instead built into QEMU: a) One interface to all clients outside of QEMU. Lowers the learning curve for dealing with different enviroments; at least for some raw file access they are all accessible in the same way. You can lower con

Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)

>> - no ide-channel is blocked (unlike vvFat) > > I don't believe this is a major issue. Alias, vvFat is readonly and > anyways not > suitable for the purposes of every OS (e.g. copy from Linux guest to Linux > host, preserving ownership). Well for the current project I'm working on, I'm running s

Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)

On Mon, Jun 06, 2005 at 08:11:08PM +0200, [EMAIL PROTECTED] wrote: > The advantages are: > - no ide-channel is blocked (unlike vvFat) I don't believe this is a major issue. Alias, vvFat is readonly and anyways not suitable for the purposes of every OS (e.g. copy from Linux guest to Linux host, pre

[Qemu-devel] Mac OS X at native speed...

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Could this: http://apple.slashdot.org/apple/05/06/06/1752234.shtml?tid=118&tid=179&tid=3 help to run Mac OS X at near-native speed on x86? I'd really like to try OS X myself, but money-wise Qemu will most likely be the only way for me... So maybe this

Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)

> On Fri, 3 Jun 2005, Jan Marten Simons wrote: > >> Ok, I talked about this issue in irc lately, but as this list will have >> a larger audience I'll post this here as well. So here is the (cleaned) >> log: >> >> What I want: >> >> some feature I'm really missing is: a v(S)FTP sever inside the >>

[Qemu-devel] Information flow tracking extension for qemu

Hi, I've started looking at the source code to figure the best way to write the extension, and I figures out it is best to write it as a new target CPU based on the i386. I'm adding some instrumentation code in op.c, which should make things a bit slower but hopefully not too slow. There are two

Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)

On Sun, Jun 05, 2005 at 09:17:45PM +0200, Henrik Nordstrom wrote: > On Fri, 3 Jun 2005, Jan Marten Simons wrote: > > >Ok, I talked about this issue in irc lately, but as this list will have > >a larger audience I'll post this here as well. So here is the (cleaned) > >log: > > > >What I want: > >

Re: [Qemu-devel] [PATCH] Fix for a malloc heap corruption problem in the slirp network code

> Fabrice Bellard wrote > > Juergen Keil wrote: > > Compiling inside a NetBSD 1.5 qemu guest OS (source files are located > > on an NFS filesystem mounted from the Solaris host OS) crashes qemu > > with a malloc heap corruption error, when the slirp user mode > > networking code is in use. > > [.