On 20.12.2011, at 08:46, 陳韋任 wrote:
This patch is actually wrong and we should rather make proper -R values the
default instead of relying on MAP_32BIT.
I don't understand what make proper -R values means. Where/how
This patch is actually wrong and we should rather make proper -R values
the default instead of relying on MAP_32BIT.
I don't understand what make proper -R values means. Where/how we can
apply
-R?
Please see
On 21.12.2011, at 03:43, 陳韋任 che...@iis.sinica.edu.tw wrote:
This patch is actually wrong and we should rather make proper -R values
the default instead of relying on MAP_32BIT.
I don't understand what make proper -R
This patch is actually wrong and we should rather make proper -R values the
default instead of relying on MAP_32BIT.
I don't understand what make proper -R values means. Where/how we can apply
-R?
Regards,
chenwj
--
On 25.11.2011, at 14:06, Peter Maydell wrote:
On 24 November 2011 23:43, Alexander Graf ag...@suse.de wrote:
---
v1 - v2:
- make prettier by just wrapping mmap in linux-user/mmap.c
Hmm. I prefer the non-wrapped version :-)
In particular, qemu_mmap() implies that (like other qemu_foo
On 24 November 2011 23:43, Alexander Graf ag...@suse.de wrote:
---
v1 - v2:
- make prettier by just wrapping mmap in linux-user/mmap.c
Hmm. I prefer the non-wrapped version :-)
In particular, qemu_mmap() implies that (like other qemu_foo
wrappers) this is a portability wrapper that should
