Andrew Morton explains flex-mmap in “Re: ptrace single-stepping change breaks Wine” on lkml. Makes a lot of sense when you put it this way. The only downside is that some applications expect the old binary layout and break with the new one.
the ‘after’ layout guarantees that brk area (malloc()) can grow unlimited and mmap() can grow unlimited – they will meet somewhere inbetween when almost all of the VM is used up. [the ‘top’ of the mmaps in the ‘after’ layout is constrained by the stack ulimit – the stack must still fit and we never allocate into the stack’s yet unallocated and growable hole.]
with the ‘before’ layout we’ve got 900 MB for brk() and 1.9GB for mmaps() – a rigid limit.
Muli Ben-Yehuda's journal 
The question is, does the new interface make sure that the old applications have no way of using it by mistake.
Comment by ladypine — January 5, 2005 @ 4:01 PM |
it’s not really an interface, it’s the binary layout in virtual memory. The linker / loader gives you one or the other. Do you mean the application needs a way to know which layout it’s using?
Comment by mulix — January 5, 2005 @ 4:11 PM |
I mean there must never be a situation in which a program is running, but it does the wrong thing, because it uses the old standard.
No results are OK, wrong results are, well, wrong.
If it does not link, it is fine with me.
What about dynamically linked programs? Will the stop working and give a linker error? Or will they start running, and crash out of the blue?
Comment by ladypine — January 5, 2005 @ 4:43 PM