[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081121131109.GA12241@flint.arm.linux.org.uk>
Date: Fri, 21 Nov 2008 13:11:09 +0000
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Jim Radford <radford@...vanix.net>
Cc: Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
linuxppc-dev@...abs.org, Paul Mundt <lethal@...ux-sh.org>,
Matt Fleming <mjf@...too.org>, Sam Ravnborg <sam@...nborg.org>,
linux-arm-kernel@...ts.arm.linux.org.uk
Subject: Re: [PATCH] ftrace: mcountrecord.pl for arm
On Thu, Nov 20, 2008 at 02:11:49PM -0800, Jim Radford wrote:
> Ingo and Steven,
>
> Here's an updated version of the arch/arm changes for dynamic ftrace
> based on top of your latest tip/master.
Excuse me if I'm rather confused, but...
When ftrace for ARM was originally merged, neither linux-arm-kernel
nor myself were copied with the patches. Now, I'm being sent updates
to code that I've no understanding of and haven't seen before.
I mean, yes, it's nice to be copied with patches which are relevent.
It would've been even nicer to have been copied with the patches adding
ftrace in the first place, so people knew something about it and were
aware of the changes.
It seems to me like there's been a total breakdown of communication
when ftrace was initially merged...
So, questions: has ftrace actually been tested on ARM at all? Has it
been reviewed? Which ARM platforms has it been tried on? How stable
is it? How has it been implemented on ARM? Does it rely on any CPU
specific behaviour?
Looking at the git history, ftrace was merged via Ingo, so I assume
that Ingo has some understanding of this code. So, for the time being
if these are urgent updates, I suggest that updates go through Ingo's
tree rather than mine.
And looking at arch/arm/kernel/ftrace.c, it's incompatible with Thumb2
which we've been working towards supporting. What about SMP? ARM is
a SMP capable architecture now, and I see no locking in there - what
I do see is static data with pointers to it being returned to other
code... Yuck.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists