public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* janitoring printk with no KERN_ constants, kill all defaults?
@ 2004-10-15 15:44 Daniele Pizzoni
  2004-10-15 15:46 ` Dave Jones
  2004-10-15 16:17 ` [KJ] " Nishanth Aravamudan
  0 siblings, 2 replies; 5+ messages in thread
From: Daniele Pizzoni @ 2004-10-15 15:44 UTC (permalink / raw)
  To: lkml, kernel-janitors; +Cc: pazke

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 <auouo@tin.it>



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: janitoring printk with no KERN_ constants, kill all defaults?
  2004-10-15 15:44 janitoring printk with no KERN_ constants, kill all defaults? Daniele Pizzoni
@ 2004-10-15 15:46 ` Dave Jones
  2004-10-15 17:20   ` Daniele Pizzoni
  2004-10-15 16:17 ` [KJ] " Nishanth Aravamudan
  1 sibling, 1 reply; 5+ messages in thread
From: Dave Jones @ 2004-10-15 15:46 UTC (permalink / raw)
  To: Daniele Pizzoni; +Cc: lkml, kernel-janitors, pazke

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [KJ] janitoring printk with no KERN_ constants, kill all defaults?
  2004-10-15 15:44 janitoring printk with no KERN_ constants, kill all defaults? Daniele Pizzoni
  2004-10-15 15:46 ` Dave Jones
@ 2004-10-15 16:17 ` Nishanth Aravamudan
  1 sibling, 0 replies; 5+ messages in thread
From: Nishanth Aravamudan @ 2004-10-15 16:17 UTC (permalink / raw)
  To: Daniele Pizzoni; +Cc: lkml, kernel-janitors, pazke

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: janitoring printk with no KERN_ constants, kill all defaults?
@ 2004-10-15 17:06 Chuck Ebbert
  0 siblings, 0 replies; 5+ messages in thread
From: Chuck Ebbert @ 2004-10-15 17:06 UTC (permalink / raw)
  To: Dave Jones; +Cc: Daniele Pizzoni, linux-kernel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: janitoring printk with no KERN_ constants, kill all defaults?
  2004-10-15 15:46 ` Dave Jones
@ 2004-10-15 17:20   ` Daniele Pizzoni
  0 siblings, 0 replies; 5+ messages in thread
From: Daniele Pizzoni @ 2004-10-15 17:20 UTC (permalink / raw)
  To: Dave Jones; +Cc: lkml

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



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2004-10-15 17:18 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-15 15:44 janitoring printk with no KERN_ constants, kill all defaults? Daniele Pizzoni
2004-10-15 15:46 ` Dave Jones
2004-10-15 17:20   ` Daniele Pizzoni
2004-10-15 16:17 ` [KJ] " Nishanth Aravamudan
  -- strict thread matches above, loose matches on Subject: below --
2004-10-15 17:06 Chuck Ebbert

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox