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
2010/8/25 Greg KH gre...@suse.de: 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 01:12, Greg KH gre...@suse.de 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
On Wed, Aug 25, 2010 at 09:40, Kay Sievers kay.siev...@vrfy.org wrote: On Wed, Aug 25, 2010 at 01:12, Greg KH gre...@suse.de 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 21 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
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
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 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
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 samo_pogac...@t-2.net
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 linux/device.h
+#include linux/serial.h
+#include linux/tty.h
+
+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]) {
+
Re: [PATCH] detour TTY driver - now ttyprintk
On Wed, 25 Aug 2010 11:16:47 -0700 Greg KH gre...@suse.de 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.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 samo_pogac...@t-2.net
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 linux/device.h
+#include linux/serial.h
+#include linux/tty.h
+
+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
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
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: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
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
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
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
+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 samo_pogac...@t-2.net
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 linux/sched.h
+#include linux/delay.h
+#include linux/ratelimit.h
+#include linux/device.h
+#include linux/serial.h
+#include linux/tty.h
+
+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 */
+
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 samo_pogac...@t-2.net
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 linux/sched.h
+#include linux/ratelimit.h
+#include linux/device.h
+#include linux/serial.h
+#include linux/tty.h
+
+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
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
+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
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
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
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
