[lkml]   [2003]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: The disappearing sys_call_table export.

On Mon, 2003-05-05 at 13:23, Terje Eggestad wrote:

> > Again, where's your driver source so we can help you to find a better
> > approach out of that mess?
> >
> The trace module we made to trace munmap() and sbrk() could be opened,
> but you'll be disappointed since all the pinning ( get_user_pages() and
> friends), send() recv() etc are in the drivers for the various hardware,
> most of which are not our property.
> The module works as follows. It catches sbrk(-arg) and munmap() and lays
> out the trace info in a memory area mmap()'able thru the device file.
> So when processes need the trace info they have the info in memory to
> avoid doing a ioctl().
> Thats all we need to know if a given virtual address needs to be
> (re)pinned.

In all fairness this should be done in glibc, but the task of getting it
done there was several orders of magnitude larger than just adding the
syscall intercepts. Serves you right for writing clean code :-)

The thing is of course this *worked* until someone decided to remove the
export of sys_call_table.

Which is a decision that is most probably right, I just need another way
of getting a hook or notification of the sys calls.

> TJ

Terje Eggestad
Scali Scalable Linux Systems

Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE)
P.O.Box 150, Oppsal +47 975 31 574 (MOBILE)
N-0619 Oslo fax: +47 22 62 89 51

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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