All of lore.kernel.org
 help / color / mirror / Atom feed
From: liubo <liubo2009@cn.fujitsu.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Linux Btrfs <linux-btrfs@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Chris Mason <chris.mason@oracle.com>
Subject: Re: [RFC PATCH] Trace: use unsigned long long in trace print frames
Date: Sat, 02 Apr 2011 09:41:35 +0800	[thread overview]
Message-ID: <4D967ECF.8050802@cn.fujitsu.com> (raw)
In-Reply-To: <1301665762.2160.22.camel@gandalf.stny.rr.com>

On 04/01/2011 09:49 PM, Steven Rostedt wrote:
> On Fri, 2011-04-01 at 14:42 +0800, liubo wrote:
>> While adding tracepoint for btrfs, I got a problem:
>>
>> btrfs uses some macros with "ULL" type, but tracepoint's macros,
>> __print_[flags,symbols](), only have "unsigned long", so on 32bit box
>> there will be 64->32 truncate WARNINGs when compiling.
>>
>> Here I'm inclined to make the replacement to clear those WARNINGs.
> 
> Hmm, I don't like this. unsigned long is a natural word for
> architectures, I don't want to have 32 bit suffer because one user is
> doing something with ULL.
> 
> A better solution is to add a trace_print_flags_u64 or something, that
> can be used for cases that u64 is needed. For archs were sizeof(long) ==
> sizeof(u64) we can have the two macros/structs be the same.
> 

All right, a u64 specific one is also in my mind. :)

thanks,
liubo

> -- Steve
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2011-04-02  1:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-01  6:42 [RFC PATCH] Trace: use unsigned long long in trace print frames liubo
2011-04-01 13:49 ` Steven Rostedt
2011-04-02  1:41   ` liubo [this message]
2011-04-06  9:18   ` [PATCH] Trace: add __print_symbolic_u64 to avoid warnings on 32bit machine liubo
2011-04-15 16:24     ` Randy Dunlap
2011-04-15 16:37       ` Christoph Hellwig
2011-04-18 18:11     ` Steven Rostedt
2011-04-19  1:08       ` liubo
2011-04-19  1:35       ` [PATCH 1/2] tracing: " liubo
2011-04-29 10:01         ` liubo
2011-05-01 15:35           ` Steven Rostedt
2011-05-26  5:49             ` liubo
2011-05-25 12:27               ` Steven Rostedt
2011-05-25 16:12                 ` Randy Dunlap
2011-05-25 16:47                   ` Steven Rostedt
2011-05-25 16:50                     ` Randy Dunlap
2011-05-26  1:08                     ` Li Zefan
2011-05-26  1:17                       ` Steven Rostedt
2011-05-27 12:48         ` [tip:perf/urgent] tracing: Add " tip-bot for liubo
2011-04-19  1:35       ` [PATCH 2/2] tracing: update btrfs's tracepoints to use u64 interface liubo
2011-05-27 12:48         ` [tip:perf/urgent] tracing: Update " tip-bot for liubo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D967ECF.8050802@cn.fujitsu.com \
    --to=liubo2009@cn.fujitsu.com \
    --cc=chris.mason@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.