Re: Using tracing_off() in __schedule_bug()

[Chase Douglas <chase.douglas@canonical.com>]

On Fri, Mar 12, 2010 at 9:30 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 2010-03-12 at 21:12 -0500, Chase Douglas wrote:
>> On Fri, Mar 12, 2010 at 6:34 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
>> > Hmm, thinking about it more, I would rather have a separate function,
>> > that would call tracing_off() if some variable is set. By default it
>> > would be set, but in case you want to keep tracing after a bug is hit,
>> > you can have a way to disable it.
>> >
>> > I need to write up a patch soon. Thanks for bring this up.
>>
>> I'd be happy to help out in this endeavor if you'd like. I'm wondering
>> if there shouldn't be multiple levels of tracing_off support specified
>> at boot time (disabled on WARNING, BUG, __schedule_bug, OOPS) in an
>> ordered priority way. I.e. tracing_off_bug would leave tracing on for
>> WARNING's, but turn it off for BUG's, schedule bugs, and oopses. The
>> default would be tracing_off_warn, which would call tracing_off on all
>> of the above.
>
> I think that's a bit over-engineering. I'd suggest that you either want
> to disable tracing on an error or you don't. I could add a tracing
> option that lets you stop it. Keep it simple. If it becomes complex, no
> one will use it.

I was thinking that there may be times where you want to skip warnings
to trace real bugs. For example, there's a WARNING that you hit if
your resume takes too long. I may want to skip that warning for the
oops that occurs just after it. As a distro, we also want to be
flexible in our official kernels so we don't have to build special
ones when people hit bugs. It's not as though it would be very
difficult to design with a few priorities, so unless it's really
unnecessary I don't see why we shouldn't. The default would also fire
tracing_off in all cases, so most people wouldn't have to modify it
unless they hit a corner case.

-- Chase