* Re: [PATCH] detour TTY driver - now ttyprintk
From: Samo Pogacnik @ 2010-08-24 22:50 UTC (permalink / raw)
To: Greg KH; +Cc: linux kernel, linux-embedded, Alan Cox
In-Reply-To: <20100824222035.GA10625@suse.de>
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
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Greg KH @ 2010-08-24 22:20 UTC (permalink / raw)
To: Samo Pogacnik; +Cc: linux kernel, linux-embedded, Alan Cox
In-Reply-To: <1282687797.8020.108.camel@itpsd6lap>
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
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Alan Cox @ 2010-08-24 22:16 UTC (permalink / raw)
To: Greg KH; +Cc: Samo Pogacnik, linux kernel, linux-embedded
In-Reply-To: <20100824211016.GA7176@suse.de>
> 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
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Samo Pogacnik @ 2010-08-24 22:09 UTC (permalink / raw)
To: Greg KH; +Cc: linux kernel, linux-embedded, Alan Cox
In-Reply-To: <20100824211016.GA7176@suse.de>
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
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Greg KH @ 2010-08-24 22:02 UTC (permalink / raw)
To: Alan Cox; +Cc: Samo Pogacnik, linux kernel, linux-embedded
In-Reply-To: <20100824231641.33d5679b@lxorguk.ukuu.org.uk>
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
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Greg KH @ 2010-08-24 21:10 UTC (permalink / raw)
To: Samo Pogacnik; +Cc: linux kernel, linux-embedded, Alan Cox
In-Reply-To: <1282683470.8020.66.camel@itpsd6lap>
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
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Samo Pogacnik @ 2010-08-24 20:57 UTC (permalink / raw)
To: linux kernel; +Cc: linux-embedded, Alan Cox, Greg Kroah-Hartman
In-Reply-To: <20100625120329.1303aa61@lxorguk.ukuu.org.uk>
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_pogacnik@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/ttyprintk User 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 0000000..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]) {
+ case '\r':
+ /* replace cr with nl */
+ tmp[tpk_curr + 0] = '\n';
+ tmp[tpk_curr + 1] = '\0';
+ printk(KERN_INFO "%s%s", tpk_tag, tmp);
+ tpk_curr = 0;
+ if (buf[i + 1] == '\n')
+ i++;
+ break;
+ case '\n':
+ tmp[tpk_curr + 1] = '\0';
+ printk(KERN_INFO "%s%s", tpk_tag, tmp);
+ tpk_curr = 0;
+ break;
+ default:
+ tpk_curr++;
+ }
+ } else {
+ /* end of tmp buffer reached: cut the message in two */
+ tmp[tpk_curr + 1] = '\\';
+ tmp[tpk_curr + 2] = '\n';
+ tmp[tpk_curr + 3] = '\0';
+ printk(KERN_INFO "%s%s", tpk_tag, tmp);
+ tpk_curr = 0;
+ }
+ }
+
+ return count;
+}
+
+/*
+ * TTY operations open function.
+ */
+static int tpk_open(struct tty_struct *tty, struct file *filp)
+{
+ tty->driver_data = &tpk_port;
+
+ return tty_port_open(&tpk_port.port, tty, filp);
+}
+
+/*
+ * TTY operations close function.
+ */
+static void tpk_close(struct tty_struct *tty, struct file *filp)
+{
+ struct ttyprintk_port *tpkp = tty->driver_data;
+
+ mutex_lock(&tpkp->port_write_mutex);
+ /* flush tpk_printk buffer */
+ tpk_printk(NULL, 0);
+ mutex_unlock(&tpkp->port_write_mutex);
+
+ tty_port_close(&tpkp->port, tty, filp);
+}
+
+/*
+ * TTY operations write function.
+ */
+static int tpk_write(struct tty_struct *tty,
+ const unsigned char *buf, int count)
+{
+ struct ttyprintk_port *tpkp = tty->driver_data;
+ int ret;
+
+
+ /* exclusive use of tpk_printk within this tty */
+ mutex_lock(&tpkp->port_write_mutex);
+ ret = tpk_printk(buf, count);
+ mutex_unlock(&tpkp->port_write_mutex);
+
+ return ret;
+}
+
+/*
+ * TTY operations write_room function.
+ */
+static int tpk_write_room(struct tty_struct *tty)
+{
+ return TPK_MAX_ROOM;
+}
+
+/*
+ * TTY operations ioctl function.
+ */
+static int tpk_ioctl(struct tty_struct *tty, struct file *file,
+ unsigned int cmd, unsigned long arg)
+{
+ struct ttyprintk_port *tpkp = tty->driver_data;
+
+ if (!tpkp)
+ return -EINVAL;
+
+ switch (cmd) {
+ /* Stop TIOCCONS */
+ case TIOCCONS:
+ return -EOPNOTSUPP;
+ default:
+ return -ENOIOCTLCMD;
+ }
+ return 0;
+}
+
+static const struct tty_operations ttyprintk_ops = {
+ .open = tpk_open,
+ .close = tpk_close,
+ .write = tpk_write,
+ .write_room = tpk_write_room,
+ .ioctl = tpk_ioctl,
+};
+
+struct tty_port_operations null_ops = { };
+
+static struct tty_driver *ttyprintk_driver;
+
+static int __init ttyprintk_init(void)
+{
+ int ret = -ENOMEM;
+ void *rp;
+
+ ttyprintk_driver = alloc_tty_driver(1);
+ if (!ttyprintk_driver)
+ return ret;
+
+ ttyprintk_driver->owner = THIS_MODULE;
+ ttyprintk_driver->driver_name = "ttyprintk";
+ ttyprintk_driver->name = "ttyprintk";
+ ttyprintk_driver->major = TTYAUX_MAJOR;
+ ttyprintk_driver->minor_start = 3;
+ ttyprintk_driver->num = 1;
+ ttyprintk_driver->type = TTY_DRIVER_TYPE_CONSOLE;
+ ttyprintk_driver->init_termios = tty_std_termios;
+ ttyprintk_driver->init_termios.c_oflag = OPOST | OCRNL | ONOCR | ONLRET;
+ ttyprintk_driver->flags = TTY_DRIVER_RESET_TERMIOS |
+ TTY_DRIVER_REAL_RAW | TTY_DRIVER_DYNAMIC_DEV;
+ tty_set_operations(ttyprintk_driver, &ttyprintk_ops);
+
+ ret = tty_register_driver(ttyprintk_driver);
+ if (ret < 0) {
+ printk(KERN_ERR "Couldn't register ttyprintk driver\n");
+ goto error;
+ }
+
+ /* create our unnumbered device */
+ rp = device_create(tty_class, NULL, MKDEV(TTYAUX_MAJOR, 3), NULL,
+ ttyprintk_driver->name);
+ if (IS_ERR(rp)) {
+ printk(KERN_ERR "Couldn't create ttyprintk device\n");
+ ret = PTR_ERR(rp);
+ goto error;
+ }
+
+ tty_port_init(&tpk_port.port);
+ tpk_port.port.ops = &null_ops;
+ mutex_init(&tpk_port.port_write_mutex);
+
+ return 0;
+
+error:
+ put_tty_driver(ttyprintk_driver);
+ ttyprintk_driver = NULL;
+ return ret;
+}
+module_init(ttyprintk_init);
^ permalink raw reply related
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Greg KH @ 2010-08-24 20:13 UTC (permalink / raw)
To: Samo Pogacnik; +Cc: linux kernel, linux-embedded, Alan Cox
In-Reply-To: <1282680194.8020.46.camel@itpsd6lap>
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 <samo_pogacnik@t-2.net>
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
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Samo Pogacnik @ 2010-08-24 20:03 UTC (permalink / raw)
To: linux kernel; +Cc: linux-embedded, Alan Cox, Greg Kroah-Hartman
In-Reply-To: <20100625120329.1303aa61@lxorguk.ukuu.org.uk>
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 <samo_pogacnik@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/ttyprintk User 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 0000000..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]) {
+ case '\r':
+ /* replace cr with nl */
+ tmp[tpk_curr + 0] = '\n';
+ tmp[tpk_curr + 1] = '\0';
+ printk(KERN_INFO "%s%s", tpk_tag, tmp);
+ tpk_curr = 0;
+ if (buf[i + 1] == '\n')
+ i++;
+ break;
+ case '\n':
+ tmp[tpk_curr + 1] = '\0';
+ printk(KERN_INFO "%s%s", tpk_tag, tmp);
+ tpk_curr = 0;
+ break;
+ default:
+ tpk_curr++;
+ }
+ } else {
+ /* end of tmp buffer reached: cut the message in two */
+ tmp[tpk_curr + 1] = '\\';
+ tmp[tpk_curr + 2] = '\n';
+ tmp[tpk_curr + 3] = '\0';
+ printk(KERN_INFO "%s%s", tpk_tag, tmp);
+ tpk_curr = 0;
+ }
+ }
+
+ return count;
+}
+
+/*
+ * TTY operations open function.
+ */
+static int tpk_open(struct tty_struct *tty, struct file *filp)
+{
+ tty->driver_data = &tpk_port;
+
+ return tty_port_open(&tpk_port.port, tty, filp);
+}
+
+/*
+ * TTY operations close function.
+ */
+static void tpk_close(struct tty_struct *tty, struct file *filp)
+{
+ struct ttyprintk_port *tpkp = tty->driver_data;
+
+ mutex_lock(&tpkp->port_write_mutex);
+ /* flush tpk_printk buffer */
+ tpk_printk(NULL, 0);
+ mutex_unlock(&tpkp->port_write_mutex);
+
+ tty_port_close(&tpkp->port, tty, filp);
+}
+
+/*
+ * TTY operations write function.
+ */
+static int tpk_write(struct tty_struct *tty,
+ const unsigned char *buf, int count)
+{
+ struct ttyprintk_port *tpkp = tty->driver_data;
+ int ret;
+
+
+ /* exclusive use of tpk_printk within this tty */
+ mutex_lock(&tpkp->port_write_mutex);
+ ret = tpk_printk(buf, count);
+ mutex_unlock(&tpkp->port_write_mutex);
+
+ return ret;
+}
+
+/*
+ * TTY operations write_room function.
+ */
+static int tpk_write_room(struct tty_struct *tty)
+{
+ return TPK_MAX_ROOM;
+}
+
+/*
+ * TTY operations ioctl function.
+ */
+static int tpk_ioctl(struct tty_struct *tty, struct file *file,
+ unsigned int cmd, unsigned long arg)
+{
+ struct ttyprintk_port *tpkp = tty->driver_data;
+
+ if (!tpkp)
+ return -EINVAL;
+
+ switch (cmd) {
+ /* Stop TIOCCONS */
+ case TIOCCONS:
+ return -EOPNOTSUPP;
+ default:
+ return -ENOIOCTLCMD;
+ }
+ return 0;
+}
+
+static const struct tty_operations ttyprintk_ops = {
+ .open = tpk_open,
+ .close = tpk_close,
+ .write = tpk_write,
+ .write_room = tpk_write_room,
+ .ioctl = tpk_ioctl,
+};
+
+struct tty_port_operations null_ops = { };
+
+static struct tty_driver *ttyprintk_driver;
+
+static int __init ttyprintk_init(void)
+{
+ int ret = -ENOMEM;
+ void *rp;
+
+ ttyprintk_driver = alloc_tty_driver(1);
+ if (!ttyprintk_driver)
+ return ret;
+
+ ttyprintk_driver->owner = THIS_MODULE;
+ ttyprintk_driver->driver_name = "ttyprintk";
+ ttyprintk_driver->name = "ttyprintk";
+ ttyprintk_driver->major = TTYAUX_MAJOR;
+ ttyprintk_driver->minor_start = 3;
+ ttyprintk_driver->num = 1;
+ ttyprintk_driver->type = TTY_DRIVER_TYPE_CONSOLE;
+ ttyprintk_driver->init_termios = tty_std_termios;
+ ttyprintk_driver->init_termios.c_oflag = OPOST | OCRNL | ONOCR | ONLRET;
+ ttyprintk_driver->flags = TTY_DRIVER_RESET_TERMIOS |
+ TTY_DRIVER_REAL_RAW | TTY_DRIVER_DYNAMIC_DEV;
+ tty_set_operations(ttyprintk_driver, &ttyprintk_ops);
+
+ ret = tty_register_driver(ttyprintk_driver);
+ if (ret < 0) {
+ printk(KERN_ERR "Couldn't register ttyprintk driver\n");
+ goto error;
+ }
+
+ /* create our unnumbered device */
+ rp = device_create(tty_class, NULL, MKDEV(TTYAUX_MAJOR, 3), NULL,
+ ttyprintk_driver->name);
+ if (IS_ERR(rp)) {
+ printk(KERN_ERR "Couldn't create ttyprintk device\n");
+ ret = PTR_ERR(rp);
+ goto error;
+ }
+
+ tty_port_init(&tpk_port.port);
+ tpk_port.port.ops = &null_ops;
+ mutex_init(&tpk_port.port_write_mutex);
+
+ return 0;
+
+error:
+ put_tty_driver(ttyprintk_driver);
+ ttyprintk_driver = NULL;
+ return ret;
+}
+module_init(ttyprintk_init);
^ permalink raw reply related
* Re: [PATCH] RFC: AMBA bus discardable probe() function
From: Dmitry Torokhov @ 2010-08-05 6:43 UTC (permalink / raw)
To: Linus WALLEIJ
Cc: Greg KH, linux-kernel@vger.kernel.org, David Brownell,
Russell King, linux-embedded@vger.kernel.org, Viresh KUMAR
In-Reply-To: <CEE6BB42CAD6E947908279175AF8470A0262E58F8B@EXDCVYMBSTM006.EQ1STM.local>
On Wednesday, August 04, 2010 11:26:00 pm Linus WALLEIJ wrote:
> [Greg]
>
> > [Me]
> >
> > > + spin_lock(&amba_bustype.p->klist_drivers.k_lock);
> >
> > Ick, nope, you can't do this, sorry. That's a "private" structure for
> > a reason.
>
> Yeah I get it, but in the platform bus case what's that traversal of
> the klists actually for? I didn't get it, and was guessing that it
> was considering the case where devices spawn new devices.
It is to check if the driver actually bound to any devices and fail driver
registration if it did not - then, in case of modular build, entire driver
module might get unloaded from memory as well.
--
Dmitry
^ permalink raw reply
* RE: [PATCH] RFC: AMBA bus discardable probe() function
From: Linus WALLEIJ @ 2010-08-05 6:26 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel@vger.kernel.org, David Brownell, Dmitry Torokhov,
Russell King, linux-embedded@vger.kernel.org, Viresh KUMAR
In-Reply-To: <20100804194319.GA30722@suse.de>
[Greg]
> [Me]
> > + spin_lock(&amba_bustype.p->klist_drivers.k_lock);
>
> Ick, nope, you can't do this, sorry. That's a "private" structure for
> a reason.
Yeah I get it, but in the platform bus case what's that traversal of
the klists actually for? I didn't get it, and was guessing that it
was considering the case where devices spawn new devices.
> So what's the real driving force here, just saving a few hundred bytes
> after booting? Or something else?
A few thousand actually according to Russells measurements.
And no I don't think it's worth it unless someone else challenge this...
Yours,
Linus Walleij
^ permalink raw reply
* RE: [PATCH] RFC: AMBA bus discardable probe() function
From: Linus WALLEIJ @ 2010-08-05 6:22 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman, David Brownell,
Dmitry Torokhov, linux-embedded@vger.kernel.org, Viresh KUMAR
In-Reply-To: <20100804222410.GB12502@n2100.arm.linux.org.uk>
[Russell]
> which gives a total of 5188 bytes for all the above probe functions.
> However, in order to free this, we're adding 184 bytes of code and
> literal pool to achieve this:
> (...)
> The overall kernel size is 3877020 bytes, which means we're potentially
> allowing for 0.13% of the kernel to be freed at run time - which may
> equate to one or at most two additional pages.
We have the PL022 as well, and the PL08x is being added but it will
likely stay in that ballpark figure.
But overall that does not seem to be worth it, so let's drop it
for the time being. CC:ing the linux-embedded folks that
often worry about footprint size to see if someone oppose. Also
CC Viresh who works on a platform for e.g. set-top boxes using
these PrimeCells which I think may be memory-constrained.
Yours,
Linus Walleij
^ permalink raw reply
* Re: Where to post an embedded-centric filesystem driver?
From: David Woodhouse @ 2010-08-04 12:18 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded
In-Reply-To: <AANLkTi=oBoVKW4QrtjCYfsM7bd+W-9RPgExGe=iQwvQt@mail.gmail.com>
On Wed, 2010-08-04 at 07:16 -0500, Bill Gatliff wrote:
>
>
> I just finished a filesystem driver that provides Linux the ability to
> do a read-only mount of Micromonitor's TFS filesystem. Micromonitor
> is a great little bootloader that I use on all my boards. A
> read-write filesystem driver for Linux is in the works.
>
> Nobody outside of the embedded world will ever hear of
> Micromonitor/TFS. So I'm not quite sure where to post my patches.
> Suggestions?
linux-fsdevel@vger.kernel.org
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Where to post an embedded-centric filesystem driver?
From: Bill Gatliff @ 2010-08-04 12:16 UTC (permalink / raw)
To: linux-embedded
Guys:
I just finished a filesystem driver that provides Linux the ability to
do a read-only mount of Micromonitor's TFS filesystem. Micromonitor
is a great little bootloader that I use on all my boards. A
read-write filesystem driver for Linux is in the works.
Nobody outside of the embedded world will ever hear of
Micromonitor/TFS. So I'm not quite sure where to post my patches.
Suggestions?
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Planning on updating the PWM patches soon...
From: Bill Gatliff @ 2010-08-02 23:06 UTC (permalink / raw)
To: linux-embedded
Guys:
I have some time this week to finally update my PWM API patches. Some
of you have emailed me privately, saying that you have adapted your
own hardware to use the API. If you would like your code to be
proffered as part of the initial patch set, please email me and let me
know!
I should have a git tree set up with my latest stuff in a few hours.
Once we have that how we want it, I'll send patches to this mailing
list. Thanks to everyone who has helped me with this code, the
response has been very gratifying. Sorry it has taken me so long to
get back to this.
Kindest regards,
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Cfp - Languages, Compilers, Tools and Theory,for Embedded Systems
From: Tomas Kalibera @ 2010-07-29 17:59 UTC (permalink / raw)
To: linux-embedded
*********************************************************
LCTES 2011 - FIRST CALL FOR PAPERS
ACM SIGPLAN/SIGBED Conference on
Languages, Compilers, Tools,
and Theory for Embedded Systems
(In conjunction with CPS Week 2011)
Chicago, Illinois, USA, April 12-14 2011
http://lctes2011.elis.ugent.be
*********************************************************
Deadline: 8 October 2010.
Embedded system design faces many challenges both with respect to functional
requirements and non-functional requirements, many of which are
conflicting. They are found in areas such as design and developer
productivity,
verification, validation, maintainability, and meeting performance goals and
resource constraints. Novel design-time and run-time approaches are
needed to
meet the demand of emerging applications and to exploit new hardware
paradigms,
and in particular to scale up to multicores and distributed systems
built from
multicores. LCTES 2011 solicits papers presenting original work on
programming
languages, compilers, tools, theory and architectures that help in
overcoming
these challenges. Research papers on innovative techniques are welcome,
as well
as experience papers on insights obtained by experimenting with real-world
systems and applications.
Papers are solicited on, but not limited to, the following topics in
embedded
and cyber-physical systems:
* Programming language challenges, including:
Domain-specific languages
Features to exploit multicore, reconfigurable, and other emerging
architectures
Features for distributed, adaptive, and real-time control embedded
systems
Language capabilities for specification, composition, and
construction of embedded systems
Language features and techniques to enhance reliability,
verifiability, and security
Virtual machines, concurrency, inter-processor synchronization, and
memory management
* Compiler challenges, including:
Interaction between embedded/cyber-physical architectures,
operating systems, and compilers
Interpreters, binary translation, just-in-time compilation, and
split compilation
Support for enhanced programmer productivity
Support for enhanced debugging, profiling, and exception/interrupt
handling
Optimization for low power/energy, code and data size, and
best-effort and real-time performance
Parametrized and structural compiler design space exploration and
autotuning
* Tools for analysis, specification, design, and implementation, including:
Hardware, system software, and application software, and their
interfaces
Distributed real-time control, media players, and reconfigurable
architectures
System integration and testing
Performance estimation, monitoring, and tuning
Run-time system support for embedded and cyber-physical systems
Design space exploration tools
Support for system security and system-level reliability
Approaches for cross-layer system optimization
* Theory and foundations of embedded and cyber-physical systems, including:
Predictability of resource behavior: energy, space, time
Validation and verification, in particular of concurrent and
distributed systems
Formal foundations of model-based design as basis for code
generation, analysis, and verification
Mathematical foundations for embedded systems
Models of computations for embedded applications
* Novel embedded and cyber-physical architectures, including:
Design and implementation of novel architectures
Workload analysis and performance evaluation
Architecture support for new language features, virtualization,
compiler techniques, and debugging tools
Submission deadline: 8 October 2010. Page limit, format, blind review
and other
Submission guidelines: see http://lctes2011.elis.ugent.be. There will
also be
a call for posters and work-in-progress presentations.
The conference proceedings will be published by the ACM. The authors of
the best
papers of the conference will be invited to submit an extended version to a
special issue on LCTES of ACM Transactions in Embedded Computing
Systems. The
best paper and the best presentation will receive an award.
*********************************************************
PROGRAM COMMITTEE
Abdoulaye Gamatié (CNRS, France)
Alastair Reid (ARM Ltd, United Kingdom)
Albert Cohen (INRIA, France)
Ann Gordon-Ross (University of Florida, USA)
Annie Liu (State University of New York at Stony Brook, USA)
Antony Hosking (Purdue University, USA)
Aviral Shrivastava (Arizona State University, USA)
Daniel Kästner (Absint, Germany)
David F. Bacon (IBM T.J. Watson Research Center, USA)
Florence Maraninchi (VERIMAG, France)
Frank Mueller (North Carolina State University, USA)
Jack Davidson (University of Virginia, USA)
Jaejin Lee (Seoul National University, Korea)
Jan Reineke (UC Berkeley, USA)
John Regher (University of Utah, USA)
Laura Pozzi (University of Lugano, Switzerland)
Peter Marwedel (Technische Universität Dortmund, Germany)
Philip Koopman (Carnegie Mellon University, USA)
Praveen Raghavan (IMEC, Belgium)
Rajeev Barua (University of Maryland, USA)
Rodric Rabbah (IBM T.J. Watson Research Center, USA)
Shangping Ren (Illinois Institute of Technology, USA)
Stephen A. Edwards (Columbia University, USA)
Tulika Mitra (National University of Singapore, Singapore)
Zili Shao (Hong Kong Polytechnic University, Hong Kong)
STEERING COMMITTEE
Bruce Childers (University of Pittsburgh, USA)
Christoph Kirsch (Salzburg University, Austria)
Jaejin Lee (Seoul National University, Korea)
John Regehr (University of Utah, USA)
Koen De Bosschere (Ghent University, Belgium)
Kristian Flautner (ARM Ltd., United Kingdom)
Mahmut Kandemir (Pennsylvania State University, USA)
Mary Jane Irwin (Pennsylvania State University, USA)
Santosh Pande (Georgia Institute of Technology, USA)
Zhiyuan Li (chair, Purdue University, USA)
AT-LARGE MEMBERS
David Whalley (University of Florida, USA)
Annie Liu (State University of New York at Stony Brook, USA)
Frank Mueller (North Carolina State University, USA)
Peter Marwedel (Technische Universität Dortmund, Germany)
Reinhard Wilhelm (Saarland University, Germany)
GENERAL CHAIR
Jan Vitek (Purdue University, USA)
PROGRAM CHAIR
Bjorn De Sutter (Ghent University, Belgium)
PUBLICITY CHAIR
Tomas Kalibera (Charles University, Czech Republic)
WORK-IN-PROGRESS/POSTER CHAIR
Jan Reineke (UC Berkeley, USA)
*********************************************************
^ permalink raw reply
* NFSRoot over PCMCIA with Static Kernel
From: Nilesh Govindarajan @ 2010-07-29 16:47 UTC (permalink / raw)
To: linux-embedded
I have a legacy laptop- 486, 20 MB RAM.
I would like to have it as dumb terminal for some purpose. I have two
PCMCIA network cards available for this purpose, one is Xircom Credit
Card Adapter IIps and 3com 3c589 both of whose drivers are there in
2.4, 2.6
I'm using 2.4 kernel because with 2.6 memory overflows and it freezes
just during kernel decompression.
The kernel command line I pass is: rw root=/dev/nfs
nfsroot=192.168.1.254:/nfsroot ip=dhcp where 192.168.1.254 is my box's
ip address.
IP Autoconfiguration has been enabled.
The problem is, kernel says: "IP-Config: No devices to configure"
You can take a look at the .config file: http://paste.pocoo.org/show/243107/
Any guesses where I'm missing?
For now there's no initrd with it. I believe it is not required if
kernel's IP-Config is able to take either of those cards as ethernet
and send DHCP request on the same. (I insert only one card at a time).
--
Regards,
Nilesh Govindarajan
Facebook: http://www.facebook.com/nilesh.gr
Twitter: http://twitter.com/nileshgr
Website: http://www.itech7.com
VPS Hosting: http://www.itech7.com/a/vps
^ permalink raw reply
* SAM9-L9260: TXD1 is not working on AT91SAM9260
From: Stefan Schoenleitner @ 2010-07-10 7:09 UTC (permalink / raw)
To: linux-embedded
Hi,
I have an Olimex SAM9-L9260 board with an AT91SAM9260 controller on it.
The board is running a sound-2.6 git kernel (2.6.35).
My problem is that for USART1 (which uses the RXD1 and TXD1 pins), the
transmit pin (i.e. TXD1) is not working.
I looked at it with my scope and discovered that it is high all the time
(which is most likely due to the configured pull-up resistor).
Here is what I did to get the UART up and running (just like what I
already did for the DBG UART and UART0):
In my board file (arch/arm/mach-at91/board-sam9-l9260.c) I added the
following line to ek_map_io(), to register USART1 as ttyS2:
-----------------------------------------------------------------------
at91_register_uart(AT91SAM9260_ID_US1, 2, 0);
-----------------------------------------------------------------------
A look at at91sam9260_devices.c reveals that this will lead to a call of
-----------------------------------------------------------------------
configure_usart1_pins(pins);
-----------------------------------------------------------------------
which in turn does the following:
-----------------------------------------------------------------------
at91_set_A_periph(AT91_PIN_PB6, 1); /* TXD1 */
at91_set_A_periph(AT91_PIN_PB7, 0); /* RXD1 */
-----------------------------------------------------------------------
Hence the pins PB6 and PB7 are configured to be UART pins.
I also made sure that there is no other code, that sets the
functionality of those pins to something else (e.g. pin PB6 could also
be used as TCLK1).
Then, when I boot the kernel, I get the following lines, which show that
the UARTs are recognized:
-----------------------------------------------------------------------
atmel_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a ATMEL_SERIAL
atmel_usart.1: ttyS1 at MMIO 0xfffb0000 (irq = 6) is a ATMEL_SERIAL
atmel_usart.2: ttyS2 at MMIO 0xfffb4000 (irq = 7) is a ATMEL_SERIAL
-----------------------------------------------------------------------
While this looks good so far, the odd behavior is that I can correctly
receive data on /dev/ttyS2 (i.e. data is received on the RXD1/PB7 pin),
but I can not send (i.e. *no* data is being transmitted on the TXD1/PB6
pin).
* Is this a bug in the kernel or am I doing something wrong here ?
* Did you experience similar behavior on the at91sam9260 ?
As I already said, I have done this with other UART devices as well
(i.e. USART0) and it worked flawlessly.
cheers,
stefan
^ permalink raw reply
* Re: Embedded topics at Linux Plumbers 2010
From: Grant Likely @ 2010-07-08 16:52 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <AANLkTinaTkyJqHQ3iBknWmJtaLjTRcwJ3G360xQK4FpE@mail.gmail.com>
Update: We've now released the official call for proposals:
http://www.linuxplumbersconf.org/2010
Cheers,
g.
On Tue, Jul 6, 2010 at 1:56 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
>
> Hi all,
>
> I'm on the Linux Plumbers [1] planning committee this year, and I'm
> also heading up the embedded Linux mini-conference. While the
> "official" call for miniconference proposals hasn't actually been
> issued (real soon now, I promise!), the submission form [2] is now
> open, and embedded topic proposals are being accepted. Some initial
> ideas have already been discussed on the plumbers wiki[3], but now we
> need firm proposals to use in planning the miniconference. If there
> is anything embedded related that you'd like to discuss at plumbers,
> then I encourage you to submit a proposal.
>
> [1] http://www.linuxplumbersconf.org/2010
> [2] http://www.linuxplumbersconf.org/2010/ocw/events/LPC2010MC/proposals
> [3] http://wiki.linuxplumbersconf.org/2010:embedded_topics
>
> The miniconferences are working sessions to get developers from
> different projects into the same room. Focus is on discussing and
> solving problems instead of formal presentations. A good proposal
> includes a problem that needs to be solved, some potential solutions
> to discuss, and ideally identify individuals who's participation is
> important.
>
> Deadline for proposal submission is July 19th, so get those proposals
> in soon! If you have a good topic, but are unsure whether or not
> you'll be able to attend, please submit the proposal anyway. The
> miniconference format is flexable so we're able to handle a certain
> amount of uncertainty.
>
> For those who do want to make a formal presentation, we've do also
> have one track dedicated to the purpose. Presentation proposals can
> be submitted here [4]. We also have some slots set aside for BoFs
> [5].
>
> [4] http://www.linuxplumbersconf.org/2010/ocw/events/LPC2010/proposals
> [5] http://www.linuxplumbersconf.org/2010/ocw/events/LPC2010BOFS/proposals
>
> If you have any questions, feel free to email me.
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Updated cs8900a driver available anywhere?
From: Geert Uytterhoeven @ 2010-07-08 8:35 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-net, linux-embedded
In-Reply-To: <AANLkTilJ8JPjjD2M5Q934V8FIIFoBX9e13P32TliFVwT@mail.gmail.com>
On Wed, Jul 7, 2010 at 21:44, Bill Gatliff <bgat@billgatliff.com> wrote:
> I'm in the process of porting Linux over to an ARM-based platform that
> features a CS8900 ethernet controller.
>
> The mainlined drivers/net/cs8x0.c file needs some pretty serious love.
> Before I start hacking on it, does anyone know if there is a
> non-mainlined improvement available anywhere? Like one that supports
> platform devices, for example?
Please note that there are actually two of them: drivers/net/cs89x0.c and
drivers/net/mac89x0.c. The latter seems to be only one third of the size.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Updated cs8900a driver available anywhere?
From: Bill Gatliff @ 2010-07-07 19:44 UTC (permalink / raw)
To: linux-net, linux-embedded
Guys:
I'm in the process of porting Linux over to an ARM-based platform that
features a CS8900 ethernet controller.
The mainlined drivers/net/cs8x0.c file needs some pretty serious love.
Before I start hacking on it, does anyone know if there is a
non-mainlined improvement available anywhere? Like one that supports
platform devices, for example?
Thanks!
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Embedded topics at Linux Plumbers 2010
From: Grant Likely @ 2010-07-06 19:56 UTC (permalink / raw)
To: linux-embedded
Hi all,
I'm on the Linux Plumbers [1] planning committee this year, and I'm
also heading up the embedded Linux mini-conference. While the
"official" call for miniconference proposals hasn't actually been
issued (real soon now, I promise!), the submission form [2] is now
open, and embedded topic proposals are being accepted. Some initial
ideas have already been discussed on the plumbers wiki[3], but now we
need firm proposals to use in planning the miniconference. If there
is anything embedded related that you'd like to discuss at plumbers,
then I encourage you to submit a proposal.
[1] http://www.linuxplumbersconf.org/2010
[2] http://www.linuxplumbersconf.org/2010/ocw/events/LPC2010MC/proposals
[3] http://wiki.linuxplumbersconf.org/2010:embedded_topics
The miniconferences are working sessions to get developers from
different projects into the same room. Focus is on discussing and
solving problems instead of formal presentations. A good proposal
includes a problem that needs to be solved, some potential solutions
to discuss, and ideally identify individuals who's participation is
important.
Deadline for proposal submission is July 19th, so get those proposals
in soon! If you have a good topic, but are unsure whether or not
you'll be able to attend, please submit the proposal anyway. The
miniconference format is flexable so we're able to handle a certain
amount of uncertainty.
For those who do want to make a formal presentation, we've do also
have one track dedicated to the purpose. Presentation proposals can
be submitted here [4]. We also have some slots set aside for BoFs
[5].
[4] http://www.linuxplumbersconf.org/2010/ocw/events/LPC2010/proposals
[5] http://www.linuxplumbersconf.org/2010/ocw/events/LPC2010BOFS/proposals
If you have any questions, feel free to email me.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Samo Pogacnik @ 2010-07-03 19:21 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-embedded, linux kernel
In-Reply-To: <20100627143518.104ef190@lxorguk.ukuu.org.uk>
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 <samo_pogacnik@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/ttyprintk User 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 0000000..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 <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;
+
+/*
+ * 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 */
+static void ttyprintk_ratelimit(const char *tag, const char *buf)
+{
+ static unsigned int tpk_write_delay;
+
+ /* clear ratelimit missed callbacks counter */
+ ttyprintk_rs.missed = 0;
+ if (__ratelimit(&ttyprintk_rs)) {
+ tpk_ratelimiting = 0;
+ ttyprintk_rs.burst = TPK_RATELIMIT_BURST;
+ } else
+ tpk_ratelimiting = 1;
+
+ if (tpk_ratelimiting == 0) {
+ tpk_write_delay = 0;
+ } else {
+ /* increase delay under pressure */
+ if (tpk_write_delay < (TPK_MAX_DELAY * TPK_SCALE_DELAY))
+ tpk_write_delay++;
+ msleep_interruptible(tpk_write_delay / TPK_SCALE_DELAY);
+
+ /* eliminate delay in ratelimiting */
+ ttyprintk_rs.burst = 1;
+ ttyprintk_rs.begin = 0;
+ __ratelimit(&ttyprintk_rs);
+ }
+
+ /* send the string down the drain */
+ printk(KERN_INFO "%s%s", tag, buf);
+}
+
+/*
+ * 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';
+ ttyprintk_ratelimit(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[tpk_curr + 0] = '\n';
+ tmp[tpk_curr + 1] = '\0';
+ ttyprintk_ratelimit(tpk_tag, tmp);
+ tpk_curr = 0;
+ if (buf[i + 1] == '\n')
+ i++;
+ break;
+ case '\n':
+ tmp[tpk_curr + 1] = '\0';
+ ttyprintk_ratelimit(tpk_tag, tmp);
+ tpk_curr = 0;
+ break;
+ default:
+ tpk_curr++;
+ }
+ } else {
+ /* end of tmp buffer reached: cut the message in two */
+ tmp[tpk_curr + 1] = '\\';
+ tmp[tpk_curr + 2] = '\n';
+ tmp[tpk_curr + 3] = '\0';
+ ttyprintk_ratelimit(tpk_tag, tmp);
+ tpk_curr = 0;
+ }
+ }
+
+ return count;
+}
+
+/*
+ * TTY operations open function.
+ */
+static int tpk_open(struct tty_struct *tty, struct file *filp)
+{
+ tty->driver_data = &tpk_port;
+
+ return tty_port_open(&tpk_port.port, tty, filp);
+}
+
+/*
+ * TTY operations close function.
+ */
+static void tpk_close(struct tty_struct *tty, struct file *filp)
+{
+ struct ttyprintk_port *tpkp = tty->driver_data;
+
+ mutex_lock(&tpkp->port_write_mutex);
+ /* flush tpk_printk buffer */
+ tpk_printk(NULL, 0);
+ mutex_unlock(&tpkp->port_write_mutex);
+
+ tty_port_close(&tpkp->port, tty, filp);
+}
+
+/*
+ * TTY operations write function.
+ */
+static int tpk_write(struct tty_struct *tty,
+ const unsigned char *buf, int count)
+{
+ struct ttyprintk_port *tpkp = tty->driver_data;
+ int ret;
+
+
+ /* exclusive use of tpk_printk within this tty */
+ mutex_lock(&tpkp->port_write_mutex);
+ ret = tpk_printk(buf, count);
+ mutex_unlock(&tpkp->port_write_mutex);
+
+ return ret;
+}
+
+/*
+ * TTY operations write_room function.
+ */
+static int tpk_write_room(struct tty_struct *tty)
+{
+ return TPK_MAX_ROOM;
+}
+
+/*
+ * TTY operations ioctl function.
+ */
+static int tpk_ioctl(struct tty_struct *tty, struct file *file,
+ unsigned int cmd, unsigned long arg)
+{
+ struct ttyprintk_port *tpkp = tty->driver_data;
+
+ if (!tpkp)
+ return -EINVAL;
+
+ switch (cmd) {
+ /* Stop TIOCCONS */
+ case TIOCCONS:
+ return -EOPNOTSUPP;
+ default:
+ return -ENOIOCTLCMD;
+ }
+ return 0;
+}
+
+static const struct tty_operations ttyprintk_ops = {
+ .open = tpk_open,
+ .close = tpk_close,
+ .write = tpk_write,
+ .write_room = tpk_write_room,
+ .ioctl = tpk_ioctl,
+};
+
+struct tty_port_operations null_ops = { };
+
+static struct tty_driver *ttyprintk_driver;
+
+static int __init ttyprintk_init(void)
+{
+ int ret = -ENOMEM;
+ void *rp;
+
+ ttyprintk_driver = alloc_tty_driver(1);
+ if (!ttyprintk_driver)
+ return ret;
+
+ ttyprintk_driver->owner = THIS_MODULE;
+ ttyprintk_driver->driver_name = "ttyprintk";
+ ttyprintk_driver->name = "ttyprintk";
+ ttyprintk_driver->major = TTYAUX_MAJOR;
+ ttyprintk_driver->minor_start = 3;
+ ttyprintk_driver->num = 1;
+ ttyprintk_driver->type = TTY_DRIVER_TYPE_CONSOLE;
+ ttyprintk_driver->init_termios = tty_std_termios;
+ ttyprintk_driver->init_termios.c_oflag = OPOST | OCRNL | ONOCR | ONLRET;
+ ttyprintk_driver->flags = TTY_DRIVER_RESET_TERMIOS |
+ TTY_DRIVER_REAL_RAW | TTY_DRIVER_DYNAMIC_DEV;
+ tty_set_operations(ttyprintk_driver, &ttyprintk_ops);
+
+ ret = tty_register_driver(ttyprintk_driver);
+ if (ret < 0) {
+ printk(KERN_ERR "Couldn't register ttyprintk driver\n");
+ goto error;
+ }
+
+ /* create our unnumbered device */
+ rp = device_create(tty_class, NULL, MKDEV(TTYAUX_MAJOR, 3), NULL,
+ ttyprintk_driver->name);
+ if (IS_ERR(rp)) {
+ printk(KERN_ERR "Couldn't create ttyprintk device\n");
+ ret = PTR_ERR(rp);
+ goto error;
+ }
+
+ tty_port_init(&tpk_port.port);
+ tpk_port.port.ops = &null_ops;
+ mutex_init(&tpk_port.port_write_mutex);
+
+ return 0;
+
+error:
+ put_tty_driver(ttyprintk_driver);
+ ttyprintk_driver = NULL;
+ return ret;
+}
+module_init(ttyprintk_init);
^ permalink raw reply related
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Samo Pogacnik @ 2010-06-28 23:27 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-embedded, linux kernel
In-Reply-To: <20100627143518.104ef190@lxorguk.ukuu.org.uk>
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
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Alan Cox @ 2010-06-27 13:35 UTC (permalink / raw)
To: Samo Pogacnik; +Cc: linux-embedded, linux kernel
In-Reply-To: <1277516912.29797.411.camel@itpsd6lap>
> 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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox