From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752050AbZCHLY6 (ORCPT ); Sun, 8 Mar 2009 07:24:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751304AbZCHLYs (ORCPT ); Sun, 8 Mar 2009 07:24:48 -0400 Received: from mail-ew0-f177.google.com ([209.85.219.177]:52535 "EHLO mail-ew0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751256AbZCHLYr (ORCPT ); Sun, 8 Mar 2009 07:24:47 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=dOGZ44baIartG8R1pyICk6e57EaE9cggi1oloDKxOVf9YHHxtaq2kxfwNOpqySzRTj O1n/6fouIJ9TOF9Dm+XX3YG3dJkgvtYriqRHfRAcqF5jnFdX4UFYj7yvKR2KD9izY6tm 4kGp2L6Uv0K/wuP+MUv2S8p3aZTVMyrDilKbI= Date: Sun, 8 Mar 2009 12:24:41 +0100 From: Frederic Weisbecker To: Peter Zijlstra Cc: Ingo Molnar , LKML , Lai Jiangshan , Steven Rostedt , Mathieu Desnoyers , Jiaying Zhang , Martin Bligh , Arjan van de Ven Subject: Re: [RFC][PATCH 0/2] Syscalls tracing Message-ID: <20090308112440.GB5000@nowhere> References: <1236401580-5758-1-git-send-email-fweisbec@gmail.com> <1236428118.6376.239.camel@laptop> <20090307160246.GB6075@nowhere> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090307160246.GB6075@nowhere> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 07, 2009 at 05:02:47PM +0100, Frederic Weisbecker wrote: > On Sat, Mar 07, 2009 at 01:15:18PM +0100, Peter Zijlstra wrote: > > On Sat, 2009-03-07 at 05:52 +0100, Frederic Weisbecker wrote: > > > Here is a first attempt, quick one-shot, to provide a syscall tracing > > > infrastructure on ftrace. > > > > > > The RFC prefix is here to reflect its ugliness on various parts. > > > The compromise between tracing reliabilty and speed is hard to balance. > > > For example I guess the basic and horrid string mask should be dropped in favour > > > of something else, which takes care of the volatile strings from the userspace. > > > > > > But I hope a lot of ideas to make it better will come along this discussion. > > > > Can't you abuse the SYSCALL_DEFINE macros? This current approach looks > > like it will replicate the syscall table. > > > > > Ah, I did not even think about it. > I will be able to get the number of parameters. Sounds good. But I will > still need a way to store their format somewhere. > Ok, we can iterate through sections datas for each one and then generate the format string depending of the types of the parameters. We can even to it once at boot time. The last thing is the need to match the exact syscall entry from this section when we enter a syscall. Don't know yet how I will do that but I will think about it.