wine on FreeBSD

[jean-marc DETREZ]

Hi, 

 

 With the differents mails i receive from users or wine's developers, i
think that:

 

            - Dislike OpenBSD or SRV4,  mincore did'nt fail if the page is
not mapped no [ENOMEM] error condition.

 

-          the FreeBSD man pages say that mmap would fail with [ENOMEM]
error condition if address is in use but in the reality it seems always
return the start address.

 

So for to use wine on FreeBSD before doing a more clean patch i propose to
add this to mmap . I know that it would map memory pages without verify
before that the pages is'nt already map but the man pages say it must failed
so I'm just verify that the result is equal to start address the mmap call
asking for.

 

            

            I do that only when creating System heap because requesting mmap
for 0x800000 start address (without MAP_FIXED) always fail and prevent wine
running on FreeBSD.

 

            I'll do more test to implement a try_mmap_fixed function working
on FreeBSD like this done for SRV4,NetBSD and DARWIN.

 

Jean-marc

[Robert Lunnon]

On Saturday 30 July 2005 04:18, jean-marc DETREZ wrote:
> Hi,
>
> With the differents mails i receive from users or wine's developers, i
> think that:
>
> - Dislike OpenBSD or SRV4,  mincore did'nt fail if the page is
> not mapped no [ENOMEM] error condition.
>
> -          the FreeBSD man pages say that mmap would fail with [ENOMEM]
> error condition if address is in use but in the reality it seems always
> return the start address.
>
> So for to use wine on FreeBSD before doing a more clean patch i propose to
> add this to mmap . I know that it would map memory pages without verify
> before that the pages is'nt already map but the man pages say it must
> failed so I'm just verify that the result is equal to start address the
> mmap call asking for.
>
> I do that only when creating System heap because requesting
> mmap for 0x800000 start address (without MAP_FIXED) always fail and prevent
> wine running on FreeBSD.
>
> I'll do more test to implement a try_mmap_fixed function
> working on FreeBSD like this done for SRV4,NetBSD and DARWIN.
>
> Jean-marc

Actually the fix for SVR4 (Solaris) does work BUT, the numerous vforks cause 
resource problems under Solaris. I already have a patch which does a single 
reserve of 64 MB for the system heap and leaves the rest alone. Other memory 
gets mapped out on the first memory allocate autmagically by the wine 
allocator. This approach seems to work well under Solaris.. From what I know 
is is unlikely (read very improbable) that 64K from 0x80000000 would be in 
use so early in the wine process so a fixed mmap is unlikely to actually 
unmap anything. Still it would be polite to check if possible. (Yo ucan do 
this by reading the processes address space (as) file in /proc on SVR4 
systems as will as mincore


Bob

[Alexandre Julliard]

Robert Lunnon <bobl(a)optushome.com.au> writes:
> Actually the fix for SVR4 (Solaris) does work BUT, the numerous vforks cause 
> resource problems under Solaris. I already have a patch which does a single 
> reserve of 64 MB for the system heap and leaves the rest alone. Other memory 
> gets mapped out on the first memory allocate autmagically by the wine 
> allocator. This approach seems to work well under Solaris..

The problem is that this won't prevent dlopen from mapping things
above 0x80000000, so if Solaris ever does this you'll have trouble
with some applications.

-- 
Alexandre Julliard
julliard(a)winehq.org