Messages in this thread | | | Date | Mon, 2 Feb 2009 23:33:52 -0500 (EST) | From | Steven Rostedt <> | Subject | Re: [PATCH 2/3] trace: fix default boot up tracer |
| |
On Mon, 2 Feb 2009, Andrew Morton wrote: > > > > The lock_kernel addition was added when the BKL became a spinlock again. > > The selftests needed to be able to sleep, and this caused issues. > > Sleeping inside lock_kernel() is quite OK. Confused.
I did not explain that quite well. I need to focus on the emails that I write, and not do it half concentrating on code that I'm also writing :-/
The preempt tracer expects preemption enabled when the self test is executed. Because the self test for preempt tracer is basically:
start_trace(); preempt_disable(); udelay(x); preempt_enable(); stop_trace();
make sure we have a delay.
This failed, because lock_kernel now disables preemption. So that preempt_disable() never triggers the trace, and the test sees that nothing was recorded. This causes a failure to be flagged, and we disable the preempt tracer.
> > What is the call path to this function? Does it all happen under > ftrace_init()? If not, do we risk breaking start_kernel()'s > thou-shalt-not-enable-interrupts-early rule which powerpc (at least) > imposes?
This function is always called via the initcall functions.
> > > The register_tracer was initial written to be pluggable at any time. > > Perhaps in the future to allow modules. But this does not seem to have > > panned out. > > > > Since we have the lock_kernel there anyway, if we ever need to handle > > modules, that will need a different interface anyway. I guess I can nuke > > the unregister tracer. > > And add some __init/__initdatas?
I'll take some time to analyze what can be annotated.
-- Steve >
| |