Re: [tip:timers/tracing] hrtimer: Add tracepoint for hrtimers
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [tip:timers/tracing] hrtimer: Add tracepoint for hrtimers
- From: Ingo Molnar <mingo@xxxxxxx>
- Date: Tue, 13 Oct 2009 15:26:56 +0200
- Cc: mingo@xxxxxxxxxx, hpa@xxxxxxxxx, mathieu.desnoyers@xxxxxxxxxx, anton@xxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, peterz@xxxxxxxxxxxxx, zhaolei@xxxxxxxxxxxxxx, xiaoguangrong@xxxxxxxxxxxxxx, fweisbec@xxxxxxxxx, tglx@xxxxxxxxxxxxx, kosaki.motohiro@xxxxxxxxxxxxxx, linux-tip-commits@xxxxxxxxxxxxxxx
- In-reply-to: <1255439822.7113.1541.camel@xxxxxxxxxxxxxxxxxxx>
- References: <4A7F8B2B.5020908@xxxxxxxxxxxxxx> <tip-c6a2a1770245f654f35f60e1458d4356680f9519@xxxxxxxxxxxxxx> <1255404309.7113.948.camel@xxxxxxxxxxxxxxxxxxx> <20091013070853.GA13175@xxxxxxx> <1255439822.7113.1541.camel@xxxxxxxxxxxxxxxxxxx>
- User-agent: Mutt/1.5.18 (2008-05-17)
* Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> On Tue, 2009-10-13 at 09:08 +0200, Ingo Molnar wrote:
> > * Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> >
>
> > > (unsigned long long)(((ktime_t) { .tv64 = REC->expires }).tv64)
> > >
> > > Is not easy. It's basically implementing a C interpreter :-(
> >
> > Btw., what i suggested quite some time ago was that we should bind
> > tracepoints by emitting C source code stubs, which tools can then build
> > and link in, using gcc.
>
> Yeah, and I thought about that too. But that kills any chance of
> running the trace on one box (non x86) and reading it on another
> (x86). And that is one of my goals for this.
Why does it kill that chance?
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Index of Archives]
[Linux Stable Commits]
[Linux Stable Kernel]
[Linux Kernel]
[Linux USB Devel]
[Linux Video &Media]
[Linux Audio Users]
[Yosemite News]
[Linux SCSI]