Re: patches to actually use markers?

David Smith wrote:
> Mathieu Desnoyers wrote:
>> * David Smith ([email protected]) wrote:
>>> Mathieu,
>>>
>>> Now that the markers facility itself has made it in the kernel, do
>>> you have plans on trying to send patches that actually use markers to
>>> lkml?
>>>
>>> For systemtap's use, we'd like to get some actual markers in the
>>> upstream kernel.  Off the top of my head, we might start with adding
>>> markers to system calls (sys_*) that contain the system call's
>>> argument(s).
>>>
>>
>> Hi David,
>>
>> Yes, we have something similar in LTTng, we instrument many widely used
>> system calls to get the detailed arguments.

...

>> It's a good thing that we start having a discussion about these marker
>> sites at this point.
>>
>> Mathieu

I've been looking at your system call tracing patches.  (I've tried
running lttv itself without much luck, but it doesn't really matter for
the sake of this discussion.)

I like the way you use the existing system call tracing points.  So
we're on the same page, here are the markers I'm seeing in
arch/x86/kernel/ptrace32.c after applying
patch-2.6.24-rc2-lttng-0.10-pre23.tar.bz2:

  trace_mark(kernel_arch_syscall_entry, "syscall_id %d ip #p%ld",
			(int)regs->orig_eax, instruction_pointer(regs));

  trace_mark(kernel_arch_syscall_exit, MARK_NOARGS);

For systemtap use, we'd like to have more information than that.  On
syscall entry, we'd like be able to get the arguments,  On syscall exit,
we'd like the to be able to get the return value.  In fact, the easiest
thing would be to supply the same information that audit_syscall_entry()
and audit_syscall_exit() need.

Since I'll bet you've already considered this, I'd like to know why you
decided to go a different way.

Thanks.

-- 
David Smith
[email protected]
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)