On Wed, Feb 24, 2010 at 01:07:15PM -0800, [email protected] wrote:
>
> The patch titled
> kernel.h: printk/panic/string cleanup
> has been added to the -mm tree. Its filename is
> kernelh-printk-panic-string-cleanup.patch
>
> Before you just go and hit "reply", please:
> a) Consider who else should be cc'ed
> b) Prefer to cc a suitable mailing list as well
> c) Ideally: find the original patch on the mailing list and do a
> reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
> out what to do about this
>
> The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
Andrew, please don't merge this patch.
I'm not against the idea kernel.h gets split up a bit, by having
a prink.h and panic.h included from kernel.h for example.
But this patch breaks bisection: some tracing general helpers are
removed here but re-integrated in a different header only in a subsequent
patch in the series. This should be done in the same patch, otherwise it
breaks the build in the middle of the set.
The other problem, as Steve noticed, is that the tracing prototypes are
moved in ring_buffer.h (in the subsequent patch), which is not the right
place as the ring buffer is not only for tracing purpose. And also
it moves functions out of kernel.h while these are really useful for
general purposes.
That said, it's probably sane to think about a new header to put
these tracing prototypes, if it's included by kernel.h,
linux/ftrace.h is already filled with non-general purpose things.
So may be linux/trace.h ? Yeah this could be confusing, Steve what
do you think?
And all in one, it would probably better to split this in three
patches: one that moves printk helpers out of kernel.h to printk.h,
another following the same pattern for panic things and another one
for tracing things.
Thanks.
On Wed, 2010-02-24 at 22:34 +0100, Frederic Weisbecker wrote:
> On Wed, Feb 24, 2010 at 01:07:15PM -0800, [email protected] wrote:
> >
> That said, it's probably sane to think about a new header to put
> these tracing prototypes, if it's included by kernel.h,
> linux/ftrace.h is already filled with non-general purpose things.
> So may be linux/trace.h ? Yeah this could be confusing, Steve what
> do you think?
>
> And all in one, it would probably better to split this in three
> patches: one that moves printk helpers out of kernel.h to printk.h,
> another following the same pattern for panic things and another one
> for tracing things.
Yeah, I'm fine with moving the tracing related stuff in kernel.h into a
trace.h file and keep ftrace.h specific to ftrace in general.
But I still find it necessary that trace.h gets included by kernel.h.
I can just imaging Thomas yelling at me more when he adds a
tracing_off() or trace_printk() somewhere and then gets a warning about
it not being declared.
I also gave that patch a NAK, in case that carries any weight.
-- Steve
On Thu, Feb 25, 2010 at 5:34 AM, Frederic Weisbecker <[email protected]> wrote:
> On Wed, Feb 24, 2010 at 01:07:15PM -0800, [email protected] wrote:
>>
>> The patch titled
>> kernel.h: printk/panic/string cleanup
>> has been added to the -mm tree. Its filename is
>> kernelh-printk-panic-string-cleanup.patch
>>
>> Before you just go and hit "reply", please:
>> a) Consider who else should be cc'ed
>> b) Prefer to cc a suitable mailing list as well
>> c) Ideally: find the original patch on the mailing list and do a
>> reply-to-all to that, adding suitable additional cc's
>>
>> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>>
>> See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
>> out what to do about this
>>
>> The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
>
>
>
> Andrew, please don't merge this patch.
>
> I'm not against the idea kernel.h gets split up a bit, by having
> a prink.h and panic.h included from kernel.h for example.
>
> But this patch breaks bisection: some tracing general helpers are
> removed here but re-integrated in a different header only in a subsequent
> patch in the series. This should be done in the same patch, otherwise it
> breaks the build in the middle of the set.
Yeah, my wrong, I will send a update version of this patch. Thank you.
>
> The other problem, as Steve noticed, is that the tracing prototypes are
> moved in ring_buffer.h (in the subsequent patch), which is not the right
> place as the ring buffer is not only for tracing purpose. And also
> it moves functions out of kernel.h while these are really useful for
> general purposes.
>
> That said, it's probably sane to think about a new header to put
> these tracing prototypes, if it's included by kernel.h,
> linux/ftrace.h is already filled with non-general purpose things.
> So may be linux/trace.h ? Yeah this could be confusing, Steve what
> do you think?
>
> And all in one, it would probably better to split this in three
> patches: one that moves printk helpers out of kernel.h to printk.h,
> another following the same pattern for panic things and another one
> for tracing things.
Fine to me.
>
> Thanks.
>
>
--
Regards
dave
On Thu, Feb 25, 2010 at 6:21 AM, Steven Rostedt <[email protected]> wrote:
> On Wed, 2010-02-24 at 22:34 +0100, Frederic Weisbecker wrote:
>> On Wed, Feb 24, 2010 at 01:07:15PM -0800, [email protected] wrote:
>> >
>
>> That said, it's probably sane to think about a new header to put
>> these tracing prototypes, if it's included by kernel.h,
>> linux/ftrace.h is already filled with non-general purpose things.
>> So may be linux/trace.h ? Yeah this could be confusing, Steve what
>> do you think?
>>
>> And all in one, it would probably better to split this in three
>> patches: one that moves printk helpers out of kernel.h to printk.h,
>> another following the same pattern for panic things and another one
>> for tracing things.
>
> Yeah, I'm fine with moving the tracing related stuff in kernel.h into a
> trace.h file and keep ftrace.h specific to ftrace in general.
>
> But I still find it necessary that trace.h gets included by kernel.h.
Thanks, will do
>
> I can just imaging Thomas yelling at me more when he adds a
> tracing_off() or trace_printk() somewhere and then gets a warning about
> it not being declared.
>
> I also gave that patch a NAK, in case that carries any weight.
>
> -- Steve
>
>
>
--
Regards
dave