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 mailto:terje.eggestad@scali.no Scali Scalable Linux Systems http://www.scali.com
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 NORWAY _________________________________________________________________________
- 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/
This archive was generated by hypermail 2b29 : Wed May 07 2003 - 22:00:21 EST