xfs
[Top] [All Lists]

Re: [PATCH] get rid of fname[] for tracing functions

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: [PATCH] get rid of fname[] for tracing functions
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Wed, 7 Mar 2007 08:27:53 +0000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <45EE2EF3.8090707@xxxxxxxxxxx>
References: <45EE2EF3.8090707@xxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.2.2i
On Tue, Mar 06, 2007 at 09:18:11PM -0600, Eric Sandeen wrote:
> this gets rid of the
> 
> #ifdef XFS_BMAP_TRACE
>        static char             fname[] = "xfs_iextents_copy";
> #endif
> 
> ugliness littered in the bmap code for tracing, and instead just uses 
> gcc's __FUNCTION__, which never gets out of sync with the actual 
> function name....
> 
> It also makes some of this tracing more consistently use the
> 
> #define        XFS_BMBT_TRACE_ARGBI(c,b,i)     \
>        xfs_bmbt_trace_argbi(__FUNCTION__, c, b, i, __LINE__)
> 
> type constructs, to automatically pick up the gcc extensions.

Very nice.  I might hear some people to scream that we should use
the C99 __func__ and not the __FUNCTION__ gccism, but __FUNCTION__
is what the rest of the Linux kernel uses, and can be emulated with
a trivial

        #define __func__ __FUNCTION__

on any non-gcc C99 system.

> the vn tracing could probably get a similar treatment, so that every 
> call to vn_trace_foo wouldn't have to include a function name and a 
> __builtin_return_address, but could be done via macros... it's currently 
> a mishmash of __FUNCTION__ and "function" *shrug* what do you think?

It should probably use __FUNCTION__ and hide use of both __FUNCTION__
and __builtin_return_address behind a macro.


<Prev in Thread] Current Thread [Next in Thread>