Re: [PATCH] detour TTY driver - now ttyprintk
On Thu, Aug 26, 2010 at 07:24:44PM +0200, Samo Pogacnik wrote: > On 25.08.2010 (sre) at 11:16 -0700 Greg KH wrote: > > On Wed, Aug 25, 2010 at 07:14:37PM +0100, Alan Cox wrote: > > > > > > That's one extra process, not that much, right? > > > > > > > > > > About 150K or so way too much and its not robust. > > > > > > > > Fair enough. So, with this driver, would it make sense for the distros > > > > to switch over to using it instead of the above line in their initrd? > > > > > > Distros no - I doubt any normal PC distro would turn the facility on. > > > Embedded - yes especially deeply embedded. > > > > So should this be dependent on CONFIG_EMBEDDED then? > > > > Should i resend the patch with CONFIG_EMBEDDED dependency enabled? I do > not have any real objections to that, except that the driver operates > the same way regardless of the (non-)embedded configuration. No, I can change it when I apply the patch next week (sorry, swamped at the moment.) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
On 25.08.2010 (sre) at 11:16 -0700 Greg KH wrote: > On Wed, Aug 25, 2010 at 07:14:37PM +0100, Alan Cox wrote: > > > > > That's one extra process, not that much, right? > > > > > > > > About 150K or so way too much and its not robust. > > > > > > Fair enough. So, with this driver, would it make sense for the distros > > > to switch over to using it instead of the above line in their initrd? > > > > Distros no - I doubt any normal PC distro would turn the facility on. > > Embedded - yes especially deeply embedded. > > So should this be dependent on CONFIG_EMBEDDED then? > Should i resend the patch with CONFIG_EMBEDDED dependency enabled? I do not have any real objections to that, except that the driver operates the same way regardless of the (non-)embedded configuration. regards, Samo -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
On Wed, 25 Aug 2010 11:16:47 -0700 Greg KH wrote: > On Wed, Aug 25, 2010 at 07:14:37PM +0100, Alan Cox wrote: > > > > > That's one extra process, not that much, right? > > > > > > > > About 150K or so way too much and its not robust. > > > > > > Fair enough. So, with this driver, would it make sense for the distros > > > to switch over to using it instead of the above line in their initrd? > > > > Distros no - I doubt any normal PC distro would turn the facility on. > > Embedded - yes especially deeply embedded. > > So should this be dependent on CONFIG_EMBEDDED then? No objection to that -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
On 25.08.2010 Greg KH wrote: > Samo, care to resend the patch? > Sure, here it is: --- I hope that this TTY driver is ok for merging. It is very basic - removed all flow control and rate limiting. Patch has been generated against 2.6.34 kernel version. Ttyprintk is a pseudo TTY driver, which allows users to make printk messages, via output to ttyprintk device. It is possible to store "console" messages inline with kernel messages for better analyses of the boot process, for example. regards, Samo --- Signed-off-by: Samo Pogacnik diff --git a_linux/Documentation/devices.txt b_linux/Documentation/devices.txt index 53d64d3..71aef33 100644 --- a_linux/Documentation/devices.txt +++ b_linux/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/ttyprintkUser messages via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 diff --git a_linux/drivers/char/Kconfig b_linux/drivers/char/Kconfig index 3141dd3..5c38a06 100644 --- a_linux/drivers/char/Kconfig +++ b_linux/drivers/char/Kconfig @@ -485,6 +485,20 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. +config TTY_PRINTK + bool "TTY driver to output user messages via printk" + default n + ---help--- + If you say Y here, the support for writing user messages (i.e. + console messages) via printk is available. + + The feature is useful to inline user messages with kernel + messages. + In order to use this feature, you should output user messages + to /dev/ttyprintk or redirect console to this TTY. + + If unsure, say N. + config BRIQ_PANEL tristate 'Total Impact briQ front panel driver' depends on PPC_CHRP diff --git a_linux/drivers/char/Makefile b_linux/drivers/char/Makefile index f957edf..ed60f45 100644 --- a_linux/drivers/char/Makefile +++ b_linux/drivers/char/Makefile @@ -11,6 +11,7 @@ obj-y += mem.o random.o tty_io.o n_tty.o tty_ioctl.o tty_ldisc.o tty_buffer.o t obj-$(CONFIG_LEGACY_PTYS) += pty.o obj-$(CONFIG_UNIX98_PTYS) += pty.o +obj-$(CONFIG_TTY_PRINTK) += ttyprintk.o obj-y += misc.o obj-$(CONFIG_VT) += vt_ioctl.o vc_screen.o selection.o keyboard.o obj-$(CONFIG_BFIN_JTAG_COMM) += bfin_jtag_comm.o diff --git a_linux/drivers/char/ttyprintk.c b_linux/drivers/char/ttyprintk.c new file mode 100644 index 000..c40c161 --- /dev/null +++ b_linux/drivers/char/ttyprintk.c @@ -0,0 +1,225 @@ +/* + * linux/drivers/char/ttyprintk.c + * + * Copyright (C) 2010 Samo Pogacnik + * + * This program is free software; you can redistribute it and/or modify + * it under the smems of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + */ + +/* + * This pseudo device allows user to make printk messages. It is possible + * to store "console" messages inline with kernel messages for better analyses + * of the boot process, for example. + */ + +#include +#include +#include + +struct ttyprintk_port { + struct tty_port port; + struct mutex port_write_mutex; +}; + +static struct ttyprintk_port tpk_port; + +/* + * Our simple preformatting supports transparent output of (time-stamped) + * printk messages (also suitable for logging service): + * - any cr is replaced by nl + * - adds a ttyprintk source tag in front of each line + * - too long message is fragmeted, with '\'nl between fragments + * - TPK_STR_SIZE isn't really the write_room limiting factor, bcause + * it is emptied on the fly during preformatting. + */ +#define TPK_STR_SIZE 508 /* should be bigger then max expected line length */ +#define TPK_MAX_ROOM 4096 /* we could assume 4K for instance */ +static const char *tpk_tag = "[U] "; /* U for User */ +static int tpk_curr; + +static int tpk_printk(const unsigned char *buf, int count) +{ + static char tmp[TPK_STR_SIZE + 4]; + int i = tpk_curr; + + if (buf == NULL) { + /* flush tmp[] */ + if (tpk_curr > 0) { + /* non nl or cr terminated message - add nl */ + tmp[tpk_curr + 0] = '\n'; + tmp[tpk_curr + 1] = '\0'; + printk(KERN_INFO "%s%s", tpk_tag, tmp); + tpk_curr = 0; + } + return i; + } + + for (i = 0; i < count; i++) { + tmp[tpk_curr] = buf[i]; + if (tpk_curr < TPK_STR_SIZE) { + switch (buf[i]) { + case '\r': +
Re: [PATCH] detour TTY driver - now ttyprintk
On Wed, Aug 25, 2010 at 07:14:37PM +0100, Alan Cox wrote: > > > > That's one extra process, not that much, right? > > > > > > About 150K or so way too much and its not robust. > > > > Fair enough. So, with this driver, would it make sense for the distros > > to switch over to using it instead of the above line in their initrd? > > Distros no - I doubt any normal PC distro would turn the facility on. > Embedded - yes especially deeply embedded. So should this be dependent on CONFIG_EMBEDDED then? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
> > > That's one extra process, not that much, right? > > > > About 150K or so way too much and its not robust. > > Fair enough. So, with this driver, would it make sense for the distros > to switch over to using it instead of the above line in their initrd? Distros no - I doubt any normal PC distro would turn the facility on. Embedded - yes especially deeply embedded. > Ok, I didn't realize it really was that big. libc page tables app page tables stacks (kernel and user) arguments/exec page buffers Yes - it soon adds up. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
On Wed, Aug 25, 2010 at 06:11:08PM +0100, Alan Cox wrote: > > Would that work for this driver in use as a console? > > Yes > > > exec < /dev/console > /dev/kmsg 2>&1 > > > > That's one extra process, not that much, right? > > About 150K or so way too much and its not robust. Fair enough. So, with this driver, would it make sense for the distros to switch over to using it instead of the above line in their initrd? > > > You also want errors to get out (or stored) even if there are crashes - > > > which the Fedora one is not very good at. To be fair in the Fedora world > > > its not a big deal to say 'Oh dear, boot with '. Embedded isn't the > > > same, and you want to capture the odd rare error reliably. > > > > again, the above exec line should work for what the embedded people > > want, right? > > We didn't *need* devtmpfs either - that was a little bit of user space. > It's a similar thing - you can do the job better in 1.5K of kernel code > than 150K or more of user space - which is not trivial on a box with no > swap. Ok, I didn't realize it really was that big. Samo, care to resend the patch? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
> Would that work for this driver in use as a console? Yes > exec < /dev/console > /dev/kmsg 2>&1 > > That's one extra process, not that much, right? About 150K or so way too much and its not robust. > > You also want errors to get out (or stored) even if there are crashes - > > which the Fedora one is not very good at. To be fair in the Fedora world > > its not a big deal to say 'Oh dear, boot with '. Embedded isn't the > > same, and you want to capture the odd rare error reliably. > > again, the above exec line should work for what the embedded people > want, right? We didn't *need* devtmpfs either - that was a little bit of user space. It's a similar thing - you can do the job better in 1.5K of kernel code than 150K or more of user space - which is not trivial on a box with no swap. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
On Wed, Aug 25, 2010 at 11:08:13AM +0100, Alan Cox wrote: > > > Do you want to be able to flip between a real debug interface and a > > > logging device on the same software set without risking changing behaviour > > > > I don't understand this point. > > A tty has a very specific set of behaviours simply by being a tty. Some > applications rely upon them so being able to flip between the two > interfaces is useful. Would that work for this driver in use as a console? > > Seriously, look at how Fedora 14 handles this, why can't you do the same > > for embedded systems all from userspace, no additional code needed > > anywhere. > > Its a whole set of extra processes and daemons and stuff, and > minimally uses something like 70K even if its very compact (8K stack, 40K+ > page tables, 16K of buffers, code, data) - oh and I forgot the fifo > buffering and pty cost - so its near 100K. 1.5K v 100K - for something > 1.5K of kernel code that anyone else can turn off and would be off by > default ? exec < /dev/console > /dev/kmsg 2>&1 That's one extra process, not that much, right? > On a lot of embedded systems you don't have all the stuff Fedora carts > around. No modules, initrds, magic front end processes, graphical startup > daemons etc, all of which work to produce that feature IFF you have pty > support in your kernel, and for the current code also glibc. It sounded like they had an initrd that they cared about here. > You also want errors to get out (or stored) even if there are crashes - > which the Fedora one is not very good at. To be fair in the Fedora world > its not a big deal to say 'Oh dear, boot with '. Embedded isn't the > same, and you want to capture the odd rare error reliably. again, the above exec line should work for what the embedded people want, right? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
> > Do you want to be able to flip between a real debug interface and a > > logging device on the same software set without risking changing behaviour > > I don't understand this point. A tty has a very specific set of behaviours simply by being a tty. Some applications rely upon them so being able to flip between the two interfaces is useful. > > Do you want to load a 70K daemon and an initrd or burn about 1.5K on a > > kernel interface ? > > I'd rather burn 0K on the one we have today :) So say "N" when configuring > Seriously, look at how Fedora 14 handles this, why can't you do the same > for embedded systems all from userspace, no additional code needed > anywhere. Its a whole set of extra processes and daemons and stuff, and minimally uses something like 70K even if its very compact (8K stack, 40K+ page tables, 16K of buffers, code, data) - oh and I forgot the fifo buffering and pty cost - so its near 100K. 1.5K v 100K - for something 1.5K of kernel code that anyone else can turn off and would be off by default ? On a lot of embedded systems you don't have all the stuff Fedora carts around. No modules, initrds, magic front end processes, graphical startup daemons etc, all of which work to produce that feature IFF you have pty support in your kernel, and for the current code also glibc. You also want errors to get out (or stored) even if there are crashes - which the Fedora one is not very good at. To be fair in the Fedora world its not a big deal to say 'Oh dear, boot with '. Embedded isn't the same, and you want to capture the odd rare error reliably. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
On Wed, Aug 25, 2010 at 09:40, Kay Sievers wrote: > On Wed, Aug 25, 2010 at 01:12, Greg KH wrote: >> On Wed, Aug 25, 2010 at 12:22:21AM +0100, Alan Cox wrote: >>> > No, it does cover that. You should be able to do that with a simple >>> > console redirection to /dev/kmsg What happened when you tried to do >>> > that? >>> >>> stty: standard input: Inappropriate ioctl for device >> >> Kay, how does systemd handle the kmsg console redirection? > > Systemd does not steal the console, this is done by plymouth, in the > same way blogd can do that. It uses a pty and rewrites the messages. > > Systemd does pass syslog to the kernel buffer during early boot. Init > provides /dev/log. With systemd, the started services usually don't > get the console connected, but use syslog anyway or the stdout/err > gets redirected to syslog. > > With systemd the console is not too useful because we start everything > in parallel. If all the services would put out stuff there like sysv > did, it would look like a real mess. Or isn't that what you asked for? We just write the stuff that arrives at syslog to /dev/kmsg to put things in the kernel log buffer. Also initrds are usually using exec < /dev/console > /dev/kmsg 2>&1 to get stuff directly to the kernel buffer. What does /dev/ttyprintk offer on top of that? Kay -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
On Wed, Aug 25, 2010 at 01:12, Greg KH wrote: > On Wed, Aug 25, 2010 at 12:22:21AM +0100, Alan Cox wrote: >> > No, it does cover that. You should be able to do that with a simple >> > console redirection to /dev/kmsg What happened when you tried to do >> > that? >> >> stty: standard input: Inappropriate ioctl for device > > Kay, how does systemd handle the kmsg console redirection? Systemd does not steal the console, this is done by plymouth, in the same way blogd can do that. It uses a pty and rewrites the messages. Systemd does pass syslog to the kernel buffer during early boot. Init provides /dev/log. With systemd, the started services usually don't get the console connected, but use syslog anyway or the stdout/err gets redirected to syslog. With systemd the console is not too useful because we start everything in parallel. If all the services would put out stuff there like sysv did, it would look like a real mess. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
2010/8/25 Greg KH : > On Wed, Aug 25, 2010 at 12:51:52AM +0100, Alan Cox wrote: > > Seriously, look at how Fedora 14 handles this, why can't you do the same > for embedded systems all from userspace, no additional code needed > anywhere. > > thanks, > > greg k-h > -- Samo sometimes ago I gave you some information on the system startup about OpenSuse, have you look at it? It's possible that what Greg said, it's true. Regards, Marco -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
On Wed, Aug 25, 2010 at 12:51:52AM +0100, Alan Cox wrote: > > > - formatting > > > > Ick, we really want to format things from userspace here? > > Depends what you are trying to do. > > Put an embedded hat on > > Do you want to be able to flip between a real debug interface and a > logging device on the same software set without risking changing behaviour I don't understand this point. > Do you want to load a 70K daemon and an initrd or burn about 1.5K on a > kernel interface ? I'd rather burn 0K on the one we have today :) Seriously, look at how Fedora 14 handles this, why can't you do the same for embedded systems all from userspace, no additional code needed anywhere. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
> > - formatting > > Ick, we really want to format things from userspace here? Depends what you are trying to do. Put an embedded hat on Do you want to be able to flip between a real debug interface and a logging device on the same software set without risking changing behaviour Do you want to load a 70K daemon and an initrd or burn about 1.5K on a kernel interface ? Alan -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
On Wed, Aug 25, 2010 at 12:22:21AM +0100, Alan Cox wrote: > > No, it does cover that. You should be able to do that with a simple > > console redirection to /dev/kmsg What happened when you tried to do > > that? > > stty: standard input: Inappropriate ioctl for device Kay, how does systemd handle the kmsg console redirection? > It's value is twofold > > - formatting Ick, we really want to format things from userspace here? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
> No, it does cover that. You should be able to do that with a simple > console redirection to /dev/kmsg What happened when you tried to do > that? stty: standard input: Inappropriate ioctl for device It's value is twofold - formatting - tty ioctls work as they should on a console (eg vhangup) and its a tiny driver with no impact on the rest of the kernel - so to me it seems useful in that form. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
On Wed, Aug 25, 2010 at 12:50:32AM +0200, Samo Pogacnik wrote: > Dne 24.08.2010 (tor) ob 15:20 -0700 je Greg KH zapisal(a): > > > > And what about the normal way of just writing to /dev/kmsg to do this? > > > > Why a whole new driver for this same functionality? > > > I must admit, i was not aware of the /dev/kmsg driver, but i made a few > > > tests and found out that it seems not to be possible to redirect console > > > to kmsg. > > > > See how systemd does this, as it sounds like exactly what you want to > > do. Look in either Fedora 14, or openSUSE Factory for examples of this, > > with no kernel changes needed. > > > I'll check out systemd. > > however:) > It may be that systemd does not cover the initrd part of the > initialization and it may be an overkill do introduce systemd to an > existing system just to be analyzed. No, it does cover that. You should be able to do that with a simple console redirection to /dev/kmsg What happened when you tried to do that? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
Dne 24.08.2010 (tor) ob 15:20 -0700 je Greg KH zapisal(a): > > > And what about the normal way of just writing to /dev/kmsg to do this? > > > Why a whole new driver for this same functionality? > > I must admit, i was not aware of the /dev/kmsg driver, but i made a few > > tests and found out that it seems not to be possible to redirect console > > to kmsg. > > See how systemd does this, as it sounds like exactly what you want to > do. Look in either Fedora 14, or openSUSE Factory for examples of this, > with no kernel changes needed. > I'll check out systemd. however:) It may be that systemd does not cover the initrd part of the initialization and it may be an overkill do introduce systemd to an existing system just to be analyzed. regards, Samo -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
On Wed, Aug 25, 2010 at 12:09:57AM +0200, Samo Pogacnik wrote: > On 24.08.2010 (Tue) at 14:10 -0700 Greg KH wrote: > > On Tue, Aug 24, 2010 at 10:57:50PM +0200, Samo Pogacnik wrote: > > > On 25.06.2010 (Fri) at 12:03 +0100 Alan Cox wrote: > > > > With my devices.txt owner hat on I'll allocate the minor as you suggest > > > > (and double check this causes no problems), with my tty hat on can you > > > > send it to GregKH for merging into the tree. > > > > > > Hi, > > > > > > I hope that this TTY driver is ok for merging. It is very basic - > > > removed all flow control and rate limiting. Patch has been generated > > > against 2.6.34 kernel version. > > > > > > Ttyprintk is a pseudo TTY driver, which allows users to make printk > > > messages, > > > via output to ttyprintk device. It is possible to store "console" messages > > > inline with kernel messages for better analyses of the boot process, for > > > example. > > > > Why does this need to be a tty driver? Why not a misc device? > Thanks for the response. I'll try to explain. > Well it all started with a kernel hack, which internaly redirected > console output to printk function to be able to capture console messages > inline with real kernel messages. Console messages have also been > automatically stored via system logging facility, which was very useful > especially for analyzes of the initrd part of the userspace system > initialization. Through initial posts (thread: console logging detour > via printk) Alan suggested, that a separate TTY driver could provide > this functionality and that may initial hacking isn't acceptable. That's what kmsg can do :) > > And what about the normal way of just writing to /dev/kmsg to do this? > > Why a whole new driver for this same functionality? > I must admit, i was not aware of the /dev/kmsg driver, but i made a few > tests and found out that it seems not to be possible to redirect console > to kmsg. See how systemd does this, as it sounds like exactly what you want to do. Look in either Fedora 14, or openSUSE Factory for examples of this, with no kernel changes needed. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
On 24.08.2010 (Tue) at 14:10 -0700 Greg KH wrote: > On Tue, Aug 24, 2010 at 10:57:50PM +0200, Samo Pogacnik wrote: > > On 25.06.2010 (Fri) at 12:03 +0100 Alan Cox wrote: > > > With my devices.txt owner hat on I'll allocate the minor as you suggest > > > (and double check this causes no problems), with my tty hat on can you > > > send it to GregKH for merging into the tree. > > > > Hi, > > > > I hope that this TTY driver is ok for merging. It is very basic - > > removed all flow control and rate limiting. Patch has been generated > > against 2.6.34 kernel version. > > > > Ttyprintk is a pseudo TTY driver, which allows users to make printk > > messages, > > via output to ttyprintk device. It is possible to store "console" messages > > inline with kernel messages for better analyses of the boot process, for > > example. > > Why does this need to be a tty driver? Why not a misc device? Thanks for the response. I'll try to explain. Well it all started with a kernel hack, which internaly redirected console output to printk function to be able to capture console messages inline with real kernel messages. Console messages have also been automatically stored via system logging facility, which was very useful especially for analyzes of the initrd part of the userspace system initialization. Through initial posts (thread: console logging detour via printk) Alan suggested, that a separate TTY driver could provide this functionality and that may initial hacking isn't acceptable. > > And what about the normal way of just writing to /dev/kmsg to do this? > Why a whole new driver for this same functionality? I must admit, i was not aware of the /dev/kmsg driver, but i made a few tests and found out that it seems not to be possible to redirect console to kmsg. regards, Samo -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
On Tue, Aug 24, 2010 at 11:16:41PM +0100, Alan Cox wrote: > > Why does this need to be a tty driver? Why not a misc device? > > So you can use it as a"console" (in the user space sense) tty device on > embedded devices which don't have a meaningful normal output subsystem. But can't you do that today with kmsg? The startup of systemd does this in a way that handles all of the log messages very nicely, and the embedded people are sure to pick it up as well because of the simplicity. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
> Why does this need to be a tty driver? Why not a misc device? So you can use it as a"console" (in the user space sense) tty device on embedded devices which don't have a meaningful normal output subsystem. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
On Tue, Aug 24, 2010 at 10:57:50PM +0200, Samo Pogacnik wrote: > On 25.06.2010 (Fri) at 12:03 +0100 Alan Cox wrote: > > With my devices.txt owner hat on I'll allocate the minor as you suggest > > (and double check this causes no problems), with my tty hat on can you > > send it to GregKH for merging into the tree. > > Hi, > > I hope that this TTY driver is ok for merging. It is very basic - > removed all flow control and rate limiting. Patch has been generated > against 2.6.34 kernel version. > > Ttyprintk is a pseudo TTY driver, which allows users to make printk messages, > via output to ttyprintk device. It is possible to store "console" messages > inline with kernel messages for better analyses of the boot process, for > example. Why does this need to be a tty driver? Why not a misc device? And what about the normal way of just writing to /dev/kmsg to do this? Why a whole new driver for this same functionality? confused, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
On 25.06.2010 (Fri) at 12:03 +0100 Alan Cox wrote: > With my devices.txt owner hat on I'll allocate the minor as you suggest > (and double check this causes no problems), with my tty hat on can you > send it to GregKH for merging into the tree. Hi, I hope that this TTY driver is ok for merging. It is very basic - removed all flow control and rate limiting. Patch has been generated against 2.6.34 kernel version. Ttyprintk is a pseudo TTY driver, which allows users to make printk messages, via output to ttyprintk device. It is possible to store "console" messages inline with kernel messages for better analyses of the boot process, for example. regards, Samo --- Signed-off-by: Samo Pogacnik diff --git a_linux/Documentation/devices.txt b_linux/Documentation/devices.txt index 53d64d3..71aef33 100644 --- a_linux/Documentation/devices.txt +++ b_linux/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/ttyprintkUser messages via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 diff --git a_linux/drivers/char/Kconfig b_linux/drivers/char/Kconfig index 3141dd3..5c38a06 100644 --- a_linux/drivers/char/Kconfig +++ b_linux/drivers/char/Kconfig @@ -485,6 +485,20 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. +config TTY_PRINTK + bool "TTY driver to output user messages via printk" + default n + ---help--- + If you say Y here, the support for writing user messages (i.e. + console messages) via printk is available. + + The feature is useful to inline user messages with kernel + messages. + In order to use this feature, you should output user messages + to /dev/ttyprintk or redirect console to this TTY. + + If unsure, say N. + config BRIQ_PANEL tristate 'Total Impact briQ front panel driver' depends on PPC_CHRP diff --git a_linux/drivers/char/Makefile b_linux/drivers/char/Makefile index f957edf..ed60f45 100644 --- a_linux/drivers/char/Makefile +++ b_linux/drivers/char/Makefile @@ -11,6 +11,7 @@ obj-y += mem.o random.o tty_io.o n_tty.o tty_ioctl.o tty_ldisc.o tty_buffer.o t obj-$(CONFIG_LEGACY_PTYS) += pty.o obj-$(CONFIG_UNIX98_PTYS) += pty.o +obj-$(CONFIG_TTY_PRINTK) += ttyprintk.o obj-y += misc.o obj-$(CONFIG_VT) += vt_ioctl.o vc_screen.o selection.o keyboard.o obj-$(CONFIG_BFIN_JTAG_COMM) += bfin_jtag_comm.o diff --git a_linux/drivers/char/ttyprintk.c b_linux/drivers/char/ttyprintk.c new file mode 100644 index 000..c40c161 --- /dev/null +++ b_linux/drivers/char/ttyprintk.c @@ -0,0 +1,225 @@ +/* + * linux/drivers/char/ttyprintk.c + * + * Copyright (C) 2010 Samo Pogacnik + * + * This program is free software; you can redistribute it and/or modify + * it under the smems of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + */ + +/* + * This pseudo device allows user to make printk messages. It is possible + * to store "console" messages inline with kernel messages for better analyses + * of the boot process, for example. + */ + +#include +#include +#include + +struct ttyprintk_port { + struct tty_port port; + struct mutex port_write_mutex; +}; + +static struct ttyprintk_port tpk_port; + +/* + * Our simple preformatting supports transparent output of (time-stamped) + * printk messages (also suitable for logging service): + * - any cr is replaced by nl + * - adds a ttyprintk source tag in front of each line + * - too long message is fragmeted, with '\'nl between fragments + * - TPK_STR_SIZE isn't really the write_room limiting factor, bcause + * it is emptied on the fly during preformatting. + */ +#define TPK_STR_SIZE 508 /* should be bigger then max expected line length */ +#define TPK_MAX_ROOM 4096 /* we could assume 4K for instance */ +static const char *tpk_tag = "[U] "; /* U for User */ +static int tpk_curr; + +static int tpk_printk(const unsigned char *buf, int count) +{ + static char tmp[TPK_STR_SIZE + 4]; + int i = tpk_curr; + + if (buf == NULL) { + /* flush tmp[] */ + if (tpk_curr > 0) { + /* non nl or cr terminated message - add nl */ + tmp[tpk_curr + 0] = '\n'; + tmp[tpk_curr + 1] = '\0'; + printk(KERN_INFO "%s%s", tpk_tag, tmp); + tpk_curr = 0; + } + return i; + } + + for (i = 0; i < count; i++) { + tmp[
Re: [PATCH] detour TTY driver - now ttyprintk
On 25.06.2010 (Fri) at 12:03 +0100 Alan Cox wrote: > With my devices.txt owner hat on I'll allocate the minor as you suggest > (and double check this causes no problems), with my tty hat on can you > send it to GregKH for merging into the tree. Hi, I hope that this TTY driver is ok for merging. It is very basic - removed all flow control and rate limiting. Patch has been generated against 2.6.34 kernel version. regards, Samo --- Signed-off-by: Samo Pogacnik diff --git a_linux/Documentation/devices.txt b_linux/Documentation/devices.txt index 53d64d3..71aef33 100644 --- a_linux/Documentation/devices.txt +++ b_linux/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/ttyprintkUser messages via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 diff --git a_linux/drivers/char/Kconfig b_linux/drivers/char/Kconfig index 3141dd3..5c38a06 100644 --- a_linux/drivers/char/Kconfig +++ b_linux/drivers/char/Kconfig @@ -485,6 +485,20 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. +config TTY_PRINTK + bool "TTY driver to output user messages via printk" + default n + ---help--- + If you say Y here, the support for writing user messages (i.e. + console messages) via printk is available. + + The feature is useful to inline user messages with kernel + messages. + In order to use this feature, you should output user messages + to /dev/ttyprintk or redirect console to this TTY. + + If unsure, say N. + config BRIQ_PANEL tristate 'Total Impact briQ front panel driver' depends on PPC_CHRP diff --git a_linux/drivers/char/Makefile b_linux/drivers/char/Makefile index f957edf..ed60f45 100644 --- a_linux/drivers/char/Makefile +++ b_linux/drivers/char/Makefile @@ -11,6 +11,7 @@ obj-y += mem.o random.o tty_io.o n_tty.o tty_ioctl.o tty_ldisc.o tty_buffer.o t obj-$(CONFIG_LEGACY_PTYS) += pty.o obj-$(CONFIG_UNIX98_PTYS) += pty.o +obj-$(CONFIG_TTY_PRINTK) += ttyprintk.o obj-y += misc.o obj-$(CONFIG_VT) += vt_ioctl.o vc_screen.o selection.o keyboard.o obj-$(CONFIG_BFIN_JTAG_COMM) += bfin_jtag_comm.o diff --git a_linux/drivers/char/ttyprintk.c b_linux/drivers/char/ttyprintk.c new file mode 100644 index 000..c40c161 --- /dev/null +++ b_linux/drivers/char/ttyprintk.c @@ -0,0 +1,225 @@ +/* + * linux/drivers/char/ttyprintk.c + * + * Copyright (C) 2010 Samo Pogacnik + * + * This program is free software; you can redistribute it and/or modify + * it under the smems of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + */ + +/* + * This pseudo device allows user to make printk messages. It is possible + * to store "console" messages inline with kernel messages for better analyses + * of the boot process, for example. + */ + +#include +#include +#include + +struct ttyprintk_port { + struct tty_port port; + struct mutex port_write_mutex; +}; + +static struct ttyprintk_port tpk_port; + +/* + * Our simple preformatting supports transparent output of (time-stamped) + * printk messages (also suitable for logging service): + * - any cr is replaced by nl + * - adds a ttyprintk source tag in front of each line + * - too long message is fragmeted, with '\'nl between fragments + * - TPK_STR_SIZE isn't really the write_room limiting factor, bcause + * it is emptied on the fly during preformatting. + */ +#define TPK_STR_SIZE 508 /* should be bigger then max expected line length */ +#define TPK_MAX_ROOM 4096 /* we could assume 4K for instance */ +static const char *tpk_tag = "[U] "; /* U for User */ +static int tpk_curr; + +static int tpk_printk(const unsigned char *buf, int count) +{ + static char tmp[TPK_STR_SIZE + 4]; + int i = tpk_curr; + + if (buf == NULL) { + /* flush tmp[] */ + if (tpk_curr > 0) { + /* non nl or cr terminated message - add nl */ + tmp[tpk_curr + 0] = '\n'; + tmp[tpk_curr + 1] = '\0'; + printk(KERN_INFO "%s%s", tpk_tag, tmp); + tpk_curr = 0; + } + return i; + } + + for (i = 0; i < count; i++) { + tmp[tpk_curr] = buf[i]; + if (tpk_curr < TPK_STR_SIZE) { + switch (buf[i]) { + case '\r': + /* replace cr with nl */ + tmp
Re: [PATCH] detour TTY driver - now ttyprintk
On Tue, Aug 24, 2010 at 10:03:13PM +0200, Samo Pogacnik wrote: > On 25.06.2010 (Fri) at 12:03 +0100 Alan Cox wrote: > > With my devices.txt owner hat on I'll allocate the minor as you suggest > > (and double check this causes no problems), with my tty hat on can you > > send it to GregKH for merging into the tree. > > Hi, > > I hope that this TTY driver is ok for merging. It is very basic - > removed all flow control and rate limiting. Patch has been generated > against 2.6.34 kernel version. > > regards, Samo > --- > Signed-off-by: Samo Pogacnik I need some information on what this patch is, and why we would want it, so that it can be put into the changelog. Care to resend it with that information present? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
Hi, Please bear with me for a bit longer, because i got slightly modified perspective of some things i did within the driver. I.e. somewhere down the road i forgot that my pre-formatting function does not really limit output buffer size with its "one-line" buffer size. So now 4K output size is assumed and always provided by write_room(). The other thing is that i tried to resolve two things being in conflict. I tried to fit driver to existing distro initialization, which required immediate output also for not line terminated strings. And on the other hand not line terminated strings could have been provided by line discipline all the time. So i finally removed immediate output code and let user takes care by terminating lines if immediate output is required. There is additional possibility to fine tune ratelimiting and printk delaying parameters via defines also with more comments added. Alan, if you agree, i would send this one to GregKH? regards, Samo --- Signed-off-by: Samo Pogacnik diff --git a_linux/Documentation/devices.txt b_linux/Documentation/devices.txt index 53d64d3..71aef33 100644 --- a_linux/Documentation/devices.txt +++ b_linux/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/ttyprintkUser messages via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 diff --git a_linux/drivers/char/Kconfig b_linux/drivers/char/Kconfig index 3141dd3..5c38a06 100644 --- a_linux/drivers/char/Kconfig +++ b_linux/drivers/char/Kconfig @@ -485,6 +485,20 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. +config TTY_PRINTK + bool "TTY driver to output user messages via printk" + default n + ---help--- + If you say Y here, the support for writing user messages (i.e. + console messages) via printk is available. + + The feature is useful to inline user messages with kernel + messages. + In order to use this feature, you should output user messages + to /dev/ttyprintk or redirect console to this TTY. + + If unsure, say N. + config BRIQ_PANEL tristate 'Total Impact briQ front panel driver' depends on PPC_CHRP diff --git a_linux/drivers/char/Makefile b_linux/drivers/char/Makefile index f957edf..ed60f45 100644 --- a_linux/drivers/char/Makefile +++ b_linux/drivers/char/Makefile @@ -11,6 +11,7 @@ obj-y += mem.o random.o tty_io.o n_tty.o tty_ioctl.o tty_ldisc.o tty_buffer.o t obj-$(CONFIG_LEGACY_PTYS) += pty.o obj-$(CONFIG_UNIX98_PTYS) += pty.o +obj-$(CONFIG_TTY_PRINTK) += ttyprintk.o obj-y += misc.o obj-$(CONFIG_VT) += vt_ioctl.o vc_screen.o selection.o keyboard.o obj-$(CONFIG_BFIN_JTAG_COMM) += bfin_jtag_comm.o diff --git a_linux/drivers/char/ttyprintk.c b_linux/drivers/char/ttyprintk.c new file mode 100644 index 000..22da614 --- /dev/null +++ b_linux/drivers/char/ttyprintk.c @@ -0,0 +1,283 @@ +/* + * linux/drivers/char/ttyprintk.c + * + * Copyright (C) 2010 Samo Pogacnik + * + * This program is free software; you can redistribute it and/or modify + * it under the smems of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + */ + +/* + * This pseudo device allows user to make printk messages. It is possible + * to store "console" messages inline with kernel messages for better analyses + * of the boot process, for example. + */ + +#include +#include +#include +#include +#include +#include + +struct ttyprintk_port { + struct tty_port port; + struct mutex port_write_mutex; +}; + +static struct ttyprintk_port tpk_port; + +/* + * Ratelimiting support to handle to much output to this device, + * because of explicit writes or because of unintentional loop + * setup (caught printks again sent to this device). + * Max TPK...BURST printks per TPK...INTERVAL + */ +#define TPK_RATELIMIT_INTERVAL (1 * HZ) +#define TPK_RATELIMIT_BURST 10 +static struct ratelimit_state ttyprintk_rs = { + .interval = TPK_RATELIMIT_INTERVAL, + .burst = TPK_RATELIMIT_BURST, +}; + +static int tpk_ratelimiting; + +/* + * Our private ratelimit function, to suppress its printk warnings about + * missed callbacks, which doesn't really happen (not discarding messages). + * Calls final printk at the end. + * Raise delay on every TPK_SCALE_DELAY ratelimited printk for another + * milisecond and can not exceed TPK_MAX_DELAY. + * Delay is reset allways, when ratelimiting ends. + */ +#define TPK_SCALE_DELAY 10 +#define TPK_MAX_DELAY 2000 /* 1 secs */ +stat
Re: [PATCH] detour TTY driver - now ttyprintk
Dne 27.06.2010 (ned) ob 14:35 +0100 je Alan Cox zapisal(a): > > I thought that this would automatically reduce processor load, which is > > obviously not the case. Sorry for the delay, but i am trying to figure > > out how to slow down write method when under pressure. > > Ok I played with this a bit. Much to my surprise until I thought about it > in detail it all works fine without any of the ratelimiting at all. There > is a problem if you manage to redirect the console *in kernel* to the > printk driver, but that needs stopping anyway and rate limit won't fix it > (you blow the stack before it kicks in) > > In the case where userspace loads it hard and its a graphical console > then we use a lot of CPU power drawing stuff on screen, but killing the > process does as is expected. > > With a serial console the printk itself blocks which blocks the line > discipline which in turn slows stuff down. > > The only two bad things I can see how to cause are > > - Slowing down output by stuffing lots of extra data into the port (which > I can do anyway just fine) so isn't worse than before. > > - Filling up the dmesg log easily and hiding important messages. Not > really a problem in this case bcause the whole point of this is > embedded and capturing those messages as if they were system ones. > > So much to my surprise the flow control is a red herring and best left > out. > > Alan If without flow control, do you think it makes sense to very slowly introduce more and more delay (interruptible) into tty's write operation when output rate is "too" high? That way non-error conditions would not suffer (not discarding any messages, only delaying additional 1 msec on 100 writes), when ratelimit would have been exceeded from time to time. And on the other hand endless high-volume output, which is probably an error condition, would slowly give away more and more of its processing time. Maybe this would also help if output is made on behalf of some high RT-prioritized process? Of course, i can easily remove ratelimiting as well, if the situation with flow control isn't clear and this only complicates things. Samo -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
> I thought that this would automatically reduce processor load, which is > obviously not the case. Sorry for the delay, but i am trying to figure > out how to slow down write method when under pressure. Ok I played with this a bit. Much to my surprise until I thought about it in detail it all works fine without any of the ratelimiting at all. There is a problem if you manage to redirect the console *in kernel* to the printk driver, but that needs stopping anyway and rate limit won't fix it (you blow the stack before it kicks in) In the case where userspace loads it hard and its a graphical console then we use a lot of CPU power drawing stuff on screen, but killing the process does as is expected. With a serial console the printk itself blocks which blocks the line discipline which in turn slows stuff down. The only two bad things I can see how to cause are - Slowing down output by stuffing lots of extra data into the port (which I can do anyway just fine) so isn't worse than before. - Filling up the dmesg log easily and hiding important messages. Not really a problem in this case bcause the whole point of this is embedded and capturing those messages as if they were system ones. So much to my surprise the flow control is a red herring and best left out. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
> > +static int tpk_write_room(struct tty_struct *tty) > > +{ > > + int ret = tpk_space; > > + > > + /* allow char by char under max pressure */ > > + if (tpk_space == 0) > > + tpk_space = 1; > > That won't do what you think, the ldisc will keep seeing progress and > generate millions of 1 byte I/Os in a loop ! > Somewhat changed to slowly increase delay in write, if ratelimiting doesn't end. > Otherwise looks excellent. > Thanks to you. > > > + switch (cmd) { > > + /* Stop TIOCCONS */ > > + case TIOCCONS: > > + return -EOPNOTSUPP; > > And I'll fix this bit up to work properly in the core code. > > > With my devices.txt owner hat on I'll allocate the minor as you suggest > (and double check this causes no problems), with my tty hat on can you > send it to GregKH for merging into the tree. I am not sure if i understand. Should i exclude devices.txt from patch before sending it to GregKH? Samo --- Signed-off-by: Samo Pogacnik diff --git a_linux/Documentation/devices.txt b_linux/Documentation/devices.txt index 53d64d3..71aef33 100644 --- a_linux/Documentation/devices.txt +++ b_linux/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/ttyprintkUser messages via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 diff --git a_linux/drivers/char/Kconfig b_linux/drivers/char/Kconfig index 3141dd3..5c38a06 100644 --- a_linux/drivers/char/Kconfig +++ b_linux/drivers/char/Kconfig @@ -485,6 +485,20 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. +config TTY_PRINTK + bool "TTY driver to output user messages via printk" + default n + ---help--- + If you say Y here, the support for writing user messages (i.e. + console messages) via printk is available. + + The feature is useful to inline user messages with kernel + messages. + In order to use this feature, you should output user messages + to /dev/ttyprintk or redirect console to this TTY. + + If unsure, say N. + config BRIQ_PANEL tristate 'Total Impact briQ front panel driver' depends on PPC_CHRP diff --git a_linux/drivers/char/Makefile b_linux/drivers/char/Makefile index f957edf..ed60f45 100644 --- a_linux/drivers/char/Makefile +++ b_linux/drivers/char/Makefile @@ -11,6 +11,7 @@ obj-y += mem.o random.o tty_io.o n_tty.o tty_ioctl.o tty_ldisc.o tty_buffer.o t obj-$(CONFIG_LEGACY_PTYS) += pty.o obj-$(CONFIG_UNIX98_PTYS) += pty.o +obj-$(CONFIG_TTY_PRINTK) += ttyprintk.o obj-y += misc.o obj-$(CONFIG_VT) += vt_ioctl.o vc_screen.o selection.o keyboard.o obj-$(CONFIG_BFIN_JTAG_COMM) += bfin_jtag_comm.o diff --git a_linux/drivers/char/ttyprintk.c b_linux/drivers/char/ttyprintk.c new file mode 100644 index 000..2fefa93 --- /dev/null +++ b_linux/drivers/char/ttyprintk.c @@ -0,0 +1,297 @@ +/* + * linux/drivers/char/ttyprintk.c + * + * Copyright (C) 2010 Samo Pogacnik + * + * This program is free software; you can redistribute it and/or modify + * it under the smems of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + */ + +/* + * This pseudo device allows user to make printk messages. It is possible + * to store "console" messages inline with kernel messages for better analyses + * of the boot process, for example. + */ + +#include +#include +#include +#include +#include +#include + +struct ttyprintk_port { + struct tty_port port; + struct mutex port_write_mutex; +}; + +static struct ttyprintk_port tpk_port; + +#define TTY_PRINTK_STR_SIZE 508 +static int tpk_space = TTY_PRINTK_STR_SIZE; +static const char *tpk_tag = "[U] "; /* U for User */ + +/* + * Ratelimiting support to handle to much output to this device, + * because of explicit writes or because of unintentional loop + * setup (caught printks again sent to this device). + */ +static struct ratelimit_state ttyprintk_rs = { + .interval = DEFAULT_RATELIMIT_INTERVAL, + .burst = DEFAULT_RATELIMIT_BURST, +}; + +static int tpk_ratelimiting; + +#define ttyprintk_printk(fmt, ...) \ +{ \ + printk(KERN_INFO fmt, ##__VA_ARGS__); \ +} + +/* + * Our private ratelimit function, to suppress its printk warnings about + * missed callbacks, which are irrelevant in a flow control mechanism. + */ +static void ttyprintk_ratelimit(struct ratelimit_state *rs, int count) +{ + /* clear ratelimit missed callbacks counter */ + rs->missed = 0; + if (__ratelimit(rs)) { +
Re: [PATCH] detour TTY driver - now ttyprintk
> > +static int tpk_write_room(struct tty_struct *tty) > > +{ > > + int ret = tpk_space; > > + > > + /* allow char by char under max pressure */ > > + if (tpk_space == 0) > > + tpk_space = 1; > > That won't do what you think, the ldisc will keep seeing progress and > generate millions of 1 byte I/Os in a loop ! I thought that this would automatically reduce processor load, which is obviously not the case. Sorry for the delay, but i am trying to figure out how to slow down write method when under pressure. And that setting tpk_space to 1 would then be just in case we reach 0 to enable further processing. Samo -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
> +static int tpk_write_room(struct tty_struct *tty) > +{ > + int ret = tpk_space; > + > + /* allow char by char under max pressure */ > + if (tpk_space == 0) > + tpk_space = 1; That won't do what you think, the ldisc will keep seeing progress and generate millions of 1 byte I/Os in a loop ! Otherwise looks excellent. > + switch (cmd) { > + /* Stop TIOCCONS */ > + case TIOCCONS: > + return -EOPNOTSUPP; And I'll fix this bit up to work properly in the core code. With my devices.txt owner hat on I'll allocate the minor as you suggest (and double check this causes no problems), with my tty hat on can you send it to GregKH for merging into the tree. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
> > in some logical manner. And the other would be to use ratelimit support > > to switch between max and zero in write_room answer and remove other > > retelimit response? > > Yes - except that a driver isn't permitted to reduce the write room space > by more than bytes written. That is if you offer 512 bytes you can't > offer 0 until 512 bytes have been written - hence the design of the pseudo > code I posted in the previous message. Now flow control is provided in a way that each write ratelimit false detection shrinks available space for its output lenth. On the other hand write returns available space back to maximum on true ratelimit detection result. Additionaly each next write_room returns at least one character space under high load, if zero space is reached. Additionally a private ttyprintk_ratelimit function is provided to suppress "missed callbacks" printks, because we do not really miss anything. regards, Samo Signed-off-by: Samo Pogacnik diff --git a_linux/Documentation/devices.txt b_linux/Documentation/devices.txt index 53d64d3..71aef33 100644 --- a_linux/Documentation/devices.txt +++ b_linux/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/ttyprintkUser messages via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 diff --git a_linux/drivers/char/Kconfig b_linux/drivers/char/Kconfig index 3141dd3..5c38a06 100644 --- a_linux/drivers/char/Kconfig +++ b_linux/drivers/char/Kconfig @@ -485,6 +485,20 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. +config TTY_PRINTK + bool "TTY driver to output user messages via printk" + default n + ---help--- + If you say Y here, the support for writing user messages (i.e. + console messages) via printk is available. + + The feature is useful to inline user messages with kernel + messages. + In order to use this feature, you should output user messages + to /dev/ttyprintk or redirect console to this TTY. + + If unsure, say N. + config BRIQ_PANEL tristate 'Total Impact briQ front panel driver' depends on PPC_CHRP diff --git a_linux/drivers/char/Makefile b_linux/drivers/char/Makefile index f957edf..ed60f45 100644 --- a_linux/drivers/char/Makefile +++ b_linux/drivers/char/Makefile @@ -11,6 +11,7 @@ obj-y += mem.o random.o tty_io.o n_tty.o tty_ioctl.o tty_ldisc.o tty_buffer.o t obj-$(CONFIG_LEGACY_PTYS) += pty.o obj-$(CONFIG_UNIX98_PTYS) += pty.o +obj-$(CONFIG_TTY_PRINTK) += ttyprintk.o obj-y += misc.o obj-$(CONFIG_VT) += vt_ioctl.o vc_screen.o selection.o keyboard.o obj-$(CONFIG_BFIN_JTAG_COMM) += bfin_jtag_comm.o diff --git a_linux/drivers/char/ttyprintk.c b_linux/drivers/char/ttyprintk.c new file mode 100644 index 000..344f2d3 --- /dev/null +++ b_linux/drivers/char/ttyprintk.c @@ -0,0 +1,264 @@ +/* + * linux/drivers/char/ttyprintk.c + * + * Copyright (C) 2010 Samo Pogacnik + * + * This program is free software; you can redistribute it and/or modify + * it under the smems of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + */ + +/* + * This pseudo device allows user to make printk messages. It is possible + * to store "console" messages inline with kernel messages for better analyses + * of the boot process, for example. + */ + +#include +#include +#include +#include +#include + +struct ttyprintk_port { + struct tty_port port; + struct mutex port_write_mutex; +}; + +static struct ttyprintk_port tpk_port; + +/* + * Ratelimiting support to handle to much output to this device, + * because of explicit writes or because of unintentional loop + * setup (caught printks again sent to this device). + */ +static struct ratelimit_state ttyprintk_rs = { + .interval = DEFAULT_RATELIMIT_INTERVAL, + .burst = DEFAULT_RATELIMIT_BURST, +}; + +#define ttyprintk_printk(fmt, ...) \ +{ \ + printk(KERN_INFO fmt, ##__VA_ARGS__); \ +} + +/* + * Our private ratelimit function, to suppress its printk warnings about + * missed callbacks, which are irrelevant in a flow control mechanism. + */ +static int ttyprintk_ratelimit(struct ratelimit_state *rs, + struct ttyprintk_port *tpkp) +{ + int ret; + + /* exclusive call of ttyprintk_ratelimit within this tty */ + mutex_lock(&tpkp->port_write_mutex); + /* clear ratelimit missed callbacks counter */ + rs->missed = 0; + ret = __ratelimit(rs); +
Re: [PATCH] detour TTY driver - now ttyprintk
> For correct flow control, i suppose current empty space of the real > (final) printk buffer is needed. On the other hand my intermediate Console drivers have their own buffering so that doesn't really work. If you want to just avoid explosions then you don't need to be quite so clever > in some logical manner. And the other would be to use ratelimit support > to switch between max and zero in write_room answer and remove other > retelimit response? Yes - except that a driver isn't permitted to reduce the write room space by more than bytes written. That is if you offer 512 bytes you can't offer 0 until 512 bytes have been written - hence the design of the pseudo code I posted in the previous message. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
On 21.06.2010 (Mon) at 15:38 +0100 Alan Cox wrote: > > I'm thinking to leave the ratelimit support in for the time being. I had > > in mind cases, when someone does > > "cat /proc/kmsg > dev/ttyprintk" or > > suppose the console is redirected to ttyprintk (which i would like to be > > able to do from user program) > > Console as in the printk sense would then loop. > > If you are going to do the flow control you should probably do something > like > > > write_room() > { > if (!flow_controlled) > space = 8192; > return space; > } > > write() > { > space -= len; > } > > then your flow control will behave properly and slow down users rather > than losing data (except stuff sent without blocking) > For correct flow control, i suppose current empty space of the real (final) printk buffer is needed. On the other hand my intermediate pre-formatting buffer is only "one line" long, but serialized on access in a way that it is always completely available (except for the time of tpk_printk() function running). As such intermediate buffer only defines maximum write_room space. Now there are two ideas. The first one is to dig out current real printk buffer space (smells like hacking?) and adapt write_room to that space in some logical manner. And the other would be to use ratelimit support to switch between max and zero in write_room answer and remove other retelimit response? What do you suggest, do i miss something? regards, Samo -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
> I'm thinking to leave the ratelimit support in for the time being. I had > in mind cases, when someone does > "cat /proc/kmsg > dev/ttyprintk" or > suppose the console is redirected to ttyprintk (which i would like to be > able to do from user program) Console as in the printk sense would then loop. If you are going to do the flow control you should probably do something like write_room() { if (!flow_controlled) space = 8192; return space; } write() { space -= len; } then your flow control will behave properly and slow down users rather than losing data (except stuff sent without blocking) -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
> > +/* > > + * TTY operations open function. > > + */ > > +static int tpk_open(struct tty_struct *tty, struct file *filp) > > +{ > > + struct ttyprintk_port *port = &tpk_port; > > You can replace the rest with > > return tty_port_open(port, tty, filp); > } > fixed > > + * TTY operations close function. > > + */ > > +static void tpk_close(struct tty_struct *tty, struct file *filp) > > +{ > > + struct ttyprintk_port *port = tty->driver_data; > > and > tty_port_close(port, tty, filp); > > > +} > > which saves a lot of work > yeah right, done > > + > > +/* > > + * TTY operations write function. > > + */ > > +int tpk_write(struct tty_struct *tty, > > + const unsigned char *buf, int count) > > +{ > > + struct ttyprintk_port *port; > > + int ret; > > + > > + port = tty->driver_data; > > + > > + if (!port) > > + return 0; > > + > > + if (!(port->port.flags & ASYNC_INITIALIZED)) > > + return 0; > > These two can't happen if you use tty_port_* so it is better to blow up. > If you think you may be seeing it occur then use WARN_ON() or similar > the two checks were removed > > + > > + /* exclusive use of tpk_printk within this tty */ > > + mutex_lock(&port->port_write_mutex); > > + ret = tpk_printk(buf, count); > > + mutex_unlock(&port->port_write_mutex); > > And this is serialized by the caller (not that having your own lock is > any harm) > own lock peserved just in case > > > +#defineTPKRLEV (('e'<<8) | 0) /* Wait for ttyprintk ratelimiting > > event*/ > > +static int tpk_ioctl(struct tty_struct *tty, struct file *file, > > + unsigned int cmd, unsigned long arg) > > +{ > > + struct ttyprintk_port *port; > > + > > + port = tty->driver_data; > > + > > + if (!port) > > + return -EINVAL; > > + > > + switch (cmd) { > > + case TPKRLEV: > > + wait_event_interruptible(ttyprintk_ratelimit_wq, > > + (ttyprintk_ratelimit_event != 0)); > > Ok that wasn't quite what I had in mind. ratelimiting remained present > > What I was thinking was needed was this > > /* Stop TIOCCONS */ > case TIOCCONS: > return -EOPNOTSUPP; > added > only it won't work that way. I'll sort that out in tty_io.c once the > driver is happy. That way anything trying to mis-redirect the console > will get stopped early which is probably more reliable than a ratelimit ? > > > + memset(&tpk_port, 0, sizeof(tpk_port)); > memset removed > It's static so that isn't needed > > > + tty_port_init(&tpk_port.port); > > + spin_lock_init(&tpk_port.lock); > > The one other bit you will need to use the helpers is > > struct tty_port_operations null_ops = { }; > > tpk_port.port->ops = &null_ops; > > Alan Also added, with many thanks, Samo Signed-off-by: Samo Pogacnik diff --git a_linux/Documentation/devices.txt b_linux/Documentation/devices.txt index 53d64d3..71aef33 100644 --- a_linux/Documentation/devices.txt +++ b_linux/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/ttyprintkUser messages via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 diff --git a_linux/drivers/char/Kconfig b_linux/drivers/char/Kconfig index 3141dd3..5c38a06 100644 --- a_linux/drivers/char/Kconfig +++ b_linux/drivers/char/Kconfig @@ -485,6 +485,20 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. +config TTY_PRINTK + bool "TTY driver to output user messages via printk" + default n + ---help--- + If you say Y here, the support for writing user messages (i.e. + console messages) via printk is available. + + The feature is useful to inline user messages with kernel + messages. + In order to use this feature, you should output user messages + to /dev/ttyprintk or redirect console to this TTY. + + If unsure, say N. + config BRIQ_PANEL tristate 'Total Impact briQ front panel driver' depends on PPC_CHRP diff --git a_linux/drivers/char/Makefile b_linux/drivers/char/Makefile index f957edf..ed60f45 100644 --- a_linux/drivers/char/Makefile +++ b_linux/drivers/char/Makefile @@ -11,6 +11,7 @@ obj-y += mem.o random.o tty_io.o n_tty.o tty_ioctl.o tty_ldisc.o tty_buffer.o t obj-$(CONFIG_LEGACY_PTYS) += pty.o obj-$(CONFIG_UNIX98_PTYS) += pty.o +obj-$(CONFIG_TTY_PRINTK) += ttyprintk.o obj-y += misc.o obj-$(CONFIG_VT) += vt_ioctl.o vc_screen.o selection.o keyboard.o obj-$(CONFIG_BFIN_JTAG_C
Re: [PATCH] detour TTY driver - now ttyprintk
> > +#defineTPKRLEV (('e'<<8) | 0) /* Wait for ttyprintk ratelimiting > > event*/ > > +static int tpk_ioctl(struct tty_struct *tty, struct file *file, > > + unsigned int cmd, unsigned long arg) > > +{ > > + struct ttyprintk_port *port; > > + > > + port = tty->driver_data; > > + > > + if (!port) > > + return -EINVAL; > > + > > + switch (cmd) { > > + case TPKRLEV: > > + wait_event_interruptible(ttyprintk_ratelimit_wq, > > + (ttyprintk_ratelimit_event != 0)); > > Ok that wasn't quite what I had in mind. > > What I was thinking was needed was this > > /* Stop TIOCCONS */ > case TIOCCONS: > return -EOPNOTSUPP; > > only it won't work that way. I'll sort that out in tty_io.c once the > driver is happy. That way anything trying to mis-redirect the console > will get stopped early which is probably more reliable than a ratelimit ? > I'm thinking to leave the ratelimit support in for the time being. I had in mind cases, when someone does "cat /proc/kmsg > dev/ttyprintk" or suppose the console is redirected to ttyprintk (which i would like to be able to do from user program) and then someone does: "cat /proc/kmsg > /dev/console"... or if console is redirected after this command ? Were you thinking of some other mis-redirection case? Samo -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
> +/* > + * TTY operations open function. > + */ > +static int tpk_open(struct tty_struct *tty, struct file *filp) > +{ > + struct ttyprintk_port *port = &tpk_port; You can replace the rest with return tty_port_open(port, tty, filp); } > + * TTY operations close function. > + */ > +static void tpk_close(struct tty_struct *tty, struct file *filp) > +{ > + struct ttyprintk_port *port = tty->driver_data; and tty_port_close(port, tty, filp); > +} which saves a lot of work > + > +/* > + * TTY operations write function. > + */ > +int tpk_write(struct tty_struct *tty, > + const unsigned char *buf, int count) > +{ > + struct ttyprintk_port *port; > + int ret; > + > + port = tty->driver_data; > + > + if (!port) > + return 0; > + > + if (!(port->port.flags & ASYNC_INITIALIZED)) > + return 0; These two can't happen if you use tty_port_* so it is better to blow up. If you think you may be seeing it occur then use WARN_ON() or similar > + > + /* exclusive use of tpk_printk within this tty */ > + mutex_lock(&port->port_write_mutex); > + ret = tpk_printk(buf, count); > + mutex_unlock(&port->port_write_mutex); And this is serialized by the caller (not that having your own lock is any harm) > +#define TPKRLEV (('e'<<8) | 0) /* Wait for ttyprintk ratelimiting > event*/ > +static int tpk_ioctl(struct tty_struct *tty, struct file *file, > + unsigned int cmd, unsigned long arg) > +{ > + struct ttyprintk_port *port; > + > + port = tty->driver_data; > + > + if (!port) > + return -EINVAL; > + > + switch (cmd) { > + case TPKRLEV: > + wait_event_interruptible(ttyprintk_ratelimit_wq, > + (ttyprintk_ratelimit_event != 0)); Ok that wasn't quite what I had in mind. What I was thinking was needed was this /* Stop TIOCCONS */ case TIOCCONS: return -EOPNOTSUPP; only it won't work that way. I'll sort that out in tty_io.c once the driver is happy. That way anything trying to mis-redirect the console will get stopped early which is probably more reliable than a ratelimit ? > + memset(&tpk_port, 0, sizeof(tpk_port)); It's static so that isn't needed > + tty_port_init(&tpk_port.port); > + spin_lock_init(&tpk_port.lock); The one other bit you will need to use the helpers is struct tty_port_operations null_ops = { }; tpk_port.port->ops = &null_ops; Alan -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] detour TTY driver - now ttyprintk
Hi, This is another version of former detour TTY driver, trying to follow Alan's suggestions: - renamed from detour to ttyprintk - removed possibility for initial internal redirection of console to this tty - providing hopefully more proper open/close tty operations - fixed initial termios settings - added primitive write_room operation - added ratelimting support (recursion check) and an ioctl trap to catch ratelimiting being activated. i'd appreciate a suggestion on this ioctl command naming/value and on location of its definition? - additional error checking I also have a question about the tioccons() function from the tty_io.c. Should this function also check, if the redirection tty has been opened for writing, since there are going to be implicit writes to this tty for each console message? This would prevent users without write permissions to successfully perform TIOCCONS ioctl. This would also prevent writing capable users to successfully perform TIOCCONS with read-only opened tty, but failing to write console messages to the redirection tty afterwards. This seems to happen because the mode of opened tty at the time of issuing TIOCCONS ioctl is remembered. Alan, could you please give the patch bellow another look? thanks, Samo --- Signed-off-by: Samo Pogacnik diff --git a_linux/Documentation/devices.txt b_linux/Documentation/devices.txt index 53d64d3..71aef33 100644 --- a_linux/Documentation/devices.txt +++ b_linux/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/ttyprintkUser messages via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 diff --git a_linux/drivers/char/Kconfig b_linux/drivers/char/Kconfig index 3141dd3..5c38a06 100644 --- a_linux/drivers/char/Kconfig +++ b_linux/drivers/char/Kconfig @@ -485,6 +485,20 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. +config TTY_PRINTK + bool "TTY driver to output user messages via printk" + default n + ---help--- + If you say Y here, the support for writing user messages (i.e. + console messages) via printk is available. + + The feature is useful to inline user messages with kernel + messages. + In order to use this feature, you should output user messages + to /dev/ttyprintk or redirect console to this TTY. + + If unsure, say N. + config BRIQ_PANEL tristate 'Total Impact briQ front panel driver' depends on PPC_CHRP diff --git a_linux/drivers/char/Makefile b_linux/drivers/char/Makefile index f957edf..ed60f45 100644 --- a_linux/drivers/char/Makefile +++ b_linux/drivers/char/Makefile @@ -11,6 +11,7 @@ obj-y += mem.o random.o tty_io.o n_tty.o tty_ioctl.o tty_ldisc.o tty_buffer.o t obj-$(CONFIG_LEGACY_PTYS) += pty.o obj-$(CONFIG_UNIX98_PTYS) += pty.o +obj-$(CONFIG_TTY_PRINTK) += ttyprintk.o obj-y += misc.o obj-$(CONFIG_VT) += vt_ioctl.o vc_screen.o selection.o keyboard.o obj-$(CONFIG_BFIN_JTAG_COMM) += bfin_jtag_comm.o diff --git a_linux/drivers/char/ttyprintk.c b_linux/drivers/char/ttyprintk.c new file mode 100644 index 000..5e569e4 --- /dev/null +++ b_linux/drivers/char/ttyprintk.c @@ -0,0 +1,305 @@ +/* + * linux/drivers/char/ttyprintk.c + * + * Copyright (C) 2010 Samo Pogacnik + * + * This program is free software; you can redistribute it and/or modify + * it under the smems of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + */ + +/* + * This pseudo device allows user to make printk messages. It is possible + * to store "console" messages inline with kernel messages for better analyses + * of the boot process, for example. + */ + +#include +#include +#include +#include +#include + +/* + * Ratelimiting support to handle to much output to this device, + * because of explicit writes or because of unintentional recursive + * setup (caught printks again sent to this device). + */ +static struct ratelimit_state ttyprintk_rs = { + .interval = DEFAULT_RATELIMIT_INTERVAL, + .burst = DEFAULT_RATELIMIT_BURST, +}; + +/* + * Ratelimiting action and notification support + */ +static DECLARE_WAIT_QUEUE_HEAD(ttyprintk_ratelimit_wq); +static int ttyprintk_ratelimit_event; + +#define ttyprintk_ratelimited(fmt, ...) \ +{ \ + if (__ratelimit(&ttyprintk_rs)) { \ + ttyprintk_ratelimit_event = 0; \ + printk(KERN_INFO fmt, ##__VA_ARGS__); \ + } else { \ + ttyprintk_ratelimit_event = 1; \ + wake_up_al