* patch "add ttyprintk driver" added to gregkh-2.6 tree
From: gregkh @ 2010-09-01 22:50 UTC (permalink / raw)
To: samo_pogacnik, alan, gregkh, kay.sievers, linux-embedded,
linux-kernel
In-Reply-To: <1282761847.5857.9.camel@itpsd6lap>
This is a note to let you know that I've just added the patch titled
add ttyprintk driver
to my gregkh-2.6 tree which can be found in directory form at:
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
and in git form at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/patches.git
The filename of this patch is:
add-ttyprintk-driver.patch
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
If this patch meets the merge guidelines for a bugfix, it should be
merged into Linus's tree before the next major kernel release.
If not, it will be merged into Linus's tree during the next merge window.
Either way, you will probably be copied on the patch when it gets sent
to Linus for merging so that others can see what is happening in kernel
development.
If you have any questions about this process, please let me know.
From samo_pogacnik@t-2.net Wed Sep 1 15:35:26 2010
Subject: add ttyprintk driver
From: Samo Pogacnik <samo_pogacnik@t-2.net>
To: linux kernel <linux-kernel@vger.kernel.org>
Cc: linux-embedded <linux-embedded@vger.kernel.org>,
Greg KH <gregkh@suse.de>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Kay Sievers <kay.sievers@vrfy.org>
Date: Wed, 25 Aug 2010 20:44:07 +0200
Message-Id: <1282761847.5857.9.camel@itpsd6lap>
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.
Signed-off-by: Samo Pogacnik <samo_pogacnik@t-2.net>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
Documentation/devices.txt | 1
drivers/char/Kconfig | 15 +++
drivers/char/Makefile | 1
drivers/char/ttyprintk.c | 225 ++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 242 insertions(+)
--- a/Documentation/devices.txt
+++ b/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
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -493,6 +493,21 @@ 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"
+ depends on EMBEDDED
+ 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
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -12,6 +12,7 @@ obj-y += mem.o random.o tty_io.o n_tty.
obj-y += tty_mutex.o
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
--- /dev/null
+++ b/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
* Re: [RFC] Kernel 'boot cache' to reduce boot time
From: Grant Likely @ 2010-09-01 2:40 UTC (permalink / raw)
To: Tim Bird
Cc: Andrew Murray, linux-embedded@vger.kernel.org, linux kernel,
Van De Ven, Arjan
In-Reply-To: <4C7D5D60.1070203@am.sony.com>
On Tue, Aug 31, 2010 at 1:52 PM, Tim Bird <tim.bird@am.sony.com> wrote:
> On 08/31/2010 12:13 PM, Andrew Murray wrote:
>> I have a suggestion for a kernel framework which aims to reduce boot
>> time in embedded devices and would be interested in hearing your
>> feedback.
>>
>> A large portion of kernel boot time is spent in driver probe functions
>> often waiting for hardware for example calculating LPJ values or
>> trying to determine what type of camera is connected (PAL/NTSC) etc.
>> However for most embedded devices the hardware remains constant and
>> these probes always determine the same information. Therefore boot
>> time can be decreased by removing some of this probe code and
>> replacing it with known values.
>>
>> To some extent some of these optimisations have already been done
>> through a variety of methods - for example the LPJ calculation can be
>> bypassed with the lpj= parameter and some drivers have their own
>> methods. My solution aims to generalise these solutions...
>>
>> The solution is to provide a very simple framework which will allow
>> drivers to identify and record such values (LPJ, camera type, decoder
>> chip version) during boot. Once booted the user can obtain a
>> collection of these values and pass them back to the kernel on
>> subsequent boots. During subsequent boots - drivers upon realising
>> these values have already been provided can bypass some of their probe
>> code and thus reducing boot time. Taking advantage of this framework
>> would be very trivial for drivers.
I think we've pretty much already got this functionality, even if it
isn't fully taken advantage of by all device drivers. Any device can
be registered with either a device-specific platform_data pointer or a
device_node pointer (when CONFIG_OF is enabled). Any driver can be
adapted to use additional data from either of those sources as an
alternative to HW probing. platform_data is simply a statically
defined C structure provided by the board support code. A device_node
pointer points to the device's node in a flattened device tree data
structure that is passed to the kernel at boot time.
(It's also worth noting that a large number of device drivers in
embedded devices already don't do any form of probing, and only rely
on the static data provided at device registration time).
USB and PCI busses are the obvious cases where the kernel currently HW
probes by default, but those cases could also be modified to make use
of device tree or platform_data configuration sources. From your
description, it sounds like camera connections are in the same boat.
>> I wanted to see your views on the overall solution prior to
>> considering how it could be implemented.
>
> For my part, I think this sounds like a great idea. I have
> considered such a mechanism in the past, but never gotten around
> to actually designing a solution.
>
> Here are some random thoughts on this idea:
>
> My experience is that we've made good progress on boot time
> probing, for fixed hardware. The big problems in the kernel
> boot time appear to be with busses that require discovery of
> devices, with long timeouts specified in the bus standard and
> arbitrary bus connection architecture (I'm thinking of USB,
> but other busses have similar problems). For many embedded
> devices, scanning these types of pluggable busses aren't
> required for what I call "first product use", but they can be
> scanned and populated later.
There actually already are bindings and some support code for
describing fixed PCI devices in a flattened device tree. USB is a bit
harder though, but fortunately USB probing can often be deferred until
later in the boot (as you rightly pointed out) after userspace has
started.
>
> Note that the asynchronous function call stuff by Arjan
> van de Ven addresses some of this boot time probing
> delay problem.
>
> Having said that, I don't think that probing of static
> hardware is a solved problem, by any means.
>
> For the boot cache data, you are going to need to figure
> out how to make the data persistent. Doing something
> in a regular fashion (rather than ad-hoc via command line
> options) should help with this.
I'm not convinced that doing a "live" capture is the best approach.
I'd rather see that kind of data obtained by the developer and
explicitly specified either in a device tree or the platform support
code.
If live capture is required, then doing an IPL-style boot, suspend &
dump (like you described below) is probably a more robust approach.
Otherwise you have to figure out how to pick and choose items of data
out of a running kernel and inject them in again at the next boot
(blech!).
> To some degree this might end up looking very similar
> to the "resume" path in the driver, where a particular
> device state is entered into from cold start.
>
> Sony has been doing something related to this called
> "Snapshot boot" for some time now, which is kind of an
> optimized unhibernate operation, with some hardware bringup
> done by firmware, and some bringup done using the normal driver
> resume operation. This work was presented at OLS
> several years ago, but we haven't pushed it much since
> then. (But we're using it in product)
> See http://elinux.org/upload/3/37/Snapshot-boot-final.pdf
I remember hearing very positive things about that presentation (and
being sorry that I missed it) that year at OLS. I'm pretty intrigued
by the approach and would like to see more research done in that area.
> Sorry for rambling. Anyway - I'm all for the boot cache idea.
> But acceptability would, of course, be dependent on the
> details of the implementation.
>
> The best thing to get started, IMHO, would be to identify
> a few drivers which have long probe times, and see
> how they could reduce these with the proposed boot cache.
> If you find that each new device adds some new wrinkle
> in the cache requirements, that would be a bad sign. But
> if different drivers, especially drivers in different functional
> areas, are found to be able to use a consistent API, then
> this could be a nice feature.
>
> BTW - I could see this tying into the flattened device
> tree work by Grant Likely.
http://www.devicetree.org/Device_Tree_Usage
g.
^ permalink raw reply
* Re: [RFC] Kernel 'boot cache' to reduce boot time
From: Andrew Murray @ 2010-08-31 20:15 UTC (permalink / raw)
To: Tim Bird
Cc: linux-embedded@vger.kernel.org, Grant Likely, linux kernel,
Van De Ven, Arjan
In-Reply-To: <4C7D5D60.1070203@am.sony.com>
Hello,
On 31 August 2010 20:52, Tim Bird <tim.bird@am.sony.com> wrote:
> Having said that, I don't think that probing of static
> hardware is a solved problem, by any means.
>
> For the boot cache data, you are going to need to figure
> out how to make the data persistent. Doing something
> in a regular fashion (rather than ad-hoc via command line
> options) should help with this.
Yes I wanted to see if the community was interested in the general
idea before I considered the implementation in too much detail. Though
the two obvious choices spring to mind. 1) Simply serialise and print
any suitable values to the console - these can be parsed with a
bootscript much like the way you parse initcall_debug. 2) Output these
values to a proc file which the use can extract.
The difficult part as I see it - is passing it back to the kernel - as
you suggested they may be some common ground with the device tree
models. Any suggestions?
I anticipate seeing name/value string pairs (or a small number of
types, e.g. int) - and leave it up to the driver to determine the best
way to serialise the data into the supported types. For example a
driver you may see the following pairs in a 'bootcache' file:
lpj=12313,drivers.media.video.decoder.ver=14,drivers.media.video.camera.type=pal
etc. I think the information encoded in this way would be a much
higher level that the typical register values used in suspend/resume
code.
>
> To some degree this might end up looking very similar
> to the "resume" path in the driver, where a particular
> device state is entered into from cold start.
I anticipated perhaps a simpler approach where instead of completely
getting rid of the probe - the probe simply skips time consuming paths
via this framework - I though this would make it easier for device
drivers to use the framework.
> Sorry for rambling. Anyway - I'm all for the boot cache idea.
> But acceptability would, of course, be dependent on the
> details of the implementation.
>
> The best thing to get started, IMHO, would be to identify
> a few drivers which have long probe times, and see
> how they could reduce these with the proposed boot cache.
> If you find that each new device adds some new wrinkle
> in the cache requirements, that would be a bad sign. But
> if different drivers, especially drivers in different functional
> areas, are found to be able to use a consistent API, then
> this could be a nice feature.
I agree.
>
> BTW - I could see this tying into the flattened device
> tree work by Grant Likely.
> -- Tim
>
> P.S. Also, I would recommend cross-posting to LKML
> to get wider visibility of your proposal. I'm doing
> so in this response - I hope that's OK.
Thanks for the useful information - I'll read up on those slides.
Andrew Murray
^ permalink raw reply
* Re: [RFC] Kernel 'boot cache' to reduce boot time
From: Tim Bird @ 2010-08-31 19:52 UTC (permalink / raw)
To: Andrew Murray
Cc: linux-embedded@vger.kernel.org, Grant Likely, linux kernel,
Van De Ven, Arjan
In-Reply-To: <AANLkTimJkPD=shB9oi3ASocaLEpG=C7oDJMbq8BEy2Fe@mail.gmail.com>
On 08/31/2010 12:13 PM, Andrew Murray wrote:
> I have a suggestion for a kernel framework which aims to reduce boot
> time in embedded devices and would be interested in hearing your
> feedback.
>
> A large portion of kernel boot time is spent in driver probe functions
> often waiting for hardware for example calculating LPJ values or
> trying to determine what type of camera is connected (PAL/NTSC) etc.
> However for most embedded devices the hardware remains constant and
> these probes always determine the same information. Therefore boot
> time can be decreased by removing some of this probe code and
> replacing it with known values.
>
> To some extent some of these optimisations have already been done
> through a variety of methods - for example the LPJ calculation can be
> bypassed with the lpj= parameter and some drivers have their own
> methods. My solution aims to generalise these solutions...
>
> The solution is to provide a very simple framework which will allow
> drivers to identify and record such values (LPJ, camera type, decoder
> chip version) during boot. Once booted the user can obtain a
> collection of these values and pass them back to the kernel on
> subsequent boots. During subsequent boots - drivers upon realising
> these values have already been provided can bypass some of their probe
> code and thus reducing boot time. Taking advantage of this framework
> would be very trivial for drivers.
>
> I wanted to see your views on the overall solution prior to
> considering how it could be implemented.
For my part, I think this sounds like a great idea. I have
considered such a mechanism in the past, but never gotten around
to actually designing a solution.
Here are some random thoughts on this idea:
My experience is that we've made good progress on boot time
probing, for fixed hardware. The big problems in the kernel
boot time appear to be with busses that require discovery of
devices, with long timeouts specified in the bus standard and
arbitrary bus connection architecture (I'm thinking of USB,
but other busses have similar problems). For many embedded
devices, scanning these types of pluggable busses aren't
required for what I call "first product use", but they can be
scanned and populated later.
Note that the asynchronous function call stuff by Arjan
van de Ven addresses some of this boot time probing
delay problem.
Having said that, I don't think that probing of static
hardware is a solved problem, by any means.
For the boot cache data, you are going to need to figure
out how to make the data persistent. Doing something
in a regular fashion (rather than ad-hoc via command line
options) should help with this.
To some degree this might end up looking very similar
to the "resume" path in the driver, where a particular
device state is entered into from cold start.
Sony has been doing something related to this called
"Snapshot boot" for some time now, which is kind of an
optimized unhibernate operation, with some hardware bringup
done by firmware, and some bringup done using the normal driver
resume operation. This work was presented at OLS
several years ago, but we haven't pushed it much since
then. (But we're using it in product)
See http://elinux.org/upload/3/37/Snapshot-boot-final.pdf
Sorry for rambling. Anyway - I'm all for the boot cache idea.
But acceptability would, of course, be dependent on the
details of the implementation.
The best thing to get started, IMHO, would be to identify
a few drivers which have long probe times, and see
how they could reduce these with the proposed boot cache.
If you find that each new device adds some new wrinkle
in the cache requirements, that would be a bad sign. But
if different drivers, especially drivers in different functional
areas, are found to be able to use a consistent API, then
this could be a nice feature.
BTW - I could see this tying into the flattened device
tree work by Grant Likely.
-- Tim
P.S. Also, I would recommend cross-posting to LKML
to get wider visibility of your proposal. I'm doing
so in this response - I hope that's OK.
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
* [RFC] Kernel 'boot cache' to reduce boot time
From: Andrew Murray @ 2010-08-31 19:13 UTC (permalink / raw)
To: linux-embedded
Hello,
I have a suggestion for a kernel framework which aims to reduce boot
time in embedded devices and would be interested in hearing your
feedback.
A large portion of kernel boot time is spent in driver probe functions
often waiting for hardware for example calculating LPJ values or
trying to determine what type of camera is connected (PAL/NTSC) etc.
However for most embedded devices the hardware remains constant and
these probes always determine the same information. Therefore boot
time can be decreased by removing some of this probe code and
replacing it with known values.
To some extent some of these optimisations have already been done
through a variety of methods - for example the LPJ calculation can be
bypassed with the lpj= parameter and some drivers have their own
methods. My solution aims to generalise these solutions...
The solution is to provide a very simple framework which will allow
drivers to identify and record such values (LPJ, camera type, decoder
chip version) during boot. Once booted the user can obtain a
collection of these values and pass them back to the kernel on
subsequent boots. During subsequent boots - drivers upon realising
these values have already been provided can bypass some of their probe
code and thus reducing boot time. Taking advantage of this framework
would be very trivial for drivers.
I wanted to see your views on the overall solution prior to
considering how it could be implemented.
Thanks,
Andrew Murray
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Greg KH @ 2010-08-26 23:02 UTC (permalink / raw)
To: Samo Pogacnik; +Cc: Alan Cox, Kay Sievers, linux kernel, linux-embedded
In-Reply-To: <1282843484.2440.23.camel@itpsd6lap>
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
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Samo Pogacnik @ 2010-08-26 17:24 UTC (permalink / raw)
To: Greg KH; +Cc: Alan Cox, Kay Sievers, linux kernel, linux-embedded
In-Reply-To: <20100825181647.GA22018@suse.de>
On 25.08.2010 (sre) at 11:16 -0700 Greg KH wrote:
> On Wed, Aug 25, 2010 at 07:14:37PM +0100, Alan Cox wrote:
> > > > > That's one extra process, not that much, right?
> > > >
> > > > About 150K or so way too much and its not robust.
> > >
> > > Fair enough. So, with this driver, would it make sense for the distros
> > > to switch over to using it instead of the above line in their initrd?
> >
> > Distros no - I doubt any normal PC distro would turn the facility on.
> > Embedded - yes especially deeply embedded.
>
> So should this be dependent on CONFIG_EMBEDDED then?
>
Should i resend the patch with CONFIG_EMBEDDED dependency enabled? I do
not have any real objections to that, except that the driver operates
the same way regardless of the (non-)embedded configuration.
regards, Samo
^ permalink raw reply
* Embedded Linux Conference Europe Program Announced
From: Tim Bird @ 2010-08-25 21:51 UTC (permalink / raw)
To: linux-embedded
Sorry in advance for this non-technical post, but I figured
some embedded kernel developers (especially in Europe) might
be interested in this.
== SUMMARY
The CE Linux Forum is pleased to announce the program for
Embedded Linux Conference Europe, 2010. This event
brings together embedded Linux experts from Europe and around the world.
This year the event is planned for October 26-28, in Cambridge, UK.
We are happy to be co-located with the GStreamer conference, to be
held October 26 in the same venue.
A full list of ELC Europe sessions is available at:
http://www.embeddedlinuxconference.com/elc_europe10/sessions.html
and for program details, see:
http://www.embeddedlinuxconference.com/elc_europe10/program.html
Note that the main conference days are October 27 and 28, with
some tutorial workshops offered October 26.
Registration is now open at the above web site.
Information about the GStreamer conference is available at:
http://gstreamer.freedesktop.org/conference/
== PROGRAM HIGHLIGHTS
The conference will host almost 50 sessions, including presentations,
Birds-of-a-Feather sessions, keynotes and tutorials. The sessions
will cover such wide-ranging topics as:
* Linux in Mobile
* Porting and board bring-up
* Android
* Meego
* Video and Multimedia
* Boot technologies, including fast booting
* Toolchains
* Power management
* Real-time
* Memory analysis and performance
* Flash file systems
* Security
* License compliance
and much more.
Presenters are Linux developers and experts from companies
like: Texas Instruments, Intel, ARM, Wind River, Mentor Graphics,
ST Ericsson, Alcatel-Lucent, ST Microelectronics, Montavista,
Sony, Pengutronix, Samsung, Nokia, and Toshiba.
Here are some of the experts presenting at this event:
* Ari Rauch - Senior director of Software and Systems Engineering
for TI's wireless OMAP processor group
* Ralf Baechle - Maintainer of the MIPS architecture in the
Linux kernel
* Wolfram Sang - Developer at Pengutronix, and longtime
kernel contributor
* Armijn Hemel - A driving force at gpl-violations.org
* Kevin Hillman - Former MontaVistan, long-time kernel power manage-
ment guru, and maintainer of the TI DaVinci SoC kernel code
* Wookey - Maintainer of YAFFS, and embedded Debian contributor
* Grant Likely - Kernel maintainer for some embedded PowerPC boards
and the new flattened device tree system
* Frank Rowand - Realtime Linux practitioner at Sony Corporation
Registration includes access to all sessions, demos, BOF meetings,
and lunch and snacks each day.
There will also be a fun social event Wednesday night,
hosted by Intel.
== Tutorials
We have also arranged for some hands-on tutorial sessions on
Tuesday, October 26. There will be 2 half-day sessions taught
by experienced Linux trainer and consultant Chris Simmonds.
The sessions cover basic embedded Linux bring-up and an
introduction to Android development. Space for these sessions
is limited, and requires an extra fee. See the tutorial page
for details.
http://www.embeddedlinuxconference.com/elc_europe10/tutorial.html
== Sponsors
Sponsors for the event include the CE Linux Forum, Texas Instruments,
Linaro, Google, and Intel. All of these groups or companies are interested
in enhancing and promoting Linux in embedded products.
== Registration
To register, please follow the link at:
http://www.embeddedlinuxconference.com/elc_europe10/registration1.html
Registration is open to professionals and hobbyists, who receive
a substantially discounted rate.
If you have any questions, send e-mail to elce-10@tree.celinuxforum.org.
I hope you can make it!
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Alan Cox @ 2010-08-25 19:30 UTC (permalink / raw)
To: Greg KH; +Cc: Kay Sievers, Samo Pogacnik, linux kernel, linux-embedded
In-Reply-To: <20100825181647.GA22018@suse.de>
On Wed, 25 Aug 2010 11:16:47 -0700
Greg KH <gregkh@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
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Samo Pogacnik @ 2010-08-25 18:44 UTC (permalink / raw)
To: linux kernel; +Cc: linux-embedded, Greg KH, Alan Cox, Kay Sievers
In-Reply-To: <20100825171045.GA19401@suse.de>
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_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-25 18:16 UTC (permalink / raw)
To: Alan Cox; +Cc: Kay Sievers, Samo Pogacnik, linux kernel, linux-embedded
In-Reply-To: <20100825191437.1df57c9d@lxorguk.ukuu.org.uk>
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
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Alan Cox @ 2010-08-25 18:14 UTC (permalink / raw)
To: Greg KH; +Cc: Kay Sievers, Samo Pogacnik, linux kernel, linux-embedded
In-Reply-To: <20100825171045.GA19401@suse.de>
> > > 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
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Alan Cox @ 2010-08-25 17:11 UTC (permalink / raw)
To: Greg KH; +Cc: Kay Sievers, Samo Pogacnik, linux kernel, linux-embedded
In-Reply-To: <20100825155716.GB16284@suse.de>
> Would that work for this driver in use as a console?
Yes
> exec < /dev/console > /dev/kmsg 2>&1
>
> That's one extra process, not that much, right?
About 150K or so way too much and its not robust.
> > You also want errors to get out (or stored) even if there are crashes -
> > which the Fedora one is not very good at. To be fair in the Fedora world
> > its not a big deal to say 'Oh dear, boot with ....'. Embedded isn't the
> > same, and you want to capture the odd rare error reliably.
>
> again, the above exec line should work for what the embedded people
> want, right?
We didn't *need* devtmpfs either - that was a little bit of user space.
It's a similar thing - you can do the job better in 1.5K of kernel code
than 150K or more of user space - which is not trivial on a box with no
swap.
Alan
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Greg KH @ 2010-08-25 17:10 UTC (permalink / raw)
To: Alan Cox; +Cc: Kay Sievers, Samo Pogacnik, linux kernel, linux-embedded
In-Reply-To: <20100825181108.1dcd0d80@lxorguk.ukuu.org.uk>
On Wed, Aug 25, 2010 at 06:11:08PM +0100, Alan Cox wrote:
> > Would that work for this driver in use as a console?
>
> Yes
>
> > exec < /dev/console > /dev/kmsg 2>&1
> >
> > That's one extra process, not that much, right?
>
> About 150K or so way too much and its not robust.
Fair enough. So, with this driver, would it make sense for the distros
to switch over to using it instead of the above line in their initrd?
> > > You also want errors to get out (or stored) even if there are crashes -
> > > which the Fedora one is not very good at. To be fair in the Fedora world
> > > its not a big deal to say 'Oh dear, boot with ....'. Embedded isn't the
> > > same, and you want to capture the odd rare error reliably.
> >
> > again, the above exec line should work for what the embedded people
> > want, right?
>
> We didn't *need* devtmpfs either - that was a little bit of user space.
> It's a similar thing - you can do the job better in 1.5K of kernel code
> than 150K or more of user space - which is not trivial on a box with no
> swap.
Ok, I didn't realize it really was that big.
Samo, care to resend the patch?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Greg KH @ 2010-08-25 15:57 UTC (permalink / raw)
To: Alan Cox; +Cc: Kay Sievers, Samo Pogacnik, linux kernel, linux-embedded
In-Reply-To: <20100825110813.5f7d7ac8@lxorguk.ukuu.org.uk>
On Wed, Aug 25, 2010 at 11:08:13AM +0100, Alan Cox wrote:
> > > Do you want to be able to flip between a real debug interface and a
> > > logging device on the same software set without risking changing behaviour
> >
> > I don't understand this point.
>
> A tty has a very specific set of behaviours simply by being a tty. Some
> applications rely upon them so being able to flip between the two
> interfaces is useful.
Would that work for this driver in use as a console?
> > Seriously, look at how Fedora 14 handles this, why can't you do the same
> > for embedded systems all from userspace, no additional code needed
> > anywhere.
>
> Its a whole set of extra processes and daemons and stuff, and
> minimally uses something like 70K even if its very compact (8K stack, 40K+
> page tables, 16K of buffers, code, data) - oh and I forgot the fifo
> buffering and pty cost - so its near 100K. 1.5K v 100K - for something
> 1.5K of kernel code that anyone else can turn off and would be off by
> default ?
exec < /dev/console > /dev/kmsg 2>&1
That's one extra process, not that much, right?
> On a lot of embedded systems you don't have all the stuff Fedora carts
> around. No modules, initrds, magic front end processes, graphical startup
> daemons etc, all of which work to produce that feature IFF you have pty
> support in your kernel, and for the current code also glibc.
It sounded like they had an initrd that they cared about here.
> You also want errors to get out (or stored) even if there are crashes -
> which the Fedora one is not very good at. To be fair in the Fedora world
> its not a big deal to say 'Oh dear, boot with ....'. Embedded isn't the
> same, and you want to capture the odd rare error reliably.
again, the above exec line should work for what the embedded people
want, right?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Alan Cox @ 2010-08-25 10:08 UTC (permalink / raw)
To: Greg KH; +Cc: Kay Sievers, Samo Pogacnik, linux kernel, linux-embedded
In-Reply-To: <20100825004134.GA28884@suse.de>
> > 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
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Kay Sievers @ 2010-08-25 7:48 UTC (permalink / raw)
To: Greg KH; +Cc: Alan Cox, Samo Pogacnik, linux kernel, linux-embedded
In-Reply-To: <AANLkTi=SkVv4tYUuAr9n03iYFdTJQr7wQnFaodrkHpom@mail.gmail.com>
On Wed, Aug 25, 2010 at 09:40, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Wed, Aug 25, 2010 at 01:12, Greg KH <gregkh@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 2>&1
to get stuff directly to the kernel buffer.
What does /dev/ttyprintk offer on top of that?
Kay
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Kay Sievers @ 2010-08-25 7:40 UTC (permalink / raw)
To: Greg KH; +Cc: Alan Cox, Samo Pogacnik, linux kernel, linux-embedded
In-Reply-To: <20100824231241.GA6971@suse.de>
On Wed, Aug 25, 2010 at 01:12, Greg KH <gregkh@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
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Marco Stornelli @ 2010-08-25 6:50 UTC (permalink / raw)
To: Samo Pogacnik
Cc: Alan Cox, Kay Sievers, linux kernel, linux-embedded, Greg KH
In-Reply-To: <20100825004134.GA28884@suse.de>
2010/8/25 Greg KH <gregkh@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
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Greg KH @ 2010-08-25 0:41 UTC (permalink / raw)
To: Alan Cox; +Cc: Kay Sievers, Samo Pogacnik, linux kernel, linux-embedded
In-Reply-To: <20100825005152.40ba2f12@lxorguk.ukuu.org.uk>
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
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Alan Cox @ 2010-08-24 23:51 UTC (permalink / raw)
To: Greg KH; +Cc: Kay Sievers, Samo Pogacnik, linux kernel, linux-embedded
In-Reply-To: <20100824231241.GA6971@suse.de>
> > - formatting
>
> Ick, we really want to format things from userspace here?
Depends what you are trying to do.
Put an embedded hat on
Do you want to be able to flip between a real debug interface and a
logging device on the same software set without risking changing behaviour
Do you want to load a 70K daemon and an initrd or burn about 1.5K on a
kernel interface ?
Alan
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Alan Cox @ 2010-08-24 23:22 UTC (permalink / raw)
To: Greg KH; +Cc: Samo Pogacnik, linux kernel, linux-embedded
In-Reply-To: <20100824225703.GA5913@suse.de>
> No, it does cover that. You should be able to do that with a simple
> console redirection to /dev/kmsg What happened when you tried to do
> that?
stty: standard input: Inappropriate ioctl for device
It's value is twofold
- formatting
- tty ioctls work as they should on a console (eg vhangup)
and its a tiny driver with no impact on the rest of the kernel - so to me
it seems useful in that form.
Alan
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Greg KH @ 2010-08-24 23:12 UTC (permalink / raw)
To: Alan Cox, Kay Sievers; +Cc: Samo Pogacnik, linux kernel, linux-embedded
In-Reply-To: <20100825002221.68fc09a4@lxorguk.ukuu.org.uk>
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
^ permalink raw reply
* Re: [PATCH] detour TTY driver - now ttyprintk
From: Greg KH @ 2010-08-24 22:57 UTC (permalink / raw)
To: Samo Pogacnik; +Cc: linux kernel, linux-embedded, Alan Cox
In-Reply-To: <1282690232.8020.116.camel@itpsd6lap>
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
^ permalink raw reply
* 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
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