console logging detour via printk

Hi,

drivers/char/Kconfig +0 -0

index e023682..b5d0909 100644

drivers/char/Kconfig +8 -0

+	  feature, you should specify kernel command line option "detour" or write a
+	  positive number into /proc/sys/kernel/console_detour. You can disable
+	  the feature on-line by writing zero into the proc file. By writing a
+	  negative value into the proc file, the feature is disabled permanently
+	  (until next boot).
+
+	  If unsure, say N.
+
 config HW_CONSOLE
 	bool
 	depends on VT && !S390 && !UML

drivers/serial/Kconfig +0 -0

index 9ff47db..20acfab 100644

Quoted 8 lines

Hi,

drivers/char/Kconfig +0 -0

index e023682..b5d0909 100644

drivers/char/Kconfig config VT_CONSOLE · line 74

Quoted 9 lines

drivers/char/Kconfig +6 -0

@@ -66,6 +66,23 @@ config VT_CONSOLE
 
 	  If unsure, say Y.
 
+config VT_CONSOLE_DETOUR
+	bool "Support for VT console detour via printk"
+	depends on VT_CONSOLE
+	default n
+	---help---
+	  If you do say Y here, the support for writing console messages via

If you say Y here,

drivers/char/Kconfig config VT_CONSOLE · line 77

Quoted 3 lines

drivers/char/Kconfig +3 -0

+	  printk is included into VT console code.
+
+	  The feature is usefull to catch all console log. In order to use this

useful log messages.

Quoted 17 lines

drivers/char/Kconfig +8 -0

+	  feature, you should specify kernel command line option "detour" or write a
+	  positive number into /proc/sys/kernel/console_detour. You can disable
+	  the feature on-line by writing zero into the proc file. By writing a
+	  negative value into the proc file, the feature is disabled permanently
+	  (until next boot).
+
+	  If unsure, say N.
+
 config HW_CONSOLE
 	bool
 	depends on VT && !S390 && !UML

drivers/serial/Kconfig +0 -0

index 9ff47db..20acfab 100644

drivers/serial/Kconfig config SERIAL_CORE · line 1039

Quoted 9 lines

drivers/serial/Kconfig +6 -0

@@ -1031,6 +1031,23 @@ config SERIAL_CORE
 config SERIAL_CORE_CONSOLE
 	bool
 
+config SERIAL_CORE_CONSOLE_DETOUR
+	bool "Support for serial console detour via printk"
+	depends on SERIAL_CORE_CONSOLE
+	default n
+	---help---
+	  If you do say Y here, the support for writing console messages via

If you say Y here,

drivers/serial/Kconfig config SERIAL_CORE · line 1042

Quoted 3 lines

drivers/serial/Kconfig +3 -0

+	  printk is included into serial console code. 
+
+	  The feature is usefull to catch all console log. In order to use this

useful log messages.

drivers/serial/Kconfig config SERIAL_CORE · line 1050

Quoted 8 lines

drivers/serial/Kconfig +8 -0

+	  feature, you should specify kernel command line option "detour" or write a
+	  positive number into /proc/sys/kernel/console_detour. You can disable
+	  the feature on-line by writing zero into the proc file. By writing a
+	  negative value into the proc file, the feature is disabled permanently
+	  (until next boot).
+
+	  If unsure, say N.
+

The kernel command line option needs to be added to Documentation/kernel-parameters.txt also, please.

include/linux/console.h struct console { · line 112

Quoted 13 lines

drivers/serial/Kconfig +0 -0

 config CONSOLE_POLL
 	bool
 

include/linux/console.h +2 -0

index dcca533..bc88030 100644
@@ -108,6 +108,12 @@ struct console {
 	struct	 console *next;
 };
 
+extern int console_detour;
+extern void console_printk_detour(const unsigned char *, int);

Please include parameter names in function prototype(s).

include/linux/console.h struct console { · line 115

Quoted 3 lines

include/linux/console.h +3 -0

+
+struct ctl_table;
+int detour_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);

ditto

Quoted 3 lines

include/linux/console.h +1 -0

+
 extern int console_set_on_cmdline;
 

include/linux/console.h struct console { · line 119

Quoted 1 line

include/linux/console.h +0 -0

 extern int add_preferred_console(char *name, int idx, char *options);

Looks interesting/useful to me. Thanks.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Quoted 8 lines

Hi,

drivers/char/Kconfig +0 -0

index e023682..b5d0909 100644

drivers/char/Kconfig config VT_CONSOLE · line 74

Quoted 9 lines

drivers/char/Kconfig +6 -0

@@ -66,6 +66,23 @@ config VT_CONSOLE
 
 	  If unsure, say Y.
 
+config VT_CONSOLE_DETOUR
+	bool "Support for VT console detour via printk"
+	depends on VT_CONSOLE
+	default n
+	---help---
+	  If you do say Y here, the support for writing console messages via

If you say Y here,

drivers/char/Kconfig config VT_CONSOLE · line 77

Quoted 3 lines

drivers/char/Kconfig +3 -0

+	  printk is included into VT console code.
+
+	  The feature is usefull to catch all console log. In order to use this

useful log messages.

Quoted 17 lines

drivers/char/Kconfig +8 -0

+	  feature, you should specify kernel command line option "detour" or write a
+	  positive number into /proc/sys/kernel/console_detour. You can disable
+	  the feature on-line by writing zero into the proc file. By writing a
+	  negative value into the proc file, the feature is disabled permanently
+	  (until next boot).
+
+	  If unsure, say N.
+
 config HW_CONSOLE
 	bool
 	depends on VT && !S390 && !UML

drivers/serial/Kconfig +0 -0

index 9ff47db..20acfab 100644

drivers/serial/Kconfig config SERIAL_CORE · line 1039

Quoted 9 lines

drivers/serial/Kconfig +6 -0

@@ -1031,6 +1031,23 @@ config SERIAL_CORE
 config SERIAL_CORE_CONSOLE
 	bool
 
+config SERIAL_CORE_CONSOLE_DETOUR
+	bool "Support for serial console detour via printk"
+	depends on SERIAL_CORE_CONSOLE
+	default n
+	---help---
+	  If you do say Y here, the support for writing console messages via

If you say Y here,

drivers/serial/Kconfig config SERIAL_CORE · line 1042

Quoted 3 lines

drivers/serial/Kconfig +3 -0

+	  printk is included into serial console code. 
+
+	  The feature is usefull to catch all console log. In order to use this

useful log messages.

drivers/serial/Kconfig config SERIAL_CORE · line 1050

Quoted 8 lines

drivers/serial/Kconfig +8 -0

+	  feature, you should specify kernel command line option "detour" or write a
+	  positive number into /proc/sys/kernel/console_detour. You can disable
+	  the feature on-line by writing zero into the proc file. By writing a
+	  negative value into the proc file, the feature is disabled permanently
+	  (until next boot).
+
+	  If unsure, say N.
+

The kernel command line option needs to be added to Documentation/kernel-parameters.txt also, please.

include/linux/console.h struct console { · line 112

Quoted 13 lines

drivers/serial/Kconfig +0 -0

 config CONSOLE_POLL
 	bool
 

include/linux/console.h +2 -0

index dcca533..bc88030 100644
@@ -108,6 +108,12 @@ struct console {
 	struct	 console *next;
 };
 
+extern int console_detour;
+extern void console_printk_detour(const unsigned char *, int);

Please include parameter names in function prototype(s).

include/linux/console.h struct console { · line 115

Quoted 3 lines

include/linux/console.h +3 -0

+
+struct ctl_table;
+int detour_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, loff_t *);

ditto

Quoted 3 lines

include/linux/console.h +1 -0

+
 extern int console_set_on_cmdline;
 

include/linux/console.h struct console { · line 119

Quoted 1 line

include/linux/console.h +0 -0

 extern int add_preferred_console(char *name, int idx, char *options);

Looks interesting/useful to me. Thanks.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

while i was searching for effective logging of complete console output produced by the kernel and user phase of the boot process, it turned out that only kernel messages imho get systematically cached and stored into log files (if needed). All userspace processes are on their own to use syslog, which is fine, but there are also many console messages reporting the boot status via init scripts, .... I came across the bootlogd daemo, which handles the job of redirecting console output into a log file, but i find it problematic to use especialy, when using initial ram disk image.

So in short i came up with an idea to transform console writes into printks at appropriate code place of some console drivers (the patch includes code for VT console and SERIAL_CORE console drivers). Printks eventually reach console device avoiding the patched part of the console drivers.

Quoted 10 lines

while i was searching for effective logging of complete console output produced by the kernel and user phase of the boot process, it turned out that only kernel messages imho get systematically cached and stored into log files (if needed). All userspace processes are on their own to use syslog, which is fine, but there are also many console messages reporting the boot status via init scripts, .... I came across the bootlogd daemo, which handles the job of redirecting console output into a log file, but i find it problematic to use especialy, when using initial ram disk image.

Quoted 5 lines

So in short i came up with an idea to transform console writes into printks at appropriate code place of some console drivers (the patch includes code for VT console and SERIAL_CORE console drivers). Printks eventually reach console device avoiding the patched part of the console drivers.

What about catching /dev/console instead of VT console, SERIAL_CORE console, ...?
Then it works with whatever console= parameter you specify.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Dne 01.05.2010 (sob) ob 11:00 +0200 je Geert Uytterhoeven zapisal(a):

Quoted 17 lines · Samo Pogacnik

Quoted 15 lines

while i was searching for effective logging of complete console output produced by the kernel and user phase of the boot process, it turned out that only kernel messages imho get systematically cached and stored into log files (if needed). All userspace processes are on their own to use syslog, which is fine, but there are also many console messages reporting the boot status via init scripts, .... I came across the bootlogd daemo, which handles the job of redirecting console output into a log file, but i find it problematic to use especialy, when using initial ram disk image.

So in short i came up with an idea to transform console writes into printks at appropriate code place of some console drivers (the patch includes code for VT console and SERIAL_CORE console drivers). Printks eventually reach console device avoiding the patched part of the console drivers.

Quoted 3 lines

What about catching /dev/console instead of VT console, SERIAL_CORE console, ...?
Then it works with whatever console= parameter you specify.

Could not agree more, but that was as close as i was able to detect the common code and provide something that actually works. Maybe this is already enough to cover all boot consoles?

Quoted 4 lines

Gr{oetje,eeting}s,

Quoted 8 lines

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

regards, Samo

--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

while i was searching for effective logging of complete console output produced by the kernel and user phase of the boot process, it turned out that only kernel messages imho get systematically cached and stored into log files (if needed). All userspace processes are on their own to use syslog, which is fine, but there are also many console messages reporting the boot status via init scripts, .... I came across the bootlogd daemo, which handles the job of redirecting console output into a log file, but i find it problematic to use especialy, when using initial ram disk image.

drivers/char/vt.c +0 -0

@@ -2696,6 +2696,16 @@ static int con_write(struct tty_struct *tty, const unsigned char *buf, int count
 {
 	int	retval;
 

Quoted 9 lines

while i was searching for effective logging of complete console output produced by the kernel and user phase of the boot process, it turned out that only kernel messages imho get systematically cached and stored into log files (if needed). All userspace processes are on their own to use syslog, which is fine, but there are also many console messages reporting the boot status via init scripts, .... I came across the bootlogd daemo, which handles the job of redirecting console output into a log file, but i find it problematic to use especialy, when using initial ram disk image.

So you want to patch the kernel because you can't work out how to do this in userspace ? The distributions seem to have no problem doing this in user space that I can see. It doesn't seem to be a hard user space problem, and there are a ton of things you want to do with this sort of stuff (like network logging) that you can't do in kernel space.

Quoted 7 lines

drivers/char/vt.c +0 -0

@@ -2696,6 +2696,16 @@ static int con_write(struct tty_struct *tty, const unsigned char *buf, int count
 {
 	int	retval;
 

drivers/char/vt.c static int con_write(struct tty_struct *tty, const unsigned char *buf, int count · line 2708

Quoted 10 lines

drivers/char/vt.c +10 -0

+#ifdef CONFIG_VT_CONSOLE_DETOUR
+	if (console_detour) {
+		int idx = vt_console_driver.index - 1;
+ 
+		if ((idx >= 0) && (idx == tty->index)) {
+			console_printk_detour(buf, count);
+			return count;
+		}
+	}
+#endif

This requires you go around hacking up each device which is not a good idea and becomes rapidly unmaintainable.

I suspect what you actually need for such logging might be to write a very simple tty driver whose write method is implemented as printk. That works in the general case and doesn't require hacking up the code everywhere else.

However given your init stuff can trivially use openpty to set up a logged console I am not sure I see the point in doing this in kernel in the first place.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

The distros have no problem logging complete console output into log files or over the network, because they simply do not do it at least for the initrd part of the boot process (i'd be glad, if i'm wrong).

Quoted 4 lines

I suspect what you actually need for such logging might be to write a very simple tty driver whose write method is implemented as printk. That works in the general case and doesn't require hacking up the code everywhere else.

Looks to me that some kernel code is welcome:)?

Quoted 4 lines

However given your init stuff can trivially use openpty to set up a logged console I am not sure I see the point in doing this in kernel in the first place.

As said above, how to bridge kernel boot start and logging daemon start-up without kernel help, especially when initrd is in the way? imho it would be too complicated.

Quoted 3 lines

The distros have no problem logging complete console output into log files or over the network, because they simply do not do it at least for the initrd part of the boot process (i'd be glad, if i'm wrong).

I'd have to double check - but its trivial to move the log if so.

Quoted 6 lines

Quoted 4 lines

I suspect what you actually need for such logging might be to write a very simple tty driver whose write method is implemented as printk. That works in the general case and doesn't require hacking up the code everywhere else.

Looks to me that some kernel code is welcome:)?

I really don't see the point but if you must do it then doing it as its own driver would at least avoid making a mess in the rest of the kernel, at which point it becomes less of a problem

Quoted 5 lines

Quoted 4 lines

However given your init stuff can trivially use openpty to set up a logged console I am not sure I see the point in doing this in kernel in the first place.

Quoted 3 lines

As said above, how to bridge kernel boot start and logging daemon start-up without kernel help, especially when initrd is in the way? imho it would be too complicated.

Put the logging start up in the initrd, its just a ramdisk its not special in any way at all.

Dne 01.05.2010 (sob) ob 12:04 +0100 je Alan Cox zapisal(a):

Quoted 10 lines

Quoted 9 lines

while i was searching for effective logging of complete console output produced by the kernel and user phase of the boot process, it turned out that only kernel messages imho get systematically cached and stored into log files (if needed). All userspace processes are on their own to use syslog, which is fine, but there are also many console messages reporting the boot status via init scripts, .... I came across the bootlogd daemo, which handles the job of redirecting console output into a log file, but i find it problematic to use especialy, when using initial ram disk image.

Quoted 5 lines

So you want to patch the kernel because you can't work out how to do this in userspace ? The distributions seem to have no problem doing this in user space that I can see. It doesn't seem to be a hard user space problem, and there are a ton of things you want to do with this sort of stuff (like network logging) that you can't do in kernel space.

The distros have no problem logging complete console output into log files or over the network, because they simply do not do it at least for the initrd part of the boot process (i'd be glad, if i'm wrong).

Quoted 17 lines · Samo Pogacnik

Dne 01.05.2010 (sob) ob 12:04 +0100 je Alan Cox zapisal(a):

Quoted 15 lines

Quoted 9 lines

while i was searching for effective logging of complete console output produced by the kernel and user phase of the boot process, it turned out that only kernel messages imho get systematically cached and stored into log files (if needed). All userspace processes are on their own to use syslog, which is fine, but there are also many console messages reporting the boot status via init scripts, .... I came across the bootlogd daemo, which handles the job of redirecting console output into a log file, but i find it problematic to use especialy, when using initial ram disk image.

So you want to patch the kernel because you can't work out how to do this in userspace ? The distributions seem to have no problem doing this in user space that I can see. It doesn't seem to be a hard user space problem, and there are a ton of things you want to do with this sort of stuff (like network logging) that you can't do in kernel space.

Quoted 3 lines

The distros have no problem logging complete console output into log files or over the network, because they simply do not do it at least for the initrd part of the boot process (i'd be glad, if i'm wrong).

Mmm...It's an interesting problem. I see in my distro (openSuse) a script called boot.klog that it seems to perform that (even initrd part). In the file boot.msg I can see the initial prints of the kernel and user space scripts.

Dne 02.05.2010 (ned) ob 11:58 +0200 je Marco Stornelli zapisal(a):

Quoted 7 lines

01/05/2010 20:48, Samo Pogacnik wrote:

Mmm...It's an interesting problem. I see in my distro (openSuse) a script called boot.klog that it seems to perform that (even initrd part). In the file boot.msg I can see the initial prints of the kernel and user space scripts.

Thanks for the info.
Is this boot.klog script from the initrd image or from the real rootfs? As you can see, i am still suspicious about the initrd part user console messages:)

Samo