Re: [PATCH] introduce boot_printk()

Previous thread: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption by Sebastien Dugue on Monday, September 15, 2008 - 1:04 am. (27 messages)

Next thread: [PATCH] apci: dump slit v2 by Yinghai Lu on Monday, September 15, 2008 - 1:05 am. (1 message)
From: Yinghai Lu
Date: Monday, September 15, 2008 - 1:05 am

could be enabled via "boot=verbose" to get more debug info

will use it to convert some printk(KERN_DEBUG ...)

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>

---
 include/linux/kernel.h |   19 +++++++++++++++++++
 kernel/printk.c        |   21 +++++++++++++++++++++
 2 files changed, 40 insertions(+)

Index: linux-2.6/include/linux/kernel.h
===================================================================
--- linux-2.6.orig/include/linux/kernel.h
+++ linux-2.6/include/linux/kernel.h
@@ -344,6 +344,25 @@ static inline char *pack_hex_byte(char *
 #endif
 
 /*
+ * Debugging macros
+ */
+#define BOOT_QUIET   0
+#define BOOT_VERBOSE 1
+#define BOOT_SPEW    2
+
+extern int boot_verbosity;
+/*
+ * Define the default level of output to be very little
+ * This can be turned up by using boot=verbose for more
+ * information and boot=spew for _lots_ of information.
+ * boot_verbosity is defined in printk.c
+ */
+#define boot_printk(v, s, a...) do {        \
+		if ((v) <= boot_verbosity)  \
+			printk(s, ##a);    \
+	} while (0)
+
+/*
  *      Display an IP address in readable format.
  */
 
Index: linux-2.6/kernel/printk.c
===================================================================
--- linux-2.6.orig/kernel/printk.c
+++ linux-2.6/kernel/printk.c
@@ -604,6 +604,27 @@ asmlinkage int printk(const char *fmt, .
 	return r;
 }
 
+int boot_verbosity;
+
+static int __init boot_set_verbosity(char *arg)
+{
+	if (!arg)
+		return -EINVAL;
+
+	if (strcmp("spew", arg) == 0)
+		boot_verbosity = BOOT_SPEW;
+	else if (strcmp("verbose", arg) == 0)
+		boot_verbosity = BOOT_VERBOSE;
+	else {
+		printk(KERN_WARNING "boot Verbosity level %s not recognised"
+			" use boot=verbose or boot=spew\n", arg);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+early_param("boot", boot_set_verbosity);
+
 /* cpu currently holding logbuf_lock */
 static volatile unsigned int printk_cpu = UINT_MAX;
 
--

From: Pavel Machek
Date: Monday, September 15, 2008 - 2:58 am

boot= is a bit too generic name, I guess...

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--

From: Yinghai Lu
Date: Monday, September 15, 2008 - 9:14 am

Ingo suggest to use x86=verbose

but some users are in driver/acpi etc

YH
--

From: Randy Dunlap
Date: Monday, September 15, 2008 - 7:54 am

ised; "



---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/
--

From: H. Peter Anvin
Date: Monday, September 15, 2008 - 10:15 am

This seems odd, why not just use KERN_DEBUG?

	-hpa
--

From: Yinghai Lu
Date: Monday, September 15, 2008 - 10:18 am

some guys complained that it is even too verbose with KERN_DEBUG

YH
--

From: H. Peter Anvin
Date: Monday, September 15, 2008 - 10:24 am

I can understand the desire to enable filtering on a 
subsystem-by-subsystem basis, but I think rather than doing a 
subsystem-specific hack we should do something that any subsystem can use.

Perhaps we could extend the current <level> hack to include a subsystem, 
something like:

<7><x86>Your blort driver seems to be befudged, trying blarfing.

... and something like "loglevel=x86:7,acpi:3,..."

	-hpa

--

From: Yinghai Lu
Date: Monday, September 15, 2008 - 10:34 am

sounds good.

every subsystem will have
x86_printk
acpi_printk
pci_printk

YH
--

From: Peter Zijlstra
Date: Tuesday, September 16, 2008 - 7:26 am

doesn't sound like an easily extensible interface, better would be
extending printk with a KERN_subsys tag like proposed.

Perhaps Jason has better ideas - iirc he worked on something similar.

--

From: H. Peter Anvin
Date: Tuesday, September 16, 2008 - 9:06 am

That would be my thinking too.

	-hpa
--

From: Yinghai Lu
Date: Tuesday, September 16, 2008 - 9:42 am

will be printk(KERN_PCI, KERN_DEBUG ".....") ?
and it will be ...KERN_PCI will be int?


YH
--

From: Jeremy Fitzhardinge
Date: Tuesday, September 16, 2008 - 10:44 am

#define X86_DEBUG    KERN_DEBUG SUBSYS_X86
...
    printk(X86_DEBUG "woozle failed the wibble\n);


    J
--

From: Yinghai Lu
Date: Tuesday, September 16, 2008 - 10:45 am

it seem using pci_printk or acpi_printk.. could be more flexible.

otherwise will need to keep update linux/kernel.h to add so call subsys tags...

use only need to
have DEFINE_LOGLEVEL_SETUP(xxx) in c
and have DECLARE_LOGLEVEL(xxx) in .h
then just use xxx_printk

YH
--

From: Yinghai Lu
Date: Tuesday, September 16, 2008 - 10:47 am

and in real subsys could have as many the xxx_printk that user want...

YH
--

From: H. Peter Anvin
Date: Tuesday, September 16, 2008 - 10:53 am

Uh?  You can add the subsys tags elsewhere if you prefer too.

However, there are a few important differences to keep in mind.  Tags 
get logged in the dmesg buffer even if not printed to the kernel, 
whereas a jump-based architecture will not just suppress the output, but 
even the formatting of the output.  Either is a good thing for certain 
things, and a bad thing for other things.

I personally think the kind of things discussed belong in the category 
of "always put in the dmesg buffer", and like the idea of 
subsystem-tagging them.

	-hpa
--

From: Yinghai Lu
Date: Tuesday, September 16, 2008 - 11:10 am

you still can use
pci_printk(v, KERN_PCI KERN_DEBUG "...\n");

if vprintk is expanded to handle KERN_PCI and other tags...
or even you could use
pci_printk(v, KERN_ACPI KERN_DEBUG "...\n");

YH
--

From: H. Peter Anvin
Date: Tuesday, September 16, 2008 - 11:15 am

And the point of this, other than sheer verbosity?

	-hpa
--

From: Yinghai Lu
Date: Tuesday, September 16, 2008 - 11:24 am

let every file or componet of subsystem could control the print out
via loglevel=pci_any_name:7

YH
--

From: H. Peter Anvin
Date: Tuesday, September 16, 2008 - 11:31 am

pci_printk(v, KERN_ACPI KERN_DEBUG "...\n");
^^^^          ^^^^^^^^^

Not only do you have duplication, here, but inconsistency...

	-hpa
--

From: Yinghai Lu
Date: Tuesday, September 16, 2008 - 11:37 am

how about
pci_printk(v, KERN_DEBUG "...\n");

will put
<pci> <7> ...\n
in dmesg bug,

and let vprintk get rid of <pci> like <7>

is that what you want?

YH
--

From: H. Peter Anvin
Date: Tuesday, September 16, 2008 - 11:53 am

First of all, what is the "v" here, and why not just have
printk(KERN_PCI KERN_DEBUG "...\n");

... and we can do #define PCI_DEBUG KERN_PCI KERN_DEBUG even.

We do have a need for special macros when we're doing device-specific 
prefixes, of course.  If that is what your "v" is meant to be, then 
there was an implicit topic shift in the discussion thread.

	-hpa
--

From: Yinghai Lu
Date: Tuesday, September 16, 2008 - 12:24 pm

will try.

YH
--

Previous thread: [PATCH HACK] powerpc: quick hack to get a functional eHEA with hardirq preemption by Sebastien Dugue on Monday, September 15, 2008 - 1:04 am. (27 messages)

Next thread: [PATCH] apci: dump slit v2 by Yinghai Lu on Monday, September 15, 2008 - 1:05 am. (1 message)