Possibly crazy idea to deal with memory layout problems once and for all

[Mike McCormack]

Troy Rollo wrote:

>>It has a few problems though.  Firstly, we'd miss mmaps done with system
>>calls.
> 
> Yes, but how many apps actually do this?

We wouldn't care about applications, only libraries that use their own 
mmap system call (eg. Wine).

>>Secondly, we'd have to make assumptions about what areas of 
>>memory the kernel would let us map, and what areas of memory were
>>already used in the address map.
> 
> 
> It is possible to discover this by attempting to map all areas. It would not 
> need to be done page-by-page because we could use something akin to a binary 
> search (actually if we really wanted to be rude about it we could grovel 
> at /proc/self/maps, which would work (absent a debugger), but is non-portable 
> - of course this whole technique is non-portable).
> 
> If the system call fails because part of the address space it was attempting 
> to allocate was already used, the same technique could be used to discover 
> what was mapped and mark that space as temporarily "poisoned" (if we later 
> run out of address space, or perhaps at the time we free neighbouring 
> addresses, we could attempt to reclaim it).

Well, what's needed is a proof of concept patch so that we can explore 
the issues with it, show the advantages and submit it to Alexandre to 
finally be rejected :)

> Aren't kernel modules considered a last resort? Would it even win anything 
> given that we still call native libraries which are then likely to call 
> libc's mmap (directly or indirectly)?

I didn't write it to solve this problem in particular... but having the 
kernel know about Wine's special memory layout requirements is probably 
the only way to solve the problem once and for all.

Mike