On 21.12.2011, at 03:43, 陳韋任 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" mean
> >> 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
> > "-
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. Wher
> 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 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_fo
On 24 November 2011 23:43, Alexander Graf 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 be used f
