I've used that call too, and I've read entry.S a lot.
> Would it be reasonable to change entry.S to check after a normal
> (non-traced) system call for PF_TRACESYS, and trap (and clear the
> flag) then?
This would add a test and an untaken conditional jump to the fast path
for system calls. That's a very, very hot fast path so you would have
to persuade Linus that your facility is very useful to lots of people
in order to get this.
It's much easier to add code to the slow path that starts in tracesys.
You could try to add a few more bits that conditionalize PF_TRACESYS
there. As long as the fast path has only one test-and-untaken-jump then
the fast-path performance will be the same.
But I think you can just do everything you want in user-space anyways.
Why don't you just turn on PF_TRACESYS at the beginning of execution,
and then keep your own state in your parent process about which traps
to take action on and which to pass through?
Michael Elizabeth Chastain
<mailto:mec@shout.net>
"love without fear"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/