lkml.org 
[lkml]   [2003]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: The disappearing sys_call_table export.
On Mon, May 05, 2003 at 01:23:19PM +0200, Terje Eggestad wrote:
> The problem occur when you
> 1. pinn a buffer
> 2. sbrk(-n) or munmap() (usually thru free()) the area the buffer
> 3. a new malloc() resulting in a sbrk(+n) or mmap()
> 4. then my new buffer has the exactly same virtual address as the prev.
>
> (belive it or not this happens, and relatively frequently).

That only shows that you really don't want to use glibc's malloc and
sbrk implementations, but ones that are implemented as mmap in your
driver so you can keep track of it properly. LD_PRELOAD is your friend.

> Lets deal, I'll GPL the trace module if you get me a
> EXPORT_SYMBOL_GPL(sys_call_table);

Who cares about your trace module? That's the wrong approach to start
with. And the removal of the sys_call_table export is not a political
issue but a technical one. The interesting thing would be your memory
manager, but given the above hints you really should be able to fix it yourself
now..

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:35    [W:0.240 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site