2004-10-15 14:43:32

by Daniele Pizzoni

[permalink] [raw]
Subject: janitoring printk with no KERN_ constants, kill all defaults?

I'm investigating this (from the kernel janitors TODO list):

------------------------------------------------------------------------
From: Andrey Panin <pazke at orbita dot don dot sitek dot net>

- check printk() calls (should include appropriate KERN_* constant).

------------------------------------------------------------------------

printk ends up using the default KERN_WARNING constant when no costant
is explicitly specified; the default is changeable. So a printk with
_no_ constant specified means "use the current default" and could be,
maybe in some cases only, a developer choice.

I ask, what rationale there is behind checking all printks to include
the "appropriate" constant? Should then we make printk fail when called
without KERN_ constant? Or can I force with a sed script all defaulted
printk to KERN_WARNING?

I'm looking for advice, or a pointer to an appropriate thread of the
lkml archives.

Thanks
Daniele Pizzoni <[email protected]>



2004-10-15 15:47:32

by Dave Jones

[permalink] [raw]
Subject: Re: janitoring printk with no KERN_ constants, kill all defaults?

On Fri, Oct 15, 2004 at 05:44:59PM +0200, Daniele Pizzoni wrote:

> I ask, what rationale there is behind checking all printks to include
> the "appropriate" constant? Should then we make printk fail when called
> without KERN_ constant? Or can I force with a sed script all defaulted
> printk to KERN_WARNING?

No. Consider this..

printk (KERN_INFO "blah blah ");
if (foo)
printk ("%s", stringptr);
else
printk ("%d", number);
printk ("\n");

There's nothing wrong with any of those printk's, so you
cannot do the checks you mention above.

Dave

2004-10-15 16:17:47

by Nishanth Aravamudan

[permalink] [raw]
Subject: Re: [KJ] janitoring printk with no KERN_ constants, kill all defaults?

On Fri, Oct 15, 2004 at 05:44:59PM +0200, Daniele Pizzoni wrote:
> I'm investigating this (from the kernel janitors TODO list):

<snip>

> I ask, what rationale there is behind checking all printks to include
> the "appropriate" constant? Should then we make printk fail when called
> without KERN_ constant? Or can I force with a sed script all defaulted
> printk to KERN_WARNING?

I think the rationale is to compare the comments from linux/kernel.h for
the KERN_* definitions to their usage in the code and make sure they
correspond accordingly, e.g. KERN_EMERG is only used if the system is
actually unusable.

Hope that helps,
Nish

2004-10-15 16:20:36

by Daniele Pizzoni

[permalink] [raw]
Subject: Re: janitoring printk with no KERN_ constants, kill all defaults?

On ven, 2004-10-15 at 17:46, Dave Jones wrote:
> On Fri, Oct 15, 2004 at 05:44:59PM +0200, Daniele Pizzoni wrote:
>
> > I ask, what rationale there is behind checking all printks to include
> > the "appropriate" constant? Should then we make printk fail when called
> > without KERN_ constant? Or can I force with a sed script all defaulted
> > printk to KERN_WARNING?
>
> No. Consider this..
>
> printk (KERN_INFO "blah blah ");
> if (foo)
> printk ("%s", stringptr);
> else
> printk ("%d", number);
> printk ("\n");
>
> There's nothing wrong with any of those printk's, so you
> cannot do the checks you mention above.

Let me understand... You mean that we should check printk constants for
_consistency_ in their context (that is: for buggish printk code). So
printk without KERN_* constant are not an issue (and the janitors TODO
list entry is a bit puzzling)?

Thanks for helping
Daniele


2004-10-15 17:18:22

by Chuck Ebbert

[permalink] [raw]
Subject: Re: janitoring printk with no KERN_ constants, kill all defaults?

Dave Jones wrote:

> Consider this..
>
> printk (KERN_INFO "blah blah ");
> if (foo)
> printk ("%s", stringptr);
> else
> printk ("%d", number);
> printk ("\n");
>
> There's nothing wrong with any of those printk's, so you
> cannot do the checks you mention above.

But other code can call printk in between on SMP and/or preempt systems,
making a mess of the log. This is a(n old) problem that should be
fixed once and for all, AFAIC.



--Chuck Ebbert 15-Oct-04 13:05:20